ERP Data Migration: How to Plan It Without Surprises

A smooth ERP data migration comes down to deciding early what you will move, cleaning it before the move, and rehearsing the switch more than once. This article walks through the questions teams ask most, from scope to go-live day.

What should you actually move to the new ERP?

Not everything deserves a place in the new system. Start by listing every data group in the legacy system: customers, suppliers, products, open orders, price lists, ledger balances, and history.

Then sort each group into three piles: must be live on day one, can be archived and read-only, and can be dropped. Open invoices and current stock are usually in the first pile. Ten-year-old quotes rarely are.

A common mistake is copying everything because it feels safer. It is not. Every extra record is one more thing to clean, map, and test.

Who owns the data during the project?

Migration is often handed to IT alone. That is how wrong customer terms and duplicate products slip through. IT knows the tables, but finance, sales, and warehouse staff know what the values mean.

Name one owner per data group from the business side. Their job is to approve the cleaned data and sign off on test results. Give one project lead the final say on scope changes.

If the legacy system has an outside vendor, involve them early. Ask for a full export of the structure, not just the records, so you can see how fields relate to each other.

How clean does the data need to be before the move?

Cleaner than you think. A new ERP enforces rules the old system ignored: required fields, unique codes, valid tax numbers, fixed units of measure. Records that passed before may be rejected now.

Clean the data in the source system or in a staging area, not after loading. Fixing errors in the new ERP means fixing them by hand, one record at a time.

Run a few quick checks first. They surface most problems within a day.

• Find duplicate customers, suppliers, and product codes.
• List records with empty required fields, such as tax number or unit.
• Check that units, currencies, and date formats are consistent.
• Flag inactive items that still carry stock or open balances.
• Compare ledger totals in the legacy system against the finance team's own reports.

How do you map old fields to new ones?

Mapping is a document, not a feeling. For each field in the old system, write the matching field in the new ERP, the transformation rule, and who approved it.

Watch for fields that were used for the wrong purpose. A free-text notes column that staff used to store delivery codes is a classic example. Decide where that information belongs now.

Keep the mapping sheet under version control. When a rule changes in week six, everyone should see which version the latest test used.

Which migration approach fits your business?

There are three common approaches. The right one depends on how much downtime you can accept and how complex your data is.

If you are unsure, ask what happens when the system is unavailable for a weekend, and for a week. The answer usually narrows the choice quickly.

How many test runs are enough?

Plan at least two full trial migrations before go-live, using a copy of real data. The first one will fail in ways you did not predict. That is its purpose.

After each run, compare counts and totals: number of customers, stock quantities by warehouse, open receivables, open payables. Then let the data owners work through real tasks, such as creating an order or posting an invoice.

Record every defect with its cause. If the same type of error appears in the third run, your cleaning rules are still incomplete.

What does cutover day look like, and what if it goes wrong?

Choose a quiet period, such as a month-end weekend after closing, and freeze changes in the legacy system at a set hour. Write a timed run sheet that says who does what, in which order.

Agree a fallback point before you start. If checks fail beyond that point, you return to the old system rather than push on. Without that rule, teams tend to keep going under pressure.

Keep the legacy system available in read-only mode for a defined period after launch. Staff will need to look things up, and auditors may too.

What should you do this week?

Write the scope list, name a business owner for each data group, and run the quick checks above on one group, probably customers. You will learn more from that single exercise than from a month of planning meetings.

If the new ERP needs custom screens, integrations, or a web portal tied to your data, budget for that early. You can see how we price this kind of work in our transparent price list, then compare it with your own migration scope.

Finally, book the first trial migration before you feel ready. A date on the calendar forces the cleaning and mapping work to actually happen.