Blog - Syntanea

ERP data migration checklist work gets risky when people treat it as an export job. ERP data is not just rows. It is open invoices, stock levels, supplier terms, tax codes, approvals, product units, historical prices, and the small exceptions that keep operations moving.

A failed ERP migration rarely fails on one dramatic technical bug. It fails because customer records were duplicated years ago, warehouse units do not match finance units, old VAT rules sit in free text, and nobody tested what happens to an invoice created during the cutover window.

This guide is for teams replacing or consolidating ERP systems. Use it before the first production export, especially if finance, inventory, purchasing, or fulfilment depends on the move.

ERP data migration checklist before the project starts

Before mapping fields, agree what the ERP migration is meant to protect. The answer is usually not "all data". It is the data the business must trust on day one.

Write down:

source ERP modules: finance, sales, purchasing, inventory, projects, HR, manufacturing, or service

target ERP modules and which ones go live later

legal entities, countries, currencies, VAT regimes, and fiscal calendars

business objects that must migrate: customers, suppliers, products, chart of accounts, open invoices, stock, purchase orders, sales orders, contracts, users, and roles

historical data that stays archived instead of moving into the new ERP

reporting periods that must reconcile after go-live

The useful decision is where to draw the line. Five years of invoice history may be searchable in an archive while only open items and current-year transactions move into the new ERP. That is a business decision, not a script parameter.

For a broader project-level view, pair this with our data migration checklist. The ERP version below goes deeper on finance, stock, master data, and cutover risk.

Clean master data before mapping ERP fields

ERP migrations expose old habits. A supplier may appear three times because different teams used different spellings. Product units may say "box", "BOX", and "carton" for the same item. One customer may have a sales name, legal billing name, and shipping name that nobody has reconciled.

Clean master data before field mapping becomes final:

deduplicate customers and suppliers with agreed matching rules

normalize VAT IDs, registration numbers, bank accounts, addresses, and country codes

define the legal name, trading name, and display name for each account

standardize product units, SKUs, barcodes, and category names

close or archive inactive records instead of carrying every old record forward

keep source IDs so support can trace records after go-live

Do not ask developers to "clean it up" without rules. If two suppliers share a bank account, is that fraud, a parent company, or a normal setup? Engineering cannot guess. Finance or operations has to decide.

Map ERP ownership before field mapping

A field map is useful only after ownership is clear. The CRM may know the account manager. Finance owns legal names and payment terms. The warehouse owns stock locations. Procurement owns supplier status. The new ERP needs one rule for conflicts.

Use a mapping table with these columns:

target field

source system and module

source-of-truth owner

transformation rule

validation rule

exception owner

decision date

For example, payment terms should come from finance, not from a sales note. Stock on hand should come from the warehouse system at a fixed cutoff time, not from a report exported the day before. These details sound boring until month-end close fails.

If the ERP migration depends on older tools staying connected during transition, read our legacy system integration strategy. A staged integration can be safer than forcing every module into one weekend.

Test ERP migration with real reconciliation numbers

A migration dry run should prove that the business can operate, not just that the import completed.

Run each dry run against a recent production copy, with personal data masked where needed. Then reconcile numbers the business already trusts:

open accounts receivable and accounts payable totals

trial balance or selected general ledger balances

stock quantities and valuation by warehouse

open purchase orders and sales orders

customer and supplier counts after deduplication

tax/VAT totals for the selected period

user roles and approval limits

Keep reject files for records that failed validation. Keep a decision log for rules changed after each dry run. A second dry run should not repeat the same failures. If it does, the issue is not technical. The decision process is broken.

Plan cutover around finance and operations, not the IT calendar

ERP cutover has to respect the business calendar. Avoid month-end close, payroll, peak fulfilment periods, inventory counts, and tax filing windows. A quiet weekend in IT can be a terrible weekend for finance or the warehouse.

A usable cutover plan includes:

final transaction freeze time for each module

owner who can approve emergency transactions during freeze

exact export commands or reports and who runs them

import sequence, including dependencies between master data and transactions

smoke tests after each module import

go/no-go criteria written in business terms

rollback trigger, rollback owner, and the last safe restore point

communication plan for users, suppliers, and customers if needed

The dangerous phrase is "we will handle it manually if something goes wrong." Write the manual fallback down. Who enters the urgent order? Where is it recorded? Who replays it later? Without that, manual fallback is just hope.

Do not migrate every historical ERP transaction by default

Old ERP data can be expensive to move and risky to reshape. Sometimes the right answer is to migrate active operational data and keep historical data in a read-only archive.

A practical split often looks like this:

migrate active customers, suppliers, products, open invoices, open orders, current stock, current contracts, users, and approval rules

archive closed invoices, old stock movements, past purchase orders, audit logs, and legacy reports

provide searchable access to the archive for finance, support, and compliance

keep source IDs in the new ERP so archive records can be traced

This reduces mapping work and lowers the chance of changing history by accident. It also makes go-live easier to test because the new ERP starts with data people still use.

ERP migration FAQ

What should an ERP data migration checklist include?

It should include migration scope, master data cleanup, ownership rules, field mapping, validation, dry runs, reconciliation, cutover timing, rollback, archive strategy, security roles, and post-go-live support.

How long does ERP data migration take?

Small migrations can take a few weeks of focused work. Mid-sized ERP replacements often need two to four months for cleanup, mapping, dry runs, reconciliation, and cutover planning. Messy master data usually adds more time than import scripts.

Who owns ERP data migration?

IT owns the migration tooling, but finance, operations, sales, procurement, and warehouse owners must define source-of-truth rules and approve exceptions. If business owners do not sign off, the migration is not ready.

How many ERP migration dry runs are needed?

Plan at least two. The first finds data quality and mapping problems. The second proves the fixes. Complex finance or inventory migrations may need three or four dry runs before cutover is safe.

Should old ERP history move into the new system?

Not always. Active records usually need to move. Older closed transactions can often stay in a read-only archive if finance, support, and compliance can search them and trace them from the new ERP.

Need help with an ERP migration?

Syntanea helps European teams plan ERP migrations, legacy integrations, data cleanup, and cutover rehearsals. We turn messy source systems into clear ownership rules, import paths, dry run reports, and a plan business owners can review.

If an ERP migration is approaching and the data still feels uncertain, talk to Syntanea. We can run a focused migration discovery and find the risky records before they reach production.

ERP data migration checklist: clean, map, test, cut over