ERP Data Migration Checklist: Inventory, Cleansing, Mapping and Test Loads

Data migration is one of the least glamorous parts of an ERP project, and one of the most important. A new system is only as reliable as the records it starts with. If customers are duplicated, stock counts are out of date or supplier terms are missing, those problems move straight into the new environment and appear in daily work.

This ERP data migration checklist follows the order most projects find useful: inventory, ownership, cleansing, mapping, trial loads, cut-over and validation. It is written for the managers who will sign off the move and for the people who will check the results on the ground.

Use it as a working document rather than a one-off read. Each stage produces something you can review, and gaps found early are usually easier to fix than problems discovered after go-live.

Where an ERP data migration checklist starts: inventory

You cannot migrate what you have not listed. The first task is to find where the business's records actually live, including the places nobody thinks of as systems.

Systems, spreadsheets and paper

Start with the obvious sources, such as the existing accounting package, a CRM, an ecommerce platform or a stock tool. Then look for the less obvious ones: shared spreadsheets, email attachments, supplier price lists kept on a desktop and paper records that still feed a process. Excel workbooks in particular often hold rules, mappings or prices that exist nowhere else. For each source, note:

• What it holds, such as customers, suppliers, products, open orders or balances
• Who owns it and who updates it day to day
• How far back the history goes and how often it changes
• Whether it contains personal data, which needs extra care

Once the list exists, give each source a named owner and a rough view of how much work it will need, so the effort is visible before the project starts.

Decide what history you really need

Not all historical data needs to move. Open orders, current stock, live customer and supplier records and open balances usually matter most. Older transactions may be needed for reference, but they can often sit in a read-only archive rather than the live system. The decision should involve the people who use the data every day, not the migration team alone. UK GDPR expects personal data to be kept no longer than necessary, so a migration is a sensible moment to question what is still needed. Take professional advice on your own situation.

Set ownership and rules before anything moves

Migration goes faster when every dataset has a named owner and the team agrees what counts as correct before any file is touched.

Name an owner for each dataset

Customer records might belong to sales, supplier records to purchasing, product data to operations and balances to finance. Each owner signs off their own data at every stage. Without named owners, questions about duplicates or missing fields drift between departments, and nothing gets decided.

Agree the business rules in writing

Some rules must be written down before cleansing begins. What makes a customer active? How are duplicate suppliers merged? Which product codes are retired? Which old tax codes map to which new categories? Record each rule in plain language, note who approved it and keep the list visible to the whole project. Agree too who can overrule a rule and how that decision is recorded, so exceptions do not quietly become the norm.

Cleansing: fix the data before it moves

Cleansing is where most of the tedious work happens. Records are far easier to correct in the source system than to repair after they have been loaded into a new one.

Problems to look for

Source data often shows the same kinds of problems, which become easier to spot once you know what to look for:

• Duplicate customers and suppliers, often with slightly different names or addresses
• Required fields left blank, such as payment terms, tax status or units of measure
• Inconsistent formats, for example phone numbers, postcodes, dates and product codes
• Out-of-date records that should have been closed or archived
• Stock items with no clear location or unit of measure

Sorting the issues by impact helps. A duplicate supplier that blocks payments matters more than a missing note on an old quote.

Cleanse at the source where you can

Where possible, correct the data in the existing system, so the cleaned version is also the one the business keeps using until cut-over. Cleansing only inside an extract creates a second version of the truth, which someone will eventually have to reconcile. Track every change, including who made it and why, so the work can be reviewed later.

Map old fields to new fields

Mapping is the bridge between the old structure and the new one. It is where meaning is most easily lost, so it needs a written record that anyone on the project can read.

Build a mapping sheet

A mapping sheet lists each source field, the target field it feeds, any conversion applied and the person responsible. Keep it under version control, because it will change several times during the project. A simple layout covers most needs:

• Source system, and the table or sheet name
• Source field, with one real example value
• Target field in the new system
• Conversion rule, such as splitting a name or converting a unit
• Owner, status and the test cycle in which the mapping was last checked

