Glossary
ERP and Accounting System Migration
An accounting system migration moves your books from one platform to another: desktop to cloud, a small-business ledger to a full ERP, or an acquired company’s system onto yours. The move itself is rarely the hard part. What causes damage is the residue it leaves in the numbers, which we find long afterwards when someone tries to value, finance or sell the business. At Treewalk we support migrations directly, and we also spend a lot of time cleaning up ones that were done without a plan.
The three situations that trigger a migration
You are still on desktop
Desktop accounting software is the most common starting point we see, and it is the one with the clearest answer. Get to cloud quickly. Desktop files fragment across machines, backups drift, and no advisor, lender or buyer can be given clean access without someone emailing a file around. Where a business is on desktop, our advice is usually a clean cut across to an online platform rather than a drawn-out dual-running arrangement.
You have outgrown the ledger
Multiple entities, inventory, project accounting, multi-currency or consolidations push a business past what a simple bookkeeping package handles well. That is a genuine ERP conversation.
You just acquired a business
This is the one buyers underestimate, and it is worth being firm about.
After an acquisition, start your own books on day one
The instinct after closing is to carry on with the seller’s books because the history is there and it feels like continuity. In our experience that is the more expensive path. You inherit whatever errors were already in the file, and you spend the first year unsure whether a problem is yours or theirs.
What we recommend instead is opening your own set of books effective day one, running them in parallel with the seller’s for a period, then closing theirs out and moving everything across. Get onto a cloud platform, and put a strict monthly close cadence in place with whoever owns the controllership function from the start. Where the seller has agreed to stay on for a transition period, use that window deliberately: it is the cheapest opportunity you will ever have to extract what they know about how the business actually runs.
What a migration does to your numbers
This is the part nobody warns you about, and it is where most of our involvement ends up.
Balances arrive that are not real
Negative accounts receivable is the classic one. It shows up as an apparently genuine credit balance, and when you open it up it is either an overpayment mismatch between what was billed and what was paid, or pure migration artifact. We have had to adjust receivables upward on diligence work specifically because negative balances in the ledger were not real, they were left behind by a system change.
The trend line breaks
A migration mid-year leaves a visible discontinuity in the monthly figures, and it is easy to mistake for a business problem. On one engagement the months around the system change showed a sharp drop that had nothing to do with trading. It mattered because working capital benchmarks are usually set on a trailing twelve month average. Where a migration sits inside that window, the twelve month figure is contaminated, and we will use a trailing three or six month basis instead so the net working capital peg reflects the business rather than the software change.
The source of truth splits
We have seen businesses stop invoicing in their accounting system during a migration, on advice, and move all client billing into a separate operational system. The logic was sound, one system for client activity. The consequence was that the accounting file no longer carried receivables at all. Anyone reading the ledger alone would conclude the business had no AR. It is not wrong, but it has to be known, and it is exactly the kind of thing that gets missed.
Opening balances get adjusted quietly
Opening balance equity entries made during setup often do not touch the profit and loss, so they never appear in an earnings review, while materially changing the balance sheet.
How we approach it
| Stage | What matters |
|---|---|
| Before | Decide cut-over date, chart of accounts mapping, and what history actually needs to move |
| Cut-over | Reconcile closing balances in the old system to opening balances in the new one, line by line |
| Parallel period | Run both briefly, compare, and resolve differences before switching off the old system |
| First close | Full month-end close in the new system with a controller reviewing it |
| After | Keep the old system readable. Someone will need the history during diligence |
That last row gets skipped constantly. A buyer or lender will ask for periods that predate the migration, and if the old system has been decommissioned and nobody kept an export, the answer becomes reconstruction.
What we actually do on these engagements
We are not a software reseller and we do not implement platforms. Our role is the accounting integrity around the move: mapping the chart of accounts, reconciling the cut-over, testing that opening balances tie to closing balances, running the first closes in the new system, and documenting the discontinuity so nobody later mistakes a system change for a performance change.
On post-acquisition work this usually runs alongside a fractional controller arrangement, because the migration and the first few closes are exactly when a business needs more finance capability than it will need steadily afterwards.
Frequently asked questions
Should we migrate before or after a sale?
If a sale is close, generally after. A migration inside the diligence window makes the trailing figures harder to read, and a buyer will discount what they cannot verify. If the timeline is longer, migrating early and getting clean months behind you is the stronger position.
How long does a migration take?
The software cut-over is usually days. Getting the numbers trustworthy afterwards is weeks, and that is the part worth planning around. The variable is the quality of the records going in.
Do we need to move all the history?
Rarely. Most businesses move opening balances plus a defined period of detail, and keep the old system readable for anything older. Trying to move everything is a common way to import old errors into a clean file.
What is the most common mistake?
Switching off the old system too early, before anyone has confirmed the new one reconciles. The second most common is not documenting when the migration happened, which is what causes a false performance story a year later.
Can you do the migration itself?
We handle the accounting side and work alongside the implementation partner on the technical side. The reconciliation, the chart of accounts, the first closes and the diligence-readiness of the result are ours.
Where to next
If you are moving systems, or you have already moved and the numbers have not felt right since, that is worth resolving before it turns into a diligence problem. Our private company team handles the accounting side of migrations and the closes that follow. If this is post-acquisition, buy-side due diligence covers what a clean opening position looks like. To talk it through, email Avnit Sekhon at avnit.sekhon@treewalk.com.
