Guides
Moving to a new system without losing the year
What to bring, what to leave behind, and why opening balances matter more than history. A migration plan that fits on one page.
The Rocket ERP team
Rocket ERP3 min read
Most migration projects fail in one of two ways. Either they try to bring everything and never finish, or they bring too little and the first month in the new system cannot be reconciled with the last month in the old one. Both are avoidable with a decision made early about what history is actually for.
Opening balances are the deliverable; history is a convenience
The new system needs to start correct. That means, on a chosen cut-off date: stock quantities and their values, customer balances by invoice, supplier balances by invoice, cash and bank balances, fixed assets with accumulated depreciation, and the trial balance those add up to.
Transaction history - every invoice from the last five years - is useful but optional, and it is where migrations drown. Old documents carry old assumptions: discontinued items, obsolete tax rates, customers who no longer exist, a tax treatment that was legal then and is not now. Importing them means reproducing those assumptions in a system designed around today rules.
The usual right answer is to keep the old system readable for history and migrate balances plus the current year. If you need an old invoice, you look it up where it was issued.
Clean before you move, not after
Migration is the only moment when cleaning data is cheap, because nothing is built on it yet. Deduplicate customers. Retire items nobody has sold in two years. Fix units of measure. Fill in tax registration numbers. Decide the chart of accounts you want rather than copying the one you have.
Every one of those is an hour now or a month later. And the list of what needs cleaning is produced by the import itself: an import that reports per-row errors is telling you exactly where your data is wrong, which makes a failed first import the most useful document in the project.
A sequence that works
Pick the cut-off date. The start of a month, ideally the start of a quarter. Never mid-month.
Import master data first: accounts, branches, warehouses, items, units, customers, suppliers, employees. Nothing transactional until these are right, because every transaction references them.
Import opening balances as explicit opening entries, not as adjustments. They must be identifiable later as what they are.
Reconcile before going live: stock value against the inventory account, customer balances against receivables, the trial balance against the old system. If these do not agree on day zero, they will never agree.
Run both systems for one period if you can afford it, and compare the two closes. This is the only real test.
The parts people forget
Document numbering. Decide whether the new system continues the old series or starts fresh, and make sure the choice does not produce two documents with the same number.
Partially delivered orders and partially paid invoices. These exist at any cut-off date and need a defined treatment, not an improvisation per case.
Cheques and post-dated instruments in hand. They are assets with dates and they must carry over.
Who can see what. Permissions are usually configured at the end, under pressure, which is how everyone ends up an administrator.
And keep the old system until you are sure
Read-only access to the previous system for a year costs very little and removes the pressure to migrate history you may never need. The project that insists on switching off the old system on day one is the project most likely to migrate badly in order to meet that date.