How to Prepare Company Data for Migration
A checklist for cleaning master data, agreeing history depth and reconciling balances before an ERP migration — the work that decides how the project goes.
Data preparation is the part of a migration that a company can start before choosing anything, and the part that most influences how the project goes. It is also the only part that pays off even if the migration is postponed.
Start with the four master data sets
Partners. Duplicates are the norm: the same customer entered twice with different spellings, an inactive supplier that still appears in dropdowns, contacts stored in a name field. Decide the identifying attribute (registration number, VAT ID, internal code), then de-duplicate against it.
Products. Check unit consistency, obsolete items still marked active, items that exist only to support an old workaround, and codes that encode meaning nobody remembers.
Price lists and discounts. These often contain the most undocumented business logic in the company. Write down the actual rules — who gets which price, under what condition — before anyone tries to reproduce them in a new system.
Warehouses and locations. Confirm the structure that will exist after go-live, not the one that grew historically.
Agree the history depth explicitly
The most expensive unmade decision in a migration is how far back document history goes. Make it a written decision, based on:
- what operations need (open documents, balances);
- what reporting needs (comparison periods);
- what regulation requires in your country;
- what can stay accessible in the legacy system read-only instead of being migrated.
Every additional year of history multiplies migration runtime, validation effort and testing surface.
Reconcile balances before, not after
Opening balances — stock quantities, receivables, payables — are the numbers that must match to the unit. Prepare them in advance:
- run a stock count, or at least a count of the items that matter;
- age the receivables and confirm disputed items;
- close what can be closed before cut-over.
Migrating unresolved discrepancies means arguing about them later in a system nobody blames yet.
Document the exceptions
Every company has them: the customer invoiced differently, the product measured in two units, the warehouse that behaves like a customer. These exceptions are business rules. If they are not written down, they will be discovered during user acceptance testing, when changing the design is expensive.
Practical checklist
- Duplicate partners identified and merged
- Inactive partners and products marked
- Units of measure consistent
- Price list rules documented
- Warehouse structure confirmed
- History depth agreed in writing
- Stock counted for critical items
- Receivables and payables aged and reviewed
- Known exceptions documented
- Owner assigned per data set
Who should do this
Not IT alone. Each data set needs a business owner who can decide — sales for partners and prices, the warehouse for stock, finance for balances. The migration team maps and moves data; only the business can say which version is correct.
The payoff
Clean master data shortens every subsequent phase: mapping is simpler, migration runs faster, reconciliation has fewer differences to explain, and users testing the new system see their own data rather than noise.
If a migration is on your roadmap, our methodology describes how data mapping and validation fit into the wider project — and what the analysis phase can tell you before you commit.