ERP data migration: the checklist that prevents a failed go-live

Ask anyone who has been through an ERP go-live what actually went wrong and you will rarely hear about the software. You will hear that stock did not match, that a supplier appeared three times, that half the sales orders came across without their delivery addresses, and that finance spent the first month reconciling by hand.

Panorama Consulting’s research puts the overall ERP failure rate around 68% and attributes the top three causes — inadequate change management, poor data migration and inexperienced teams — to more than three quarters of failures. Data migration is the one you can most directly control with process.

This is the checklist we work through. It applies whether you are moving to a package or to a custom build.

Phase 1 — Extract, before anything else

Do this at the very start, while you still have unpressured access and while the people who know why things are configured the way they are still work there.

• Master data with internal keys. Customers, suppliers, items, bills of materials, price lists, tax codes, warehouses. Keys matter more than labels, because relationships are worthless without them.
• Open transactions in full. Unfulfilled orders, unpaid invoices, work in progress, stock positions, unreconciled bank items.
• Closed history to an agreed depth. Agree the depth with your accountant and auditor, not by instinct.
• The chart of accounts and every posting rule. Which document type posts where, under which conditions.
• Custom fields and user-defined tables. These hold undocumented business rules and they are where migrations break.
• Every report and saved query anyone uses. Each one is a requirement for the new system, already written.
• The integration inventory. Every system exchanging data, with direction, frequency and format.
• Attachments and documents. Order PDFs, certificates, drawings, signed delivery notes. Frequently forgotten until go-live.

Two rules: export in an open format you can read without the vendor’s tools, and verify every extract against the live system with row counts and control totals. An unverified export is not a backup.

Phase 2 — Profile, and expect these defects

Do not read the schema. Profile the actual values. Every migration we have seen surfaces some combination of the following.

Defect	How it shows up	How to detect it early
Overloaded field	One column carrying two or three different meanings	Sample 200 real values and read them
Duplicate master records	Same supplier under three spellings	Fuzzy match on name, tax number, address
Encoding damage	Turkish, German or Nordic characters corrupted	Search the extract for replacement characters
Unit inconsistency	Grams and kilograms in the same column	Distribution analysis — outliers by orders of magnitude
Date format drift	Dates stored as text in mixed formats	Attempt a strict parse; count failures
Referential orphans	Order lines whose parent no longer exists	Join every child to its parent and count misses
Soft-deleted records	Rows the old UI hides but an export includes	Compare export counts to on-screen counts
Precision loss	Two decimals where three were needed	Recompute line totals and compare
Placeholder values	"TBC", "1900-01-01", "999999"	Frequency count of every column's top values

Produce a written defect list. Every entry gets a named owner in the business and a decision: fix at source, fix in transformation, or accept and document. Unowned defects are not fixed; they are discovered at cutover.

Phase 3 — Decide what not to migrate

The cheapest data problem is the one you leave behind.

• Obsolete master records. Items not transacted in three years, customers who have not ordered since 2019. Archive, do not migrate.
• Deep history. Keep read-only access to the old system for the retention period instead. This single decision removes more risk than any other.
• Fields nobody uses. If profiling shows a column is 96% empty, ask who fills the other 4% and why before carrying it forward.
• Failed workarounds. Data that only exists to compensate for a limitation of the old system. Migrating it institutionalises the limitation.

Write down what you are excluding and get it agreed in advance. “Where is the 2017 data?” is a much better question in a planning meeting than on the Monday after go-live.

Phase 4 — Rehearse, at least three times

This is the part that gets cut when the schedule slips, and it is the part that determines the outcome.

Rehearsal 1 — does it load at all? Structural problems: field lengths, mandatory fields, type mismatches, referential failures. Expect it to fail. That is its purpose.

Rehearsal 2 — is it right? It loads; now reconcile. Record counts by entity. Financial control totals. Stock quantity and value by location. Open order value. Spot check fifty records end to end by eye.

Rehearsal 3 — can we do it under time pressure? A full timed dry run following the written runbook, executed by the people who will execute it on the day, in the same sequence. Record how long each step takes. This produces your cutover timetable, and it is the only way to know whether the window is long enough.

If rehearsal three produces surprises, run a fourth. Moving the date is cheap compared to an unrecoverable cutover.

Phase 5 — Reconciliation rules

Agree these before cutover and get finance to sign them off, because a go-live decision made without agreed criteria becomes an argument at two in the morning.

• Counts per entity: source rows in, target rows out, differences explained line by line.
• Financial totals: trial balance, receivables and payables ageing, stock value. These must match to the agreed tolerance, and “approximately” is not a tolerance.
• Open items: every unfulfilled order and unpaid invoice, individually accounted for.
• Sample verification: fifty records per major entity, checked field by field by someone from the business.
• Negative checks: no orphans, no duplicates on keys that must be unique, no dates in impossible ranges.

Write the acceptance thresholds down. Then decide in advance what you do if a threshold is missed: proceed with a documented exception, or abort. Deciding this in the calm beforehand is worth more than any tooling.

Phase 6 — The cutover weekend

