The Move, and the Proof That It Landed
People arrive at a migration pushed, not pulled. The subscription went up again. The desktop version you once bought outright is being retired into a monthly fee. The file was structured when the business was half this size and has been fighting you ever since. Whatever started it, the decision is rarely made calmly and the timing is rarely yours.
The move itself is mechanical and runs in a fixed order. What decides whether it went well is the end of it, when somebody has to demonstrate that the numbers in the new file are the numbers you had in the old one. A migrated file still has to be maintained, so from the day it opens it goes onto the full-cycle bookkeeping schedule.
The order the work happens in
The sequence matters more than the tooling, because each stage depends on the one before it holding.
- Your chart of accounts is reviewed and rebuilt in the new platform, with old workarounds corrected rather than carried over
- Opening balances are set from your last filed year end and agreed to it
- Historical transactions are imported, in the volume we agreed is worth bringing
- Bank, credit card, and loan feeds are connected and validated against real statements
- Both systems are reconciled against each other, account by account
- The old system is retired only after step five agrees
Most migration problems are somebody doing four before three, or skipping five because the totals looked close enough on screen.
The history is the part that actually breaks
Simple files move easily. The migrations that go wrong belong to businesses that have been operating a long time and doing something complicated the whole while.
Burnaby’s industrial areas hold sixteen business centres, places like Glenlyon Estates and the Riverfront Business Park in Big Bend, mixing office space with light and specialized manufacturing. A file from a tenant like that carries inventory valuations, work in progress, capital assets partway through their depreciation, and years of job costing. Those are the records an automated conversion handles worst, because they are not transactions, they are positions built up over time. They get checked item by item and, in places, rebuilt by hand.
Nothing is trusted until the balances agree
An import that finishes without an error message has not proved anything. It has told you the file accepted the data.
So the last step is the same check that runs every month afterwards. Every account matched to its statement, on both sides of the move, with the old trial balance next to the new one and any difference tracked to the transaction that caused it. You see that comparison rather than being told it was fine. Until it agrees the old system stays live, because the worst version of this is finding a gap six months later with no working system left to check against.
Moving books that were never right just relocates the problem
This is the conversation worth having before the work starts. If the accounts in your current system have not been reconciled in a year, a migration does not fix that. It moves an unreliable set of numbers into cleaner software and gives them a freshness they have not earned.
When we find that, we say so and deal with it first, through catch-up work on the old file or by rebuilding the affected periods in the new one. It adds time and it is not the message anybody wants. It is also the only version that leaves you with a file you can stand behind.
Accounting Software Migration FAQs
As much as is worth bringing, and that is a decision we make together rather than a technical limit. Opening balances and the current open year are essential. Prior years are worth importing when you need comparatives or the detail behind a balance. Importing history that was never reconciled adds volume to the new file without adding anything you can rely on.
Yes. We pick a cutover date, usually a period end, and you carry on in the old system until it. After the cutover you work only in the new file while we reconcile both sides against each other. The one thing that causes problems is entering transactions in both places during the changeover, so we agree the date clearly up front.
You keep it, and you should. Export a full backup and the standard reports before any subscription lapses, because a read-only archive of the system you left is what you will want if a question about an older year ever comes up. We tell you exactly what to pull and when, since the window closes when the licence does.
It is the most common migration we do and it is well understood, but it is not a one-click conversion. Desktop files often carry years of workarounds, custom fields, and job costing that the online product organises differently. The list items and payroll history are the parts that most often need rebuilding by hand rather than importing.
Because we show you. Trial balance from the old system next to trial balance from the new one, account by account, plus every bank and credit card account reconciled to the same statement on both sides. If a figure does not agree, it gets explained and corrected before the old system is retired, not afterwards.
