How long does data migration take? In an ERP project, the honest answer is: most of the programme. The final load at cutover may take a weekend. But getting the data ready to load cleanly takes months. On the mid-sized programmes I have run, I plan roughly six to nine months of active migration work, starting during design and ending at go-live. That covers profiling, cleansing, three mock loads and a dress rehearsal. Larger, multi-country programmes take longer.
Those figures are my planning experience, not a benchmark. Your timeline depends on how many legacy systems you have, how dirty the data is, and how quickly the business can make decisions about it.
What is data migration in ERP?
Data migration in ERP means moving the data your business runs on out of old systems and into the new one, in the new format, so that day one works. It covers two kinds of data.
- Master data: customers, suppliers, materials, the chart of accounts, employees, assets. It changes slowly and everything else depends on it.
- Open transactional data: open purchase orders, open sales orders, open invoices, stock balances and opening balances. These are loaded as late as possible, at cutover.
Each data object, such as customers or open purchase orders, goes through the same cycle: extract from the old system, transform to the new format, load, then reconcile to prove nothing was lost or changed.
How long does data migration take? A realistic timeline
- Months 1 to 2Profile the legacy data and agree object owners
- Months 2 to 4Map fields, write rules and start cleansing at source
- Month 4Mock load 1: prove the tools and find the gaps
- Month 6Mock load 2: full volumes, timed, reconciled
- Month 7Mock load 3: production-like, signed off by the business
- Month 8Dress rehearsal: the cutover run hour by hour
- Go-liveFinal load, reconciliation and sign-off
Notice that the loads themselves are short. The time goes into the gaps between them, where the team fixes what each load revealed.
Three things stretch this plan more than anything else. First, more source systems: every extra legacy system adds its own mapping, its own duplicates and its own owners. Second, a design that keeps changing, because each change to the target means remapping and reloading. Third, slow business decisions about which records to keep. Plan a buffer of at least one extra cycle if any of these apply to you.
Profiling and cleansing: where the time really goes
Profiling means measuring the data before you touch it: how many records, how many duplicates, how many blanks in fields the new system requires. It turns 'our data is fine' into numbers. Do it in the first two months, because it sets the size of the cleansing job.
Cleansing means fixing the data, ideally in the old system so the fix survives every reload. Merging duplicate customers, closing old purchase orders and filling missing fields is business work, not IT work. Only the people who use the data can say which of two supplier records is correct. That is why cleansing so often runs late: it competes with the day job.
Mock loads 1 to 3, the dress rehearsal and error-rate targets
A mock load is a full practice migration into a test environment. Three is the usual minimum, followed by a dress rehearsal. Each one has a different job.
- Mock load 1 proves the extract, transform and load tools work end to end. Expect lots of errors. That is the point.
- Mock load 2 runs at full volume. Time every step so you know how long cutover will take.
- Mock load 3 should look like production. The business tests with the loaded data and signs off the reconciliation.
- The dress rehearsal runs the real cutover plan, in order, against the clock, with the people who will do it on the night.
Track an error rate for every object in every cycle: records rejected divided by records extracted. Set a target before each load so 'good enough' is agreed in advance, not argued about afterwards.
Illustrative targets from my own planning, not research. Critical objects such as opening balances usually need zero errors.
Is data migration hard? Why it is the number one go-live risk
Yes, data migration is hard, and in my experience it is the risk most likely to stop a go-live. Configuration can be fixed after launch. Wrong opening balances, missing customers or duplicate suppliers break invoicing, payments and month-end on day one.
The research backs this up. Bloor Research's 2011 survey, reported by Network World in 2015, found that 38 percent of data migration projects ran over time or budget, with an average overrun of $268,000. Gartner research from 2020, cited on its data quality page, puts the cost of poor data quality at $12.9 million a year for the average organisation. And in Panorama Consulting's 2021 ERP Report, data issues were among the top reasons for timeline overruns.
- 38%of data migration projects overran on time or budget
- 268Kaverage overrun cost, in US dollars
Source: Bloor Research, 2011 (via Network World, 2015)
Data readiness for go-live
- Every object has a named business owner who has signed off
- Three mock loads completed, with error rates trending to target
- Dress rehearsal finished inside the cutover window
- Reconciliation signed off for counts and financial totals
- Cleansing done at source, not patched in load files
- A fallback plan agreed if the final load fails
Data problems are one of the patterns behind why ERP implementations fail. For where migration sits in the wider plan, see how long an ERP implementation really takes.
Tracking data migration in ProjectCAPEX
ProjectCAPEX has a data migration register built for this. You list each data object with its owner, status and error rate target. Each load is recorded against a cycle: Mock load 1, 2 or 3, Dress rehearsal or Cutover. Enter records extracted, loaded and rejected, and ProjectCAPEX works out the error rate when you save. Cutover tasks, testing and the RAID log sit in the same programme, so a data risk can be raised and tracked where the steering committee will see it.
To see load cycles and error rates on a working programme, try the demo or start free.