ERP Data Migration: What Not to Move, and How to Sign Off

Two decisions carry most of an ERP data migration: what you refuse to move, and how you prove that the rest arrived correctly. Both belong to the business, not the migration tool. A tool loads whatever it is given. It cannot tell you that an article has not sold in years, that an open order will never ship, or that two customer records are the same company under two spellings.

The cleanup in between, who owns each data object and how the test loads are run, is covered in ERP Data Migration: Master Data Is a Business Job. That article is the foundation for this one, and it is worth reading before you plan the work.

ERP Data Migration: Master Data Is a Business Job

Start with what stays behind

The cheapest record to migrate is the one you leave out. Every record you drop is one nobody has to clean, map, test and explain later, which is why the exclusion rules deserve a session with the people who know the data rather than a default of “migrate everything just in case”.

Agree the rules per data type, and write them down:

• Customers and suppliers. No transaction for an agreed number of years, duplicates merged into one surviving record, prospects that never became customers, contacts of companies since absorbed or liquidated.
• Articles and bills of materials. Blocked items, obsolete items, items never sold or never bought, items replaced by a successor, items kept only for one historic job.
• Open items. Quotes and orders that will never be confirmed, purchase orders nobody expects to receive, service jobs finished in practice but still open in the system.
• Prices and agreements. Expired price lists, discounts nobody can explain, customer agreements not applied for years.
• History. Transaction detail older than your reporting and retention needs. Often an opening balance plus a yearly summary is enough, with the detail kept in the old system.

Two rules keep this honest. Decide per data type rather than per module, because a half-migrated article master is worse than one migrated whole. And give the rules a cut-off date everyone uses, so the extract and the count share one boundary. They are only real once the business signs them off; who signs for which data type is in the article linked above.

Keep the old system readable, not running

Almost every migration keeps the old system for a while. Decide what that means before cutover, or you end up with a second system people still work in.

• Read-only, no exceptions. After cutover nobody creates, changes or posts a transaction in the old system. A read-only copy is a lookup. A copy that still accepts entries is a reconciliation problem waiting for month end.
• Named access. Agree who can look things up, on what basis and through which route. One documented way in beats a ticket to IT every time someone asks about an old invoice.
• Retention. Keep the archive as long as statutory retention and audit need it, and put that date in the migration document rather than in someone’s memory.
• A lookup guide. One page saying where to find an old invoice, an old order and an old stock movement. It saves weeks of questions.

Reconcile against the old system, then sign off

A migration is finished when the numbers match, not when the import runs without errors. Agree the checks before the first test load, so every load is measured against the same list and the final one repeats a pass.

• Record counts per data type, old against new, against the agreed scope. If a data type comes in short of scope, the missing records need a name-level explanation, not an average.
• Stock quantities per article and location, not only the total. A total that matches while two warehouses are wrong by the same amount in opposite directions is a coincidence, not a reconciliation.
• Open customer and supplier items, in total, per account, and line by line for the largest accounts. This is where currency, payment terms and partial payments surface.
• Spot checks on real records. The data owners pull a customer, an article, a price agreement and an open order and compare field by field. Careful checks on real records find more than a dashboard.
• One transaction end to end, from order to invoice, run on migrated data by the people who will do it after go-live.

Every check needs one named person who signs it off, with the date, both figures and any accepted difference in writing. A difference accepted with a reason is a decision. A difference nobody wrote down becomes an argument in week one of live running. That signed list is the data part of your go or no-go, complete before the cutover weekend.

Running the same list on every test load has a second benefit: you watch the error count fall. On the Waterlogic Hungary project, data migration ran as its own workstream from week one, alongside configuration and testing.

A short checklist

1. Agree what not to migrate, per data type, with a cut-off date.
2. Get the exclusion rules signed off by the business owner of each data type.
3. Decide what the old system keeps: read-only, named access, retention date, lookup guide.
4. Agree the reconciliation checks before the first test load.
5. Reconcile counts, stock per article and location, open items and balances.
6. Spot check real records with the people who own the data.
7. Get one signature per check, with accepted differences in writing.
8. Treat that signed list as the data part of go or no-go.

The bottom line

An ERP data migration is decided at its edges: what you choose not to move, and what you can prove about what you did move. Sign off the exclusion rules early, keep the old system readable rather than running, and reconcile every load against the same list until the numbers match and someone has put their name to them.