The Migration Checklist Nobody Talks About

Ask any ERP project manager what their go-live risk is and they will name the same three things: data, people and the moment of cutover. Then look at their plan, and you will find pages of software configuration, a Gantt chart of technical tasks, and almost nothing about the data, the people or the cutover. The checklist below is what that plan is missing.

I have been through enough migrations to know which tasks are skipped first when the timeline slips. They are never the technical ones. They are the data cleansing, the validation sign-offs, the rollback rehearsal and the communications plan. This article puts them in the order they need doing, so the timeline slips on something less important instead.

In this guide

1. The data work starts before the software does
2. Migrate what matters, archive the rest
3. Validation with signatures, not hopes
4. The data protection assessment nobody schedules
5. The rollback plan and its trigger threshold
6. Training and communications, timed properly
7. Frequently asked questions

The data work starts before the software does

The first rule of migration is that data quality is discovered, not assumed. The old system looks fine from the outside. Inside, there are duplicate customer records, products with no supplier, stock lines with negative quantities, and thirty years of history nobody has touched. The migration will surface all of it, at the worst possible moment, unless you go looking first.

Run a data quality audit in the discovery phase, not the month before go-live. For each master data set, count and report:

• Duplicate records and near duplicates
• Missing or empty mandatory fields
• Records that fail the new system's validation rules
• Values that exist in the old system but not in the new one's reference data
• Orphaned transactions pointing at deleted masters

The audit gives you the cleansing workload in week four instead of week forty, which is the difference between cleaning 2,000 records calmly and cleaning 20,000 records under pressure. The National Audit Office has documented the same lesson across public sector programmes in its reports on major IT change: the programmes that fail on data are the ones that treated data as a technical detail rather than a workstream.

Migrate what matters, archive the rest

The second rule: you do not have to move everything. Every record that crosses to the new system has to be mapped, validated and trusted. Every record that stays behind has to be archived with a retrieval path. Decide the boundary deliberately:

• Move: open transactions, live master data, and the history required for reporting, audit and compliance.
• Archive: closed transactions beyond the retention period, superseded masters, and data that only exists because nobody ever deleted it.

Most businesses over-migrate. The result is a new system that is slower and harder to trust than it should be, because it is carrying the old system's baggage. A lean migration is a fast system, and the archived data is still yours, in a format you can retrieve, which is what the auditors actually care about.

Validation with signatures, not hopes

Validation is the step where migrations go quiet. The technical team runs the extract, transform and load, the row counts match, and everyone assumes it worked. Row counts matching is the weakest test there is. The data can be complete and wrong at the same time.

Build validation in four layers:

1. Row and value counts. Every table in, every table out, and the exceptions report is empty.
2. Balance reconciliation. The trial balance, stock valuation and aged debtors in the new system tie to the old system, to the penny, as of the cutover date.
3. Random sampling. Pull a sample of customers, products, orders and suppliers, and check them field by field. Sampling catches the systematic errors the counts miss.
4. Business sign-off. Each department head signs off their own data. The signature is the evidence, and it belongs in the project file, because the auditors will ask for it.

The sign-off layer matters more than the others, because it transfers ownership. When finance signs the ledger data, finance owns the numbers that go live. That is the moment the project stops being an IT project and becomes the business's system.

The data protection assessment nobody schedules

Moving personal data from one system to another is processing under UK GDPR, and it triggers a data protection impact assessment whenever the processing is likely to result in a high risk to individuals. The Information Commissioner's Office guidance on data protection impact assessments is clear about when one is needed, and an ERP migration involving customer, employee or health data is squarely in scope for many businesses.

Schedule the DPIA alongside the design work, not at the end. It asks five questions that improve the migration:

• What personal data is moving, and why?
• Is the minimum necessary data being transferred?
• How is the data protected in transit and at rest?
• Who has access during and after the migration?
• How long is the data kept, and how is it deleted at the end?

Answering these during design catches problems while they are cheap. Answering them after go-live is how businesses discover they migrated six years of employee data they never needed, and have no defensible reason for holding it.

The rollback plan and its trigger threshold

Every plan says "if go-live fails, we roll back". Almost no plan says what failure means, when rollback triggers, or what rolling back involves. That vagueness is dangerous, because the decision to roll back is made in the middle of the night, by tired people, under pressure.

Write the rollback plan in the design phase and agree three things:

1. The trigger threshold. For example: if any critical process is still failing after four hours, or if a data defect affects more than one percent of transactions, we roll back. Numbers, not feelings.
2. The rollback steps. Restore the old system from the pre-cutover backup, reverse the data migration, and confirm the old processes work. Each step owned by a named person.
3. The decision authority. One person, named in advance, who can call it. Not a committee. The sponsor signs the threshold and the authority in the same meeting.

Rehearse the rollback once, in the test environment, the same way you rehearse the cutover. A rollback that has never been run is a theory. The same discipline that protects planning an ERP change without disrupting daily operations applies here: rehearse what you can, so the unplanned becomes planned.

Training and communications, timed properly

Two tasks that always get squeezed, and both fail in the same way: they are done too early, or they are done generically.

Training: role based, not everyone in everything. A picker does not need the general ledger course. Plan two to three hours per role, delivered in the two weeks before go-live, with a refresher after the first month. The superusers who trained their own departments, as described in why your team deserves software that keeps up with them, are the difference between adoption and resistance.

Communications: a migration is a change that touches every employee, and silence is a vacuum that fills with rumour. Publish a simple schedule: what changes, when, what users need to do, and who to ask. Send it at three points: when the project starts, four weeks before go-live, and the Friday before cutover. The Friday message is the one people actually read, so make it short and practical.

For the cloud route, the same checklist applies with the additions covered in moving your back office to the cloud without losing sleep: credentials rolled out early, connectivity tested, and the vendor's update cycle understood.

Frequently asked questions

The honest summary: the software is the smallest part of a migration. The data, the validation, the rollback and the people are the real project. Work this checklist in order, and go-live becomes the least interesting week of the whole programme, which is exactly how it should be.