Handle the awkward cases explicitly

Some fields do not map one to one. One old field may hold a customer type that becomes two fields in the new system, or a stock location may need to be split into site, aisle and bin. Where the mapping is uncertain, write down the choice made and the reason, so it can be revisited if the output looks wrong. Units of measure and tax codes are common examples. Test any conversion with a known item and check the result by hand before trusting the rule across the whole dataset.

Trial loads and reconciliation

A trial load is a rehearsal. Each run exposes errors, and each correction brings the final move closer to clean.

Run trial loads on copies, not live data

Load the extracted data into a test environment and examine the results. Expect the first run to reveal failures, such as rejected records, cut-off text or references to items that were never created. Log each issue, fix the source or the mapping and run again. Repeat until the results are predictable.

Reconcile totals, not just row counts

A matching count of rows does not prove the data is right. Reconcile control totals, such as the value of open orders, the balance of each account, the quantity of each stock item and the number of active customers. Check a sample of records by hand, especially those with complex relationships. Every difference should be explained, not explained away.

Involve the business in testing

Ask the people who use each area to check the results in the system, not only in a report. A buyer who knows a supplier well will spot a wrong address faster than any checklist. Their sign-off is what turns a technical load into a dataset the business can trust. Keep those sign-offs with the mapping sheet, so the evidence travels with the project.

Cut-over: the final move

Cut-over is the planned point at which live work stops in the old system and starts in the new one. It should be rehearsed as carefully as anything else in the project.

Plan the freeze

Decide when changes to the old system will stop, and communicate that moment clearly. Orders, invoices and stock movements raised after the final extract have to be captured somehow, so the freeze should be as short as the business can manage. Agree in advance who handles any work that arrives during the window.

Run the final extract and load

The final extract should follow exactly the steps used in the last trial load, with no unrecorded manual edits. Run the load, reconcile the control totals again and collect sign-off from each data owner before the new system takes live transactions. If anything differs from the last rehearsal, stop and understand why before continuing.

Keep a fallback plan

Agree in advance what happens if the load fails or the reconciliation does not match. Options usually include postponing the go-live, returning to the old system and rerunning the load, or keeping the old system in read-only mode while issues are resolved. A plan written before the event saves a great deal of argument during it.

Validation after go-live completes the ERP data migration checklist

The migration is not finished when the system goes live. It is finished when the business has run a full cycle on the new data and nothing important is missing.

Check the first live transactions

Watch the first orders, invoices, purchase approvals and stock movements closely. Compare key figures against the old system's final position and against what people expect to see. Problems often surface when reports bring together data from several areas for the first time. Keep one familiar order in mind and trace it all the way through, because a single traced example often reveals gaps that totals hide.

Keep a defect log with named owners

Record every issue raised after go-live, with its severity, owner and expected fix date. Review the log daily for the first few weeks. Patterns in the log often point to a mapping or cleansing gap rather than user error, which is worth knowing before anyone blames the software.

Retire the old source with a date and a record

Once the new system is stable, make the old source read-only, keep an archive in a controlled location and write down what the archive contains and where it lives. Two live versions of the same records invite confusion, so the old source should not be used for live work after the agreed date.

FAQ

Final thought

A good data migration is careful, unglamorous work. This checklist keeps attention on what matters: knowing what data you hold, agreeing who owns it, fixing it at source, mapping it with a written record, proving it through reconciliation and making the cut-over with a fallback plan in place. Each stage makes the next one easier.

Start the inventory now, even if the system choice is still open. Most of the questions it answers will be needed for requirements and supplier conversations anyway, so the work is not wasted.

If you are planning an ERP project and want to talk through the data side, Mirex Agency can help you think it through. Mirex is a London-based, senior-led digital agency, and our ERP solutions service is built for UK businesses that need finance, stock, HR and operations managed in one clearer system. Get in touch at hello@mirexagency.com.