A MYOB to Xero migration is not a script. It is a precision instrument with proof on every record, a name against every push, and a reconciled trial balance at the end. Here is what that actually looks like.
You moved from MYOB to Xero. Everything opened up on the other side. Customers were there. Invoices were there. The chart of accounts looked right. Someone ticked the box that said the migration was done.
Then at the next BAS, the GST figure did not match what you were expecting. Or your bookkeeper noticed the receivables total was $12,000 different to the last MYOB report. Or a supplier called about an old invoice that no longer existed in the system. Or the accountant asked, at year-end, who signed off on the tax code changes for the historical transactions, and nobody could answer.
None of this is unusual. It happens because most MYOB to Xero migrations are a script. The data moved. Nothing about the move was proven correct. And when a problem shows up months later, there is no way to trace what happened.
A migration done properly is a different thing entirely. It is a precision instrument with proof on every record, a name against every push, versioned rules that can be reproduced, and a reconciled trial balance at the end. Here is what that actually looks like.
The generic version of a MYOB to Xero migration is a three-step process. Export a CSV from MYOB. Adjust some columns. Import into Xero. The tool that does this can be a spreadsheet, a wizard, or a paid conversion service. The mechanics are the same.
What that process does well: it moves rows from one place to another. What it does not do: prove that the rows arrived intact, that they mean the same thing on the other side, or that anyone with authority looked at the change before it happened.
For a very simple file with no history to speak of, the script approach is genuinely fine. For an established business with years of transactions, custom chart of accounts, tracking categories, historical GST positions, and a bookkeeper who reads the numbers every month, the script is where the trouble starts.
The failures cluster into a short list.
Tax codes drift silently. MYOB and Xero do not use the same tax code names, and the mapping between them is a decision, not a fact. A migration that guesses that mapping without human sign-off can quietly shift the GST treatment on hundreds of transactions. You will not see it in the numbers on migration day. You will see it in the BAS three months later.
Contact merging loses history. If a customer exists in both MYOB and Xero already, a naive import creates a duplicate. A smarter import merges them, but which record wins? If the wrong one wins, you have lost the payment history from one of them.
Chart of accounts codes do not match. MYOB uses one numbering scheme, Xero uses another. If the mapping is not versioned and reviewed, you end up with historical transactions posted to the wrong accounts. Your profit and loss for last financial year now looks different depending on which system you ask.
Historical transactions round differently. The tax calculation on a $99.95 line item might land on a different cent in Xero than it did in MYOB. Across thousands of transactions, that adds up to a real difference in what the system says you owe.
Nothing is auditable. Six months later the accountant asks why a specific customer balance is off. Nobody can explain how any individual record got to where it is, what rules were applied, or who approved the batch it was in. There is no answer to give.
Each of those failures has the same root cause. The migration was treated as a data transfer, not a controlled process with proof at every step.
A migration done properly follows four principles from the first record extracted to the final reconciliation report.
The moment a record leaves MYOB, it gets stamped. Source ID (its MYOB identifier), target ID (the new Xero identifier once the push succeeds), the version of the mapping rules that were applied, and the specific migration run it belonged to. The original raw payload from MYOB is retained.
What this means in practice: if the accountant asks about a specific Xero invoice six months later, you can trace it back to the exact MYOB record it came from, the mapping version that produced it, and everything else that was in that batch. Nothing exists in Xero without a paper trail back to its source.
A two-person rule by default. The operator prepares the batch. The approver signs off before anything moves. The name of the person who approved the batch is recorded next to every migrated record forever, in an approvals table that cannot be deleted.
Why this matters: when an audit or a compliance question surfaces a year later, the answer is not "the migration tool did it". The answer is a specific person, on a specific date, approving a specific batch of records against a specific mapping. That is what a proper audit trail looks like.
The rules that translate MYOB fields to Xero fields are not fixed at the start of the project. They evolve. A tax code mapping gets refined after the first preview. A contact merge rule is added when duplicates show up. The chart of accounts mapping gets adjusted for the property side of the business.
Every one of those refinements creates a new version of the mapping. Past runs still reference the version they used. Six months later, if you need to understand exactly what produced a specific Xero record, you can look at which mapping version applied to that migration run and reproduce the logic exactly. Nothing is lost to "we changed the rules along the way".
The status "migration complete" does not mean anything on its own. The status that matters is reconciled. Endpoint counts on both sides match. The MYOB trial balance equals the Xero trial balance to the cent. Accounts receivable and accounts payable totals match. GST balances match. Bank balances match. Inventory quantities match.
If any of those do not square, the report says so, in writing, with specifics. A migration is not signed off until the reconciliation report is clean. And that report is the deliverable the business owner and the accountant keep on file.
Those four principles get delivered through a ten-phase pipeline. Every phase produces evidence. Nothing is left as "the tool did it in the background".
Authenticated connection to the source MYOB file and the target Xero organisation. Both sides use official APIs, not screen scrapers or shared logins. Access tokens are stored in a secrets manager, scoped per project, never in a spreadsheet or a shared drive. If the person running the project leaves, the credentials do not walk out with them.
Confirm which MYOB company file you are pulling from. Confirm the exact Xero organisation you are pushing to. Decide which data types are in scope: contacts, chart of accounts, tax rates, historical invoices, credit notes, tracking categories, bank feeds, opening balances. Some businesses want everything back to inception. Others want the last two financial years. That choice gets recorded.
Pull every field of every record from MYOB. Store the raw response exactly as MYOB returned it, before anything is touched. Rate limits are respected so the export runs cleanly overnight without triggering throttling. If Xero later rejects a record, the raw MYOB payload is there to show exactly what came out of MYOB in the first place.
Take the raw MYOB data and normalise it into clean, typed columns. Dates become dates. Currency becomes currency. Optional fields get consistent defaults. This step is deterministic, meaning if you run it again on the same input, you get the same output. That matters when something goes wrong and you need to re-run without introducing new drift.
Check the staged data against a set of rules before any mapping happens. ABN checksums are valid. Contact names are not blank. Invoice line totals add up to the header total. Parent references resolve, so an invoice does not point to a contact that does not exist. Anything that fails validation is flagged and the batch stops until the underlying data is fixed.
Apply the versioned mapping. This is where MYOB tax codes become Xero tax rates, MYOB account codes become Xero account codes, and cross-entity references get resolved through the identity map (so an invoice knows which Xero contact it belongs to, not just which MYOB contact it used to belong to). The mapping version applied is recorded against every record.
Nothing has moved yet. What you see is a full breakdown of what will happen if you approve the batch. Three thousand two hundred forty seven invoices ready to migrate. Four hundred fifty six contacts. Twelve merge candidates (where a contact already exists in Xero and needs a decision on which record wins). Three orphan transactions (records with a broken parent reference that need to be fixed or excluded).
The preview is the last stop before anything is written to Xero. It is designed to catch the problems that only become visible when you can see the full shape of the batch.
The two-person rule. The operator submits the batch. The named approver, usually the business owner, the bookkeeper, or the accountant, reviews the preview and signs off on the exact batch that will be pushed. The approval is recorded permanently against every record in that batch.
This is the checkpoint that turns a migration from "the tool did something" into "a specific person authorised a specific outcome on a specific date". It is not optional and it is not a rubber stamp.
The actual push to Xero, one record at a time, in the correct order (contacts before invoices, chart of accounts before transactions, tax rates before anything that uses them). If a record fails, the migration retries. If the whole batch is re-run for any reason, records that were already pushed do not become duplicates. That property is called idempotent, and it is what lets you run the migration confidently even when something goes wrong mid-way.
Endpoint totals are compared. Financial reconciliation runs. MYOB trial balance versus Xero trial balance, dollar for dollar. AR aging on both sides. GST on both sides. Bank balances on both sides. Inventory quantities where relevant. Every discrepancy is listed by record, not just as a total.
The reconciliation report is bundled with the audit log from all previous phases and delivered to the customer as the final artefact. That is the deliverable. Not "the migration is done". A reconciled Xero file with proof of how it got there.
At the end of a migration done this way, you do not just have data in Xero. You have three things that a script migration will never produce.
A reconciled Xero file. Every balance in Xero matches the equivalent balance in MYOB at the cutover date. Your accountant can sign off on the opening position without a two-week investigation.
A full audit trail. For any record in Xero, you can answer: where did it come from in MYOB, which mapping version applied to it, which migration batch it was part of, who approved that batch, and when. Every answer is a lookup, not an investigation.
A reproducible process. If a second entity needs to migrate next year, the same pipeline runs against the new source. The mappings that worked get reused. The ones that need to change get versioned. The migration is not a one-off adventure; it is a repeatable capability.
One thing worth being explicit about. A proper migration does take longer to set up than running a wizard, and it costs more up front. What you are buying is not just the move. It is confidence in the numbers on the other side, and the ability to answer any question anyone asks about them for years afterwards. That confidence is what stops the BAS surprise, the year-end investigation, and the tax audit that goes sideways because nobody can explain what happened.
Not every MYOB to Xero migration needs a precision instrument.
A wizard or a standard conversion service is usually fine when: the MYOB file is under a year old, transaction volume is low (a few hundred invoices in total), the chart of accounts is standard, there is no history you care about deeply, and the business does not run tracking categories, multiple bank feeds, or complex tax situations. A sole trader or a small consultancy in its first year of trading often fits this profile.
You want a controlled migration when: the MYOB file has multiple years of history, there is a custom chart of accounts, tracking categories are in use, GST reporting has been complex, there are multiple bank accounts or foreign currency, or the accountant will care deeply about the opening balances in Xero. Trades, hospitality groups, professional services firms, multi-entity structures, and businesses that have been on MYOB for more than three years usually fall into this bucket.
The cost of doing the wrong one is asymmetric. If you use the precision approach on a small file, you spent a bit more than you needed to. If you use the wizard approach on a complex file, you find out at year-end, at tax time, or during an audit, when fixing it is many times more expensive than doing it properly the first time.
Whether you use us, another consultancy, or an in-house team, these are the questions worth asking before anyone touches the data.
For any record in Xero after the migration, can you tell me exactly which MYOB record it came from? If the answer is vague, there is no identity map.
Who signs off on each batch before it is pushed to Xero? If the answer is "the migration runs automatically", there is no approval control.
If the mapping rules change during the project, what happens to records that were migrated under the old rules? If the answer does not involve versioned mappings, past runs cannot be explained.
What does the reconciliation report at the end look like, and what happens if the trial balance does not match? If there is no report, there is no reconciliation. If there is a report but discrepancies are "expected", the migration is not actually done.
If we find a problem three months after go-live, can you show me exactly what happened for the affected records? If the answer relies on someone remembering, the audit trail is not real.
A migration partner who can answer all five without hedging is running the kind of process that produces a Xero file you can trust. A partner who cannot is running a script.
The data moving is the easy part. The proof that it moved correctly is the whole job.
The specific failure patterns that turn a simple integration into a rebuild.
Your accounting, jobs and CRM all running fine, just separately. What that means and what fixing it looks like.
Your old system still works. It is just stuck. Four options and the risks that sink most modernisation projects.
Tell us what is happening in your workflow, stack, or customer journey. We will come back with a practical recommendation, not a generic pitch.
