ERP Data Migration: Why Your Master Data Is a Business Problem, Not an IT Task

Picture it: three weeks before go-live, the first full test load runs into the new ERP. Four thousand customers come across, but six hundred of them are duplicates, two hundred have no VAT number, and nobody can say which of the three delivery addresses for your largest customer is the right one. The item master has units of measure that only the warehouse understands. Prices come over, but the discounts were in a spreadsheet. The ERP data migration was on the plan as one line in the last month. It has just become the critical path.

Some version of this happens in a lot of ERP projects, whatever the software. Not because the migration tooling is bad, but because the problem was given to the wrong people at the wrong time. Below is why, and how to plan it so the data is ready when the system is.

ERP data migration is two jobs, not one

When people say data migration they usually mean the technical job: extract data from the old system, map the fields, transform it and load it into the new one. That job is real, and your partner or IT team can do it. But there is a second job hidden inside it, and that one decides the outcome: deciding what the data should be.

• Which of the two customer records for the same company is the real one, and who decides?
• Do the 9,000 items in the old system all still exist, or are 4,000 of them products you stopped selling years ago?
• Is the price in the system the price you actually charge, or does the sales team apply a discount from memory?
• Which supplier payment terms are agreed, and which were typed in once and never checked?

No consultant and no IT department can answer those questions. They can find the duplicates and the gaps. Only someone who runs the customer relationship, the purchasing or the product range can say which version is true. That is why ERP data migration is a business problem first.

Give every master data object an owner

The single most useful thing you can do is name one person in the business for each master data object, early in the project. Not a committee and not “finance”, a name.

• Customers: usually sales operations or customer service.
• Suppliers: purchasing, with finance for bank details and payment terms.
• Items and bills of materials: the product or supply chain lead.
• Prices and discounts: whoever signs off on pricing, which is often a commercial director.
• Chart of accounts and open balances: finance.

The owner decides the rules (what makes a customer record complete, when an item is obsolete), approves the cleaned data, and signs off on the test migrations. They also stay the owner after go-live, which matters more than it seems: a clean customer master degrades within months if nobody is responsible for keeping it that way.

Start cleaning before the build, not after it

Data cleanup does not need the new system. You can remove duplicates, close inactive customers, block obsolete items and fill in missing VAT numbers in the system you have today. The earlier you start, the more of it is done calmly by people who know the data rather than in a rush by the project team.

A practical order:

1. Agree what will not move. Customers without a transaction in the last two or three years, items not sold or bought in the same period, closed suppliers. Every record you leave behind is one you do not have to clean, map and test. Keep the old system or an archive for look-ups.
2. Fix the records that will move, in the old system, so the business keeps working with the corrected data in the meantime.
3. Decide the new structures: item categories, customer groups, units of measure. A new ERP is the one chance to change them without a separate project.
4. Write down the transformation rules in plain language, so the business owner can check them and the technical team can build them.

Run test migrations with real data, and more than once

The first full test load always fails in some way. That is its purpose. Plan at least two full test migrations before go-live, three if the data is complex, each followed by reconciliation by the business owners: do the customer count, the open receivables, the stock value and the open orders match the old system?

When we built Waterlogic’s ERP systems, Hungary went live in 12 weeks and the Czech Republic was ready in 16. Data migration ran as its own workstream in parallel with configuration and testing, not as a phase at the end. In the Czech Republic the migration was validated and reconciled at every stage. The Czech system did not go live. The client then halted the go-live because other priorities came first: a global project across 17 countries took precedence within the enterprise. Treating data as part of the project from week one is not a special technique.

What to reconcile

• Record counts per object, against what you agreed would move.
• Open balances: receivables, payables and the general ledger trial balance.
• Stock quantities and values per warehouse.
• Open sales and purchase orders, line by line for the largest ones.
• A sample of real transactions, run end to end in the new system by the people who will use it.

The cutover weekend is not the time to find out

The final migration should be a repeat of a test you have already passed, with a timed runbook and a clear go or no-go moment. If anything in the last test load needed manual fixing, either automate the fix or make it part of the runbook with an owner. And decide in advance what happens to transactions in the gap between the last extract and go-live, because invoices and orders do not stop for the weekend.

A practical checklist

1. Name a business owner for every master data object in the first month of the project.
2. Agree what will not be migrated, and archive it.
3. Clean the remaining data in the current system, starting now.
4. Decide new structures and write transformation rules the business can read.
5. Run at least two full test migrations with real data, each reconciled and signed off by the owners.
6. Make the cutover a repeat of a passed test, with a runbook and a go or no-go moment.
7. Keep the owners responsible after go-live, so the data stays clean.

The bottom line

ERP data migration goes wrong when it is treated as a technical load at the end of the project. The software can move almost any data. What it cannot do is decide which data is true. Give that job to named people in the business, start cleaning in the system you already have, and test the migration as seriously as the configuration. Then the last month before go-live is about training and cutover, not about duplicate customers.

How to Run a 12-Week ERP Implementation

Dynamics NAV End of Support: What to Decide Before January 2028

Your First Year-End Close on a New ERP: A Practical Plan

Case study: Waterlogic Czech Republic, ready in 16 weeks, go-live halted

Business Analysis service

Sources

Rand Group: ERP data migration checklist, what to clean, map, test and validate