How Do You Plan a Data Migration When Replacing a Business System?

The short answer

A data migration plan sets out exactly what data will move to the new system, who owns it, how it will be cleansed and transformed, and how each load will be proven correct before go-live. The most important principle is that the business, not the vendor, owns the data and signs off the result. Plan for several reconciled trial loads, because the first one almost never works cleanly.

Why does data migration cause so many delays?

Data looks simple from a distance: extract it from the old system, load it into the new one. Up close, it is full of decisions. Duplicate customers, inactive products, free-text fields used for three different purposes, and balances that do not quite match the general ledger are all normal in systems that have run for years.

These issues only surface when someone tries to map the data into a new structure with stricter rules. If that happens late, go-live slips. Starting the data workstream at the same time as design is one of the most effective ways to protect a programme timeline, a point we also make in our ERP implementation guide.

Step 1: Define scope and ownership

List every data domain the new system needs, and name a business owner for each. A typical scope might include:

Owners decide what is in scope, approve cleansing rules and sign off reconciliations. Without named owners, these decisions drift.

Step 2: Decide how much history to bring

Migrating all history sounds safe but increases cost, complexity and testing effort, and may carry poor-quality data into a clean system. Common options include:

• Balances and open items only, with history kept in an archive
• Balances plus a limited period of transactional history for trend reporting
• Full history, usually only where there is a strong operational or regulatory need

Consider legal and regulatory retention requirements for financial, employee and customer records, and make sure archived data remains accessible and secure for as long as you need it.

Step 3: Profile and cleanse the data

Before mapping, profile the source data to understand its real condition: completeness, duplicates, invalid values, and inconsistent formats. Then agree cleansing rules with data owners, for example:

• Merge duplicate customer records using an agreed matching rule
• Exclude products with no sales or stock movement in a defined period
• Standardise addresses and phone formats
• Verify supplier bank details before migration to reduce payment fraud risk

Decide where cleansing happens. Fixing data in the source system is often best, because it benefits the business immediately and keeps loads repeatable. Transformations applied during migration should be documented and testable.

Step 4: Map fields and transformation rules

Create a mapping specification that shows, for each target field, where the data comes from and any rules applied. Pay particular attention to:

• Code changes, such as a new chart of accounts or product numbering
• Fields that are mandatory in the new system but optional or empty in the old one
• Default values, and who approved them
• Relationships between records, such as customers, contacts and sites

Keep the mapping under version control. It will change as trial loads reveal issues.

Step 5: Run trial loads and reconcile every one

Plan for several trial migrations, typically aligned with testing cycles. Each should be fully reconciled using:

1. Record counts by entity, compared between source and target
2. Control totals, such as debtor and creditor balances, stock values and leave balances
3. Sample checks of individual records by business users
4. Exception reports listing records rejected and why

Data owners sign off each trial. Later trials should also be timed, so you know how long the final load will take during cutover. A useful rule is that the final trial load should be a full dress rehearsal of the cutover sequence.

Step 6: Plan the cutover load

The cutover plan should cover:

• When transactions freeze in the old system
• The sequence of extracts, loads and reconciliations
• Who signs off each step, and the go/no-go criteria
• How transactions during the freeze period are captured and entered
• What triggers a rollback, and how it works

Step 7: Decommission and archive the legacy system

After go-live, do not simply switch off the old system. Decide how archived data will be accessed for audits, customer queries and legal obligations, then retire the system securely. Running old systems indefinitely 'just in case' adds cost and security risk. If you are still deciding whether to replace a system at all, see our article on whether to replace or modernise a legacy system.

Common data migration mistakes

• Leaving data to the implementation partner without business ownership
• Starting cleansing after testing has begun
• Migrating everything because nobody decided otherwise
• Accepting a load without reconciling control totals
• Forgetting privacy obligations for personal information in test environments

Independent leadership for data migration

The Technology Office leads data migration as part of our technology and systems transformation service, acting as independent, owner-side leadership that sells no software and takes no implementation margin. We make sure data ownership, retention decisions and reconciliation standards are set before vendors start building, and that go-live decisions are based on evidence rather than optimism.

We work with businesses of any size and industry across Australia, and our data and technology strategy work helps ensure the data you migrate is the foundation for better reporting, not a copy of old problems.