Skip to main content
NEWOur top 12 applications for manufacturers, field proven.Request the Fall 2026 catalog
GUIDE

ERP data migration: a step-by-step guide for manufacturers

ERP data migration is moving the records a business runs on, such as customers, items, bills of materials, open orders and balances, out of the old system and into the new one, cleaned and mapped so the new ERP works on day one. Most of the risk is not in the load itself. It is in the data nobody cleaned, the business logic nobody wrote down, and the reconciliation nobody ran. This guide walks through the steps in order.

Updated . Written by Structify, which connects to ERPs but does not sell or implement them.

What is ERP data migration?

ERP data migration is the part of an ERP project that moves data from the old system and the spreadsheets around it into the new ERP. It covers deciding what moves, cleaning and de-duplicating it, mapping old fields and codes to new ones, loading it in trial runs, reconciling the results, and a final cutover load.

What data should you migrate to a new ERP?

Move master data, open transactions and balances. Archive most history where people can still look it up, rather than loading years of closed transactions into the new system.

  • Master data: customers, vendors, items, bills of materials, routings, work centers, price lists
  • Open transactions: open sales orders, purchase orders, jobs and work orders, open AR and AP
  • Balances: on-hand inventory by location and lot, opening general ledger balances
  • History: summarize or archive it, and keep it reachable for questions and audits

Do you have to migrate ERPs to use AI?

No. AI applications can be connected to the ERP you already run, including older on-premise systems. If the reason for the project is better reporting, faster answers or less re-keying, check whether AI on the current ERP gets you there before you commit to a migration.

STEP BY STEP

Seven steps to an ERP data migration.

  1. 01

    Inventory every source

    List the old ERP and everything around it: the quality system, the MES, the spreadsheets, and the export someone runs every Monday. Data that lives outside the ERP is the data most often left behind.

  2. 02

    Decide what moves

    Master data, open transactions and balances move. Closed history usually gets archived where it can still be searched. Agree on this early, in writing.

  3. 03

    Clean before you move

    Merge duplicate customers and vendors, retire item numbers nobody uses, fix units of measure, and give every record an owner who can say whether it is right.

  4. 04

    Map fields and rules

    Map every old field and code to the new system. Write down the business logic hiding in custom fields, reports and people's heads, because the new ERP will not infer it.

  5. 05

    Load, test and reconcile

    Run trial loads into a test environment. Reconcile record counts, inventory and balances against the old system, then have the people who use the data run real transactions on it.

  6. 06

    Cut over

    Freeze changes in the old system, run the final load, reconcile again, and go live. Plan the cutover around a period close and a quiet week on the floor.

  7. 07

    Keep the old data reachable

    Leave the old system read-only or keep its data somewhere searchable. Questions about old orders, warranties and audits will keep coming for years.

WHERE IT GOES WRONG

Five common ways ERP data migrations fail.

  • Moving bad data as it is

    Duplicates and stale records loaded into a new ERP make it look broken on day one, and people go back to their spreadsheets.

  • Losing the business logic

    Pricing rules, approval habits and the meaning of a custom field live in the old system and in people. If nobody writes them down, they do not survive the move.

  • Skipping reconciliation

    A load that finishes without errors is not a load that is right. Counts, quantities and balances have to tie out to the old system.

  • Loading too much history

    Years of closed transactions slow the project and the new system. Archive them and keep them searchable instead.

  • No one owns the data

    When IT owns the load but nobody in purchasing, sales or the plant owns the records, errors surface after go-live instead of before it.

WHERE STRUCTIFY FITS

A map of the data before, during and instead of a migration.

Your ERP partner runs the migration and the cutover. Structify works on the data around it.

  • Before: a map of what you have

    A forward-deployed engineer connects the old ERP, the quality system and the spreadsheets into one data map, so the inventory and the clean-up start from what is actually there.

  • During: matching records across systems

    At Harney & Sons, Structify matched more than 100,000 SAP records into one queryable layer without disrupting the systems already running the business.

  • Instead: AI on the ERP you run

    If the goal is faster answers and less re-keying, AI applications can run on the current ERP, including older on-premise systems, with no migration at all.

READ NEXT

Related guides and posts.

Get a blueprint foryour AI transformation.

Book a demo