ERP data migration checklist for SMEs: what to fix before cutover

Quick answer

ERP data migration checklist for SMEs: what to fix before cutover explains what the change means for UK SMEs and how to turn it into a practical next step. The process is to identify the business decision, connect the data, then automate only the parts that improve speed or reliability.

The risky part of an ERP project is rarely the software demo. It is the first week after cutover, when finance, operations and sales discover that the new system contains the same duplicate customers, unreliable product codes and unclear status fields as the old one.

For UK SMEs, ERP data migration is often treated as an export-import exercise. Pull the records from Sage, Xero, Access, Excel, a legacy ERP or a collection of departmental spreadsheets. Map the columns. Load them into the new platform. Test whether the screen opens.

That is not enough. The migration is the moment when old operational habits become hard-coded into the new system.

A practical data migration consultant starts earlier. Which records should move? Who owns each field? Which duplicates should be merged? Which definitions are changing? What must reconcile before finance signs off? Which reports must still agree after go-live?

This checklist is the work to do before cutover.

1. Agree what the migration is actually for

Before touching a CSV export, define the business outcome. A migration can have very different risk depending on the reason for the change.

Migration context	Data question to answer first
Replacing a finance system	Which balances, dimensions, customers, suppliers and open transactions must reconcile on day one?
Moving to a new ERP	Which operational records drive ordering, stock, production, fulfilment, invoicing and management reporting?
Consolidating multiple systems	Which source wins when two systems disagree?
Preparing for automation	Which fields need controlled values before workflow rules can be trusted?
Improving reporting	Which definitions must be standardised before dashboards become credible?

If the purpose is unclear, every later decision becomes subjective. People argue over whether to migrate old records, preserve legacy codes, clean data now or later, and whether a failed reconciliation is material.

2. Build a source-system inventory

Most SMEs underestimate how many places their operating data lives. The official system is only part of the picture.

List every source that creates, edits or reports on the records that will move into the new ERP. Include finance packages, CRM platforms, stock systems, ecommerce platforms, warehouse tools, Access databases, shared spreadsheets, CSV exports and manual trackers used by individual teams.

For each source, capture:

• System or spreadsheet name.
• Business owner.
• Record types held.
• Fields that are manually maintained.
• Known quality problems.
• Reports or decisions that depend on it.

If a spreadsheet drives a decision, it is part of the migration landscape whether the project plan admits it or not.

3. Decide what should not migrate

The cheapest data to migrate is often the data you leave behind.

Old customers, inactive suppliers, obsolete product codes, dead stock items, closed projects, historic opportunities and legacy dimensions can all create noise in the new ERP. Moving everything feels safe, but it often makes the new system harder to use from day one.

Define archive rules before extraction:

• How many years of history are legally, operationally or commercially needed?
• Which inactive customers and suppliers should remain searchable but not transactional?
• Which products or SKUs should be retired before migration?
• Which legacy project, department or cost-centre codes should be mapped to a cleaner structure?
• Which records should be held in a read-only archive rather than loaded into the ERP?

4. Profile the critical records

Data profiling is the early warning system. It tells the project where the defects are before they become cutover incidents.

At minimum, profile these areas:

• Customers: duplicate names, missing legal entities, old billing addresses, inconsistent credit terms and unclear parent-child relationships.
• Suppliers: duplicate vendors, missing payment terms, unverified bank details and inactive suppliers still used in reports.
• Products and items: inconsistent units of measure, obsolete SKUs, missing categories, unclear margin logic and duplicate item descriptions.
• Finance dimensions: cost centres, departments, nominal mappings, project codes and reporting hierarchies.
• Transactions: open orders, open purchase orders, unpaid invoices, stock balances, commitments and partially completed work.

This is where data management and migration meet. The profile tells you what needs ownership, cleanup and sign-off before the vendor starts importing files.

5. Create the source-to-target map

The source-to-target map is the working contract between the business, the implementation partner and the data migration team.

For each field, it should show:

• Source system and source field.
• Target ERP object and target field.
• Transformation rule.
• Default value where the source is blank.
• Validation rule.
• Business owner.
• Sign-off status.

Do not let this live only in the vendor's tooling. The business needs to understand and approve the logic, especially where old values are being merged, renamed, defaulted or excluded.

6. Clean before the test migration, not after it

There will always be defects found during trial loads. That is normal. The avoidable mistake is knowingly loading bad data because "we can tidy it later".

Some cleanup belongs before the first meaningful test migration:

• Merge obvious customer and supplier duplicates.
• Remove inactive records that meet the archive criteria.
• Standardise units of measure and product categories.
• Resolve missing mandatory fields.
• Confirm finance dimensions and reporting hierarchies.
• Lock down who can change master data during the migration window.

The point of the test migration is to test migration logic, user acceptance and reconciliation. If the load is full of known avoidable defects, the test becomes noise.

7. Reconcile what matters

Reconciliation is not just a finance task at the end. It is how the business proves the migration is safe.

Create checks for:

• Customer, supplier, product and item record counts.
• Opening balances and control accounts.
• Open sales orders, purchase orders and invoices.
• Stock quantities and stock valuation.
• Project, job or work-in-progress balances.
• Key reports used by finance, sales and operations.

Where Power BI or spreadsheet board packs already exist, use them carefully. They can help prove that the new ERP supports the same management view, but only if the old reports are understood and trusted. A useful supporting step is a report catalogue: which reports are needed after go-live, which can be retired, and which definitions must change.

8. Define cutover ownership and sign-off

ERP cutover needs named business owners, not just a project manager chasing approvals.

Before go-live, agree who signs off each area:

• Finance signs off balances, open transactions and reporting dimensions.
• Sales signs off customer records, territories, price lists and pipeline carryover where relevant.
• Operations signs off products, items, stock, jobs, fulfilment statuses and operational workflows.
• Procurement signs off suppliers, payment terms and purchasing controls.
• Leadership signs off known risks and the go/no-go decision.

This is also where the business decides what happens if reconciliation fails. Which defects block go-live? Which can be accepted with a workaround? Which require rollback? Decide this before the weekend of cutover.

What Digital Adaption would help produce

For a UK SME, the useful deliverables are practical and finite:

• A source-system inventory and migration scope.
• A master data ownership matrix.
• A data-quality report covering duplicates, blanks, invalid values and conflicting definitions.
• A source-to-target mapping workbook.
• A cleanup backlog ranked by cutover risk.
• Reconciliation checks for finance, operations and management reporting.
• A cutover sign-off pack that executives can actually use.

The work sits between data migration, data management and operational business analysis. It is not about making the migration theoretical. It is about reducing the risk that the business spends serious money on a new ERP and carries the same data problems into a more expensive platform.

The takeaway

An ERP migration is a control point. It is the chance to decide which data the business trusts, which records should be retired, which definitions need to be standardised and which checks must pass before go-live.

Move everything without that work and the new ERP becomes a cleaner-looking version of the old problem.

Do the checklist properly and the migration becomes more than a technical cutover. It becomes the point where finance, sales and operations agree what the business means by customer, supplier, product, order, margin and status.

That is what makes the new system usable after the implementation team leaves.