Data migration: the workstream that quietly decides your go-live

Ask a steering committee what worries them about an ERP program and you will hear about budget, timeline and user adoption. Almost nobody says “data.” Yet in my experience, when a go-live date slips, the proximate cause is more often the data migration than any other workstream: master records that will not load, balances that will not reconcile, and a legacy system whose data quality nobody had honestly assessed.

The root cause is structural. Data migration sits between teams — the legacy system owners, the new-system consultants, and the business users who actually know what the data means — and work that sits between teams tends to be owned by no one.

Profile the legacy data before you plan anything

The first deliverable of any migration workstream should be a data quality profile: for each major object (suppliers, customers, items, projects, cost codes, open transactions), how many records exist, how many are active, how many are duplicates, and how many fail basic validation. This takes a few weeks of query work and it changes the plan every single time.

On one project we discovered that of 14,000 supplier records, fewer than 3,000 had transacted in three years, and over 1,200 were duplicates created because search was slow and users found it easier to create a new record than find an old one. Migrating all 14,000 would have poisoned the new system on day one.

Decide what does not move

The bravest and most valuable migration decision is what to leave behind. My default rules for a construction or enterprise environment:

• Master data: migrate active records only — typically anything with movement in the last 18–24 months — after de-duplication and enrichment. Archive the rest.
• Open transactions: migrate open POs, unpaid invoices, open project commitments and retention balances in full. These are the records users will touch on day one.
• Closed history: do not migrate transaction-level history into the ERP. Keep the legacy system readable, or extract history into a reporting database. Loading five years of closed vouchers costs enormous effort and delivers almost nothing.
• Balances: migrate opening balances at a clean cut-off date, reconciled and signed by Finance — not by IT.

Cleansing is a business task with IT support — not the reverse

IT can find duplicates; only the business can say which supplier record is the real one, which cost code maps to which new structure, and which project is genuinely closed. Every cleansing decision needs a named business owner, and the mapping sheets need sign-off the same way a design document does. When cleansing is delegated to the implementation consultants, you get technically valid data that is operationally wrong.

Plan three loads, not one

A migration you run for the first time at cutover is a gamble. The pattern that works:

1. Trial load 1 — early, expected to fail, exists to expose mapping errors and validation rules.
2. Trial load 2 — full volume, timed, reconciled, used for user acceptance testing so people test against their own data.
3. Cutover load — a rehearsed, scripted event with a reconciliation checklist and a signed acceptance from each data owner.

The timing data from trial load 2 matters more than people expect: if the full load takes 30 hours, your cutover weekend plan just changed.

Reconciliation is the exit gate

Define, in advance, the reconciliation reports that prove the load: supplier balances legacy vs. new, open PO totals, project commitment totals, trial balance by account. Finance signs each one. “The load completed without errors” is a technical statement; “the balances reconcile and Finance has signed” is a business one. Only the second permits go-live.

Staff it like it matters

Because migration sits between teams, it needs a named lead with time actually allocated — not a shared responsibility spread across the ERP project manager, a DBA and “the departments.” In my plans the migration lead owns the object list, the mapping sheets, the load schedule and the reconciliation pack, and reports migration status as a standing item in the weekly project meeting from month one — not from the month before cutover. The cost of this role is trivial against the cost of a slipped go-live.

Budget honestly, too. Across projects I have seen, data work consumes fifteen to twenty-five percent of total implementation effort when done properly. Plans that allocate five percent are not more efficient; they are simply deferring the effort to the most expensive possible moment — after go-live, when wrong balances are live balances and every correction is an audit conversation.

Data migration will never be the glamorous workstream. But it is the one where a few weeks of early, unglamorous profiling work buys back the months that projects otherwise lose at the end — when the date is public and every day of slip is expensive.