It's often the largest share of an ERP project's effort and almost never appears properly on the quote. Why, and how to approach it.
A vendor promises you an ERP in six weeks. They're sincere: configuration does take six weeks. What they haven't priced is moving your existing data into the new system.
It's regularly the longest phase of the project, and it's the one that decides whether it succeeds. A perfectly configured ERP fed doubtful data produces exactly what you had before: two people, two numbers.
Why it always takes longer than planned.
Your data is dirtier than you think. The same client exists four times over — “ABC Construction”, “A.B.C. Construction”, “ABC Const.”, “Abc construction inc”. Three different addresses, two tax numbers. Nobody knew, because nobody had ever looked at fifteen thousand rows at once.
The rules were never written down. A product code starting with X means a discontinued item: that's been in one person's head for eleven years, and they're on holiday during the migration.
History has no structure: seven years of invoices with numbering that changed three times, tax rates that moved, a chart of accounts rebuilt along the way.
And you have to arbitrate, not just transfer. Seven years of history or two? Balances only, or detailed entries? Clients inactive for five years? Every answer has a cost, and these are business decisions — they're yours, not the vendor's.
The rule of three passes.
A successful migration happens at least three times before the real one. Pass 1, discovery: migrate everything without cleaning, to see what breaks. The error report is the deliverable — it surfaces the duplicates, the empty required fields, the inconsistent formats.
Pass 2, validation: migrate the cleaned data and reconcile the totals. Does the global client balance match to the cent? Inventory value? The general ledger? If a discrepancy appears, you don't document it: you understand it.
Pass 3, the dress rehearsal: a complete migration under real conditions, timed. It gives you the length of the cutover window and proves the procedure works. It's also the pass that makes the rollback plan credible. A project that plans only one discovers its problems on cutover day, with the company at a standstill.
What only you can do.
The vendor moves the data. They can't decide which of the four “ABC Construction” records is the right one. That part of the work is yours, and it can't be compressed. Assign someone from your team, seriously available — not “when they have time”. That's the variable that sets the project's duration, more than the vendor's competence.
A migrated figure has to reconcile. If it doesn't, we don't go live.●
We don't “document the discrepancy” — a discrepancy accepted at go-live becomes a permanent one, and it destroys trust in the system within weeks.
What we don't do.
We never cut the whole company over at once. A pilot department running parallel entry for four to six weeks costs time and removes the risk. A full overnight cutover looks brave until the first Monday morning.