1. Freeze the source. Announce it, enforce it, and confirm nobody is still entering transactions.
2. Final extract, verified against the same control totals as the rehearsals.
3. Load, following the runbook step by step, recording actual times against rehearsed times. Divergence is your early warning.
4. Reconcile against the agreed criteria. Not a spot check — the full set.
5. Smoke test the business, not the software. Take a real order. Pick it. Ship it. Invoice it. Receive a payment. Post it. If a real transaction cannot complete end to end, nothing else matters.
6. Go / no-go decision against the written criteria, by the named person, at the named time.
7. Keep the rollback open. The old system stays intact and available until the first month-end closes cleanly. Rollback is not failure; not having one is.
8. Staff the first week deliberately. Extra support, a visible issue log, daily triage. The first week determines whether people trust the system for the next three years.

Phase 7 — After go-live

• Reconcile daily for two weeks, then weekly for a month.
• Keep a public issue list. Visible progress is what keeps confidence during the inevitable rough patch.
• Do not start the next project until one full period has closed cleanly.
• Retain the old system read-only for the statutory period, and confirm you can actually retrieve a historical document from it before letting any licence lapse.

How to structure the pipeline

The technical shape of a migration matters, because the wrong shape makes rehearsals expensive and therefore rare.

Make it repeatable, and make it code. Extraction, transformation and load should be scripts under version control, runnable end to end with one command. Migrations done by hand through import wizards cannot be rehearsed cheaply, which is why teams that work that way rehearse once and hope.

Keep the three stages separate. Extract to raw files, untouched. Transform into target-shaped files. Load. When something is wrong you need to know which stage produced it, and a single fused script cannot tell you.

Never modify the source system during extraction. Cleanup happens either in the source system deliberately, as a business activity with owners, or in the transformation stage with rules you can read. Ad hoc edits during a load are how two rehearsals produce different results for reasons nobody can reconstruct.

Make every transformation rule inspectable. “Supplier name is trimmed, uppercased and matched against tax number; unmatched records go to an exception file.” Written down, reviewable by someone in the business. Rules embedded in code comments are rules nobody outside the team can validate.

Route rejects to an exception file, do not drop them. A load that reports success while silently discarding 400 rows is the worst possible outcome, because it is invisible until someone notices a customer missing months later.

Log everything with counts. Rows in, rows transformed, rows loaded, rows rejected, per entity, per run. This log is what makes reconciliation a comparison rather than an investigation.

The people side, which fails more often than the technology

Panorama Consulting names change management alongside data migration in its top three failure causes, and in practice the two are the same project.

• Cleanup needs named owners with time allocated. “The purchasing team will clean supplier data” is not an assignment. A named person, a defined data set, a deadline and a slot in their week is.
• Make the defect list visible. A shared list with owners and status does more for progress than any status meeting.
• Explain why the data matters to the people doing the cleanup. “Fix these 300 records” is drudgery. “These 300 records are why the new system will get your stock figures right” is a reason.
• Expect resistance where the data reveals something. Duplicate records and inconsistent codes sometimes exist because somebody found them convenient. Surfacing that is part of the work, and it needs handling as a management matter rather than a data one.
• Do not let the go-live date become a matter of pride. The people who will have to live with a bad cutover are rarely the people who set the date.

Who does what

The single most common structural mistake is expecting the software supplier to own data quality. They cannot. They do not know which of three supplier records is correct, or which of two part numbers your customers actually order by.

A workable split: the supplier owns extraction tooling, transformation logic, load performance and the technical runbook. Your business owns cleanup decisions, reconciliation sign-off and the go/no-go call. Both own rehearsals jointly. Write this down at kick-off.

Our approach to migrating off a live system is set out on the ERP data migration page and in the migration guide. Delivery bands and timelines are on the pricing page, and a specific migration can be scoped through the quote form.

Frequently asked questions

How much time should data migration get in the project plan?

More than the plan you were given, and much of it belongs to your team rather than the supplier's. A useful rule: if migration is under 20% of the total effort on a system replacement, someone has assumed the data is clean. Nobody's data is clean. Panorama Consulting places poor data migration among the top three causes of ERP failure.

How many rehearsals do we need before cutover?

Three complete ones, minimum. The first finds structural problems, the second finds data problems, the third proves the runbook and its timings. If rehearsal three still produces surprises, you are not ready — hold the date rather than hoping.

How much history should we migrate?

Less than instinct suggests. All open items, plus enough closed history for comparative reporting — typically two to three years. Everything older is better served by read-only access to the old system for the retention period. Migrating a decade of history multiplies risk for value almost nobody uses.

Who should own data cleanup?

Named people in the business, not the software supplier and not IT. Only the person who runs purchasing can decide which of three duplicate supplier records is correct. Assign owners per data domain, with a deadline, and track defects as a visible list. Unassigned cleanup does not happen.

What is the most common single defect?

A field used for different purposes by different teams — a notes field that is a delivery instruction to one department and a payment condition to another. Migrating it faithfully migrates the ambiguity into a system that now depends on it. These only surface by profiling actual values, not by reading the schema.

Should we clean data before or after migration?

Before, in the source system where possible. Cleaning after migration means your new system launches with known-bad data and everyone's first impression is that the new system is wrong. Clean at source, then migrate, then verify.

Related guides

• Migrating off SAP Business One: the options, the order, and what to extract first
• When does it make sense to leave SaaS and build your own?
• Gulf e-invoicing: what ZATCA and the UAE mandate actually require from your systems

Service page: Migration guide