The received wisdom on ERP migration is to take an opening balance and start clean. Cut over at a period boundary, carry the closing position forward, leave the history in the old system, and hope nobody needs it.
That advice exists because moving history is hard, not because leaving it behind is correct. A company that starts clean has a ledger with no memory. Year-on-year comparisons cross a system boundary. The auditor asking about a Q1 entry gets pointed at a decommissioned login. The board pack has a seam in it that never heals.
All Gravy moved everything. Every transaction back to the company's founding in January 2020, reconciled against trial balances year by year before import, with roughly 200,000 transactions in the Danish entity alone.
the earliest transaction migrated into Light, with every year since reconciled before import
transactions in the Danish entity alone, which carries around 95% of volume
people on the finance team that ran the migration, across 4 countries
What was being left behind
All Gravy had 4 entities on 4 ledgers: e-conomic in Denmark, Xero in the UK, Fortnox in Sweden, Tripletex in Norway. Pleo handled cards, Corpay and Farpay handled payments. 7 systems, and each new market had added one.
Underneath sat a chart of accounts built for an earlier version of the company, years before it became a SaaS business. Department reporting ran on dedicated GL accounts rather than dimensions. A migration that carried that structure forward would have moved the problem rather than solved it, so the team rebuilt the chart of accounts from the ground up for a SaaS business, with custom dimensions for department and country in place from day 1.
That is the part most migration plans skip. Lifting a broken structure into a better system produces a better system running a broken structure.
"We always have to look at the foundation and ask whether it scales 10x. We kept adding tools as we added entities, and each of them worked to a point. Orchestrating a close across all of them was the problem."
Sebastian Sandorff Jacobsen, Head of Finance and Ops, All Gravy
Why full history was non-negotiable
Dreamdata took the same position for a different reason: audited and mid-raise, the company refused to let January look different from July. Migrating an opening balance would have meant 2 sources of truth for a single financial year, which is the exact thing an auditor will spend a week unpicking.
The general principle holds beyond either company. A ledger's value is comparative. Revenue this quarter means something only against revenue last quarter, and the moment those 2 numbers live in different systems the comparison becomes a reconciliation. Full history migration is expensive once. A permanent seam in the record is expensive every time anybody looks back through it.
Common approach
Opening balance, clean start
Cut over at a period end and carry the closing position forward. Cheapest to execute, and the old system stays alive as a read-only archive nobody maintains.
What All Gravy did
Full history, reconciled
Every transaction from January 2020, checked against the trial balance for each year before import, with the chart of accounts rebuilt rather than copied.
What it buys
A ledger with memory
Comparatives, audit trails and board reporting that run continuously across the boundary, because there is no boundary.
The honest part
Nobody involved describes this as painless.
"ERP migrations are painful as a general rule. You can have a less painful experience or a very painful one. The Light team answered us at very late hours of the night, which matters when you are three people running a project this size."
Sebastian Sandorff Jacobsen, Head of Finance and Ops, All Gravy
That is the realistic frame. The variable is not whether a migration is difficult. It is how much of the difficulty the vendor absorbs, and whether the thing on the other side is worth the crossing.
For All Gravy the other side looks like this. 7 systems became 1. 4 entities close in 5 days, with nobody working nights. 500 to 600 monthly card transactions that used to be uploaded by hand now land in the ledger untouched. Bills arrive by email and get read and coded on arrival. Approvals run in Slack. Collections run as an agent. The company doubled while the finance team stayed at 3, and its bookkeeping partner spends 30 to 40% less time on the books than before.
"Going from logging into four different systems to seeing every entity in one place was the part that changed my day."
Linea Meldgaard Andersen, Finance Analyst, All Gravy
What actually makes it survivable
3 things, in the order they mattered.
Reconcile before you import, year by year, against the trial balance the old system produced. A migration that lands unreconciled data is not a migration, it is a data transfer with a reconciliation project attached to the far end.
Rebuild the structure rather than carrying it. The chart of accounts, the dimensions and the entity model are the parts a company lives with for the next decade, and a migration is the only cheap moment to change them.
Pick the vendor by how they behave at 11pm in week 6, not by the implementation methodology in the deck. All Gravy had 3 people on this. Dreamdata had a controller who joined 6 weeks before go-live. Neither had the option of a project team, which is the situation most companies of this size are actually in.
See how Light handles multi-entity finance, or book a demo.