Master Data Migration for Your New ERP: Checklist

Master data migration is the part of an ERP implementation that decides how the first few weeks in the new system go — and it is roughly 80 percent data preparation and only 20 percent technology. If you inventory every data source, clean up duplicates and legacy clutter, build a solid field mapping, form one authoritative golden record per record, and test the import before it matters, you go live with data you can trust. This guide walks you through the six steps for systematically preparing your master data for the new ERP, backed by a concrete checklist.

Why master data decides the ERP launch

A new ERP is only as good as the data inside it. Wrong articles, duplicate customers, or inconsistent accounts frustrate users from day one and undermine trust in the entire project. At the same time, a system switch is the best opportunity to get rid of years of accumulated data junk instead of simply dragging it along.

The distinction between two types of data matters here. Master data is the permanent core data of your business — the article master, customer master, supplier master, and accounts. Transactional data such as orders, postings, or stock levels is created continuously in day-to-day operations. This checklist focuses on master data, because it forms the foundation for every process and its quality has the longest-lasting effect. The goal is high data quality: complete, unambiguous, current, and in the target format.

Step 1: Inventory your data sources

Before you touch a single record, get an overview. In most companies master data does not sit in one place but is spread across the legacy system, the inventory management tool, the shop, the CRM, Excel lists, and individual department drives.

So for each data object, capture everywhere details about it exist, how many records there are, and what quality they are in. Then designate a leading source for every object — the system whose state prevails in case of doubt. This decision takes a lot of friction out of the project later, because whenever details conflict, it is clear from the start which one wins.

In this step, also clarify which data gets migrated at all. Not everything has to come along: historical documents often stay in the legacy system, which is kept available in read-only mode for the duration of the statutory retention period. That reduces the migration effort while satisfying the GoBD requirements for traceability and immutability of records.

Step 2: Cleaning — remove duplicates and dead records

Cleaning is the most laborious and the most important step. This is where you separate what should go into the new system from what you leave behind.

Detect and merge duplicates

Duplicate records are the most common quality flaw. The same customer shows up three times because they were once entered as "Müller GmbH", once as "Mueller GmbH", and once with a typo. You find duplicates like these via a match code or a fuzzy search that pulls together similar spellings. Review the hits and merge genuine duplicates into a single record — including the history attached to them.

Dead records and formats

Besides duplicates, you need to sort out obsolete records: articles that no longer exist, customers with no revenue for years, suppliers you no longer work with. For the remaining records, fill in missing mandatory fields and standardize formats — addresses, phone numbers, tax numbers, units of measure. Continuous data maintenance keeps this standard up after go-live. A simple rule of thumb: whatever you cannot bring over cleanly now, you definitely do not want in the new system.

Step 3: Define the field mapping

Once it is settled which data comes along and in what quality, you clarify where it belongs in the new system. In field mapping you assign each source field to exactly one target field and define the translation rules.

Pay particular attention to:

• Formats and units: date formats, decimal separators, currencies, and units of measure must match the target system.
• Number ranges: decide early whether article and customer numbers are carried over or reassigned — this affects all dependent documents and the respective number range.
• Value lists: fixed selection values such as country codes, tax keys, or article categories need an unambiguous assignment.
• Mandatory fields in the target: fields the new ERP strictly requires but the source does not deliver have to be filled in beforehand.

Document the mapping as a table — it is the build instruction for the actual data migration and the reference for every later question about why a value ended up where it did.

Step 4: Golden record and MDM

When data from several sources comes together, you need an authority that decides what holds true. That is exactly what the golden record provides.

The golden record as the single truth

A golden record is the one authoritative record per real-world object — a customer, an article — that bundles the best details from every source. To do this, you define survivorship rules: in a conflict, the previously designated leading source wins, or the most recent change date, or the most complete value. The result is a consolidated master with no contradictions.

MDM as a permanent solution

The golden record is not a one-off effort but a state you want to maintain. Master Data Management (MDM) describes the processes and responsibilities that keep master data unambiguous and current over the long term — who creates data, who checks it, who approves it. Even without dedicated MDM software, it is worth establishing clear responsibilities and creation rules during the migration, so the old disorder does not immediately rebuild itself in the new system.

Step 5: Test migration and validation

Only once the data is prepared and mapped do you migrate — but never straight into live operation.

The test migration

In the test migration you run the complete import at least once on a test or sandbox system. You log every error — rejected records, incorrectly mapped fields, violated mandatory entries — and correct the mapping and source data until the run completes cleanly. In practice, this usually takes several passes. That is exactly what the test migration is for: so the errors happen on the test system and not on the go-live weekend.

Validation and sign-off

An import that ran through is not yet proof of correctness. So validate on two levels: quantitatively via totals and counts (Does the record count match? Do balances and stock values match the last stocktake and the open items?) and qualitatively via samples, where the departments check individual records in the new system against the source. Only once the departments formally sign off on their data is the migration ready for the real run. If you lack the internal capacity for this effort, a specialized ERP data migration service supports cleaning, mapping, and test runs.

Checklist: master data migration at a glance

The following checklist summarizes the six steps with their respective outcome — a guide you can tick off during the project.

Which systems offer which import paths and mapping tools varies widely — for a neutral overview of common systems and their import tools, see the ERP directory.

Conclusion

Clean master data is not a by-product of the ERP implementation but the precondition for the new system carrying its weight from day one. Whoever works through the six steps with discipline — inventory the sources, clean consistently, map precisely, form one golden record per record, test the migration, and validate formally — goes live with reliable data instead of imported chaos. The biggest lever lies not in the technology but in the cleaning and in clear responsibilities for data maintenance. Plan enough time for it, involve the departments early, and factor in legal obligations such as GoBD and retention periods from the start — then master data migration becomes the foundation of your new ERP rather than its stumbling block.