Recovering an ERP data migration

ERPs live and die by the quality of the data migration. And data migration is exactly where most ERP recoveries start.

The call usually comes during testing. The migrated data hasn't turned up. The only test cases running are new business, because nobody has worked out how to move the existing business onto the new ERP.

Data migration done properly has six steps:

1. A business data owner defines what good looks like, and what stays behind.
2. Profile the data against that standard.
3. The data owner decides where data gets remediated: in the source system, during the migration, or in the target.
4. Design the migration to preserve referential integrity and business meaning.
5. Decide what happens to in-flight transactions: which complete in the old system and which move across.
6. Agree the reconciliation evidence up front, then reconcile every load back to source.

Migrating several systems at once? Add a programme-wide data catalogue, or your systems won't talk to each other when you integrate them. In a recovery, most of these have been skipped.

1. Checklist it

Literally. Walk the migration against the steps above. The gaps are your recovery plan.

2. Ownership, tooling, method

Almost every time, I find a technical team moving data with no idea what it means. No owners. No governance. Spreadsheets and scripts where there should be an ETL tool like Azure Data Factory and a Power BI data quality dashboard.

Fix ownership first. Then tooling and people. Then make sure the team follows a formal migration methodology.

3. Prove it small, then rehearse in full

Take one or two entities end to end and reconcile them. The team learns the method. Stakeholders see it work. Then run at least two full, timed mock cutovers, each reconciled and signed off by the data owners. Not an endless stream of corrections.

What it looks like in practice

A regulated client, with their licence riding on the deadline. One business analyst was running the migration out of Microsoft Access. The business couldn't identify all its customers. It was asking them the same questions twice. It couldn't tell the regulator whether it had met its obligations.

Almost none of my time went on fixing defects. It went on getting the executives to fund proper tooling and people, then coaching the team to use a formal methodology.

That is what a data migration recovery looks like. Rarely a few fixes. Usually a redo from the start.