25 August 2026 · TechSlideITS
What ERP data migration actually involves
Migration is quoted as a task and behaves like a project. It is also the stage most likely to delay a go-live, and almost always for the same reason.
Data migration appears on most implementation plans as a line item with a number of days against it. It behaves like a project with its own risks, and it is the stage that most often pushes a go-live date.
The reason is consistent: everyone underestimates how bad the existing data is, because in the old system nothing forced it to be good.
Decide what actually moves
Four categories, and they need different decisions.
Masters — items, customers, suppliers, employees, vehicles. These must move; the new system cannot function without them.
Opening balances — stock, receivables, payables, loan balances. These must move and must be correct, because everything afterwards is calculated from them.
Open transactions — pending orders, unbilled work, partly received purchases. These must move or be closed out before cutover. Deciding which is a real choice.
History — completed transactions from previous years. This is where the argument happens, and the answer is usually far less than people want.
The history question
The instinct is to bring everything. It is expensive, it is slow, and it imports data quality problems into a clean system.
A common position: keep the old system readable for a defined period, migrate summary balances rather than transaction detail, and let history accumulate naturally.
Businesses that insist on full historical migration usually spend a disproportionate share of the project on it and then find nobody queries the migrated history anyway.
Cleaning is not a technical task
The part vendors cannot do for you.
Duplicate items under three spellings. Customers who are the same party twice. Suppliers with stale details. Stock figures never physically verified. Balances that do not tie.
Deciding that two records are the same party, or that a stock figure should be corrected, requires someone who knows the business. A vendor can find suspected duplicates; only you can confirm them.
This is the single biggest cause of delay, and the only real mitigation is starting it early — before the software is configured, because it does not depend on the software at all.
Migrate bad data and you publish it
Worth being blunt. In separate registers, poor data is tolerable because nobody reconciles them.
In one system it is visible, and users conclude the new system is wrong. Once that belief takes hold, the parallel spreadsheet returns, and the project is in trouble for reasons that have nothing to do with the software.
Validate before you rely on it
- Record counts in and out, category by category
- Total values tying to the old system — stock value, receivables, payables
- Sample records checked in detail, chosen by someone who knows what right looks like
- A test transaction through each major process using migrated data
- Sign-off by the business, not the vendor
The last matters. Vendor-validated migration checks that the data moved. Business-validated migration checks that it is right.
The cutover itself
The gap between the last transaction in the old system and the first in the new. Whatever happens in that window is recorded somewhere or lost.
Plan it deliberately: a quiet period, a documented freeze, a manual record of anything unavoidable during the gap, and a defined point at which the old system becomes read-only.
Cutovers that drift — where both systems accept entries for a while — produce reconciliation problems that outlast the project.
If you want migration planned rather than quoted as a line item, see how we handle implementation or talk to us.
Frequently asked questions
Four different decisions: masters that must move, opening balances that must move and be correct, open transactions that must either move or be closed before cutover, and history — where the answer is usually far less than people want.
Usually much less than instinct suggests. A common position is keeping the old system readable for a defined period, migrating summary balances rather than transaction detail, and letting history accumulate going forward. Full historical migration consumes a disproportionate share of the project and is rarely queried afterwards.
Because it is not a technical task and the vendor cannot do it. Deciding that two records are the same customer, or that a stock figure should be corrected, requires someone who knows the business. The only real mitigation is starting early — it does not depend on the software being ready.
You publish it. In separate registers poor data is tolerable because nobody reconciles them; in one system it becomes visible and users conclude the new system is wrong. Once that belief sets in, the parallel spreadsheet returns and the project is in trouble for non-technical reasons.
Record counts by category, total values tying to the old system, sample records checked by someone who knows what right looks like, a test transaction through each major process using migrated data, and sign-off by the business rather than the vendor. Vendor validation confirms data moved; business validation confirms it is right.