The order
Chart of accounts, dimensions, pipeline stages, project shape, part numbering. Nothing goes in until these stop changing. This is the step people rush and the step that determines whether the migration is done once or twice.
The first day of a period, never mid-month. Everything before it is history; everything after it is live.
One journal entry as at the day before cutover, taken from the old system's trial balance. This is the number everything else will be checked against.
Unpaid invoices, unpaid bills, open deals, live projects. These are the things people will touch in week one, so they matter more than history.
Prior-period detail is for reporting, not for operating. Bringing it in last means a delay here does not delay going live.
A trial balance in erp.io that ties to the old system, agreed by whoever signs your accounts.
If the cutover date is inside a period that is still being posted to in the old system, you get two partial truths and no way to reconcile them. Close the old period, then migrate, then post forward only in the new system.
What to bring, and what to leave
| Data | Bring it? | Why |
|---|---|---|
| Chart of accounts | Yes — first | Everything else references it. |
| Opening balances | Yes | The anchor for every later check. |
| Open AR and AP | Yes | People will chase and pay these in week one. |
| Customers and vendors | Yes | Cheap to bring, painful to type again. |
| Prior-year detail | Usually | Useful for comparatives. Not urgent — load it after go-live. |
| Five years of detail | Rarely | Keep the old system read-only instead. Cheaper and more accurate. |
| Closed deals from the old CRM | Summary only | Full history of dead deals adds noise to every pipeline report. |
| Attachments and documents | Selectively | Bulk file migration is slow and most of it is never opened again. |
It is often the right one. You need history to be *available*, not to be *in the new system*. One archived export plus read-only access satisfies most auditors and saves weeks.
How to prove it worked
- Trial balance ties. Run Trial Balance as at cutover and compare it line for line with the old system. Not a total — line for line.
- AR and AP agings tie. Totals and the bucket splits. A total that matches with different buckets means dates came across wrong.
- Bank balances tie to statements. Not to the old system — to the bank. If the old system was wrong, do not import the error.
- Spot-check twenty transactions. Chosen by somebody who did not do the migration.
- One person signs it off in writing. Whoever signs your accounts.
Trial Balance
As at 31 March 2026 · GBP
| Account | Code | Debit | Credit |
|---|---|---|---|
| Bank — current | 1010 | 84,210.55 | |
| Accounts receivable | 1100 | 46,980.00 | |
| Accounts payable | 2100 | 31,405.20 | |
| Share capital | 3000 | 10,000.00 | |
| Retained earnings | 3100 | 89,785.35 | |
| Total | 131,190.55 | 131,190.55 |
What this does not do
There is no screen that takes a QuickBooks or Xero export and loads it. Migrations run through the API or through us.
Nothing compares the two systems for you. The tie-out is a person with two reports.
If a load goes in wrong, the fix is to reverse it with journal entries or start the organisation again — there is no undo for a bulk import.
Questions
Can you do the migration for us?
Yes — that is a services engagement. See Implementation.
How long does a typical migration take?
Two to six weeks of elapsed time, most of it waiting on decisions about structure rather than on data movement.
What if our old data is wrong?
Do not import the error. Correct it in the old system or adjust on the way in, and document which you did.
Related
Sequencing people and modules so the old system can actually be switched off — and the checks that tell you it is safe to do it.
AccountingDouble-entry books on erp.io: chart of accounts, bank feeds, reconciliation, invoicing, bills, the close, and reporting — with AI that proposes and never posts.