Data migration is not a task in the project. It is the project
Migration is scoped as moving records across. The work is deciding what does not come across, and that decision is nobody's job until it is late.
On most implementation plans, data migration is one line with a week against it. The line covers moving records. The work is deciding which records should move, and that decision belongs to the business rather than to whoever is doing the moving.
Moving is easy. Deciding is not
The technical act of moving records between systems is well-solved. What takes the time is everything that has to be settled first, and none of it is a technical decision.
- Years of duplicates, where the same customer exists three times because the name was entered three ways and nothing matched them.
- Contacts attached to companies that merged, closed, or were renamed.
- Fields that three departments filled in with three different meanings, all of which look valid.
- Historical records nobody will ever open, which will nonetheless be migrated because deleting them requires someone to take responsibility for deleting them.
Every one of those is a business decision. Engineers cannot make them, and they are the reason migration weeks turn into migration months.
Migrate faithfully and you have bought the mess
The instinct is to bring everything across so nothing is lost. It is the wrong instinct, and it has a predictable consequence: the new system inherits the old system's reputation. People open it, see the same duplicated rubbish they saw before, conclude the project changed nothing, and go back to their spreadsheets.
Adoption rarely recovers from that, and no amount of training fixes it, because the objection is correct.
A sequence that works
Profile before you plan. Count the records, the duplicates, the empty fields, the values that violate their own format. This takes days and it is the only way to size the work honestly. A plan written without it is fiction.
Decide the cut-off. How much history actually comes across? Whatever the live system needs to do its job. Anything kept only because someone might ask can be archived somewhere readable instead.
Clean in the old system, not the new one. Cleaning during migration means doing it under deadline while people wait. Cleaning beforehand is unglamorous, parallelisable, and can start today.
Name an owner per data domain. Customers, products, transactions. One person per domain who can settle a question in an hour rather than a meeting in a fortnight.
Migrate twice. A full rehearsal into a test environment, reviewed by the people who will use it, before the real run. A rehearsal surfaces the problems while there is still time to decide what to do about them.
What to do this week
Ask for one number: how many records in your main system are duplicates. If nobody can produce it, that is the finding, and it is worth more than any timeline estimate you have been given. Profiling the data is a few days of work and it is the cheapest risk reduction available on an implementation.
Where this goes next
Migration is one of six workstreams that get compressed when a date is announced early. The rest are in what software implementation actually covers. Where migration and integration sit in the total bill is covered in the licence is not the cost of the system, and what to do when a project has already slipped is in what to do when an implementation stalls.