ERP data migration: how to move your data without losing your mind

Data migration is the part of an ERP project that owners underestimate most. The software is new and clean; your data is neither. Here is how to approach it so it does not become the thing that delays your go-live.

What to migrate, and what to leave behind

There are three kinds of data.

Master data: customers, suppliers, products, price lists, chart of accounts, employees. Migrate all of it that is still in use. Archive what is not.

Open items: unpaid customer invoices, unpaid supplier bills, open sales and purchase orders, current stock quantities, bank balances. Migrate all of it, as at the go-live date.

History: every past invoice, order and journal. Think carefully. It is tempting to bring everything, but old transactions rarely map cleanly onto a new system's structure, and migrating them can double the effort. Most businesses keep the old system available read-only, or an export, and start the new one with opening balances.

Clean before you move

Migrating dirty data just gives you dirty data in a nicer system. The usual problems:

• Duplicate customers and suppliers. "ABC Ltd", "A.B.C. Limited" and "abc ltd" are one company.
• Inconsistent product codes. Different formats from different eras, or the same product under two codes.
• Missing fields. Products without weights, customers without VAT numbers, suppliers without payment terms.
• Obsolete records. Customers who last ordered in 2016. Products discontinued years ago.
• Free-text where a list should be. Ten spellings of the same county in an address field.

Cleaning is partly mechanical (deduplication tools, formulas) and partly judgement (which of these two records is correct). Only your team can make the judgement calls, so start early.

Map old to new

Every field in your old data needs a home in the new system, and some concepts will not match one to one. Your old "customer type" field might become a price list plus a tag. Your old product categories might be restructured. The implementer produces a mapping document; you review it.

Migrate twice, at least

1. Trial migration into a test system, weeks before go-live. Check counts (did all 1,842 customers arrive?), spot-check records, run a few transactions. Every problem found here is fixed in the source data or the mapping.
2. Final migration immediately before go-live, with the latest open items and stock counts. Because the process has been rehearsed, it is quick and predictable.

Complex projects do three or four trial runs.

Timing the cut-over

Go live at a period boundary, ideally the start of a VAT quarter. Close the old system at the end of the period, take opening balances and a stock count, load them, and start trading in the new system the next working day. This keeps VAT returns and management accounts clean. Our implementation steps guide shows where this sits in the project.

Stock deserves special attention

A physical stock count immediately before go-live is essential. Migrating a stock figure that was already wrong in the spreadsheet is the fastest way to lose trust in the new system. Count it, load it, and start clean.

Who does what

The implementer provides templates, mapping, tooling and the loading itself. Your team exports the data, makes the cleaning decisions, and checks the results. It is the part of the project that needs the most of your time, and the part where that time pays back most.

Common mistakes

• Starting data cleaning in the week before go-live.
• Migrating obsolete records "just in case".
• Skipping the trial migration.
• Not doing a stock count.
• Going live mid-period.

We list the broader project pitfalls in ERP implementation mistakes.

If migration is the part of the project that worries you, it is worth saying so on the discovery call, because a realistic plan for it is what makes the rest of the timeline hold. Read about our ERP service or request a quote.

Frequently asked questions