The part of a migration nobody schedules
The migration itself takes a week. Deleting the old thing takes a year.
Every migration plan I've written has the same shape: stand up the new system, dual-write to both, backfill the history, cut reads over, delete the old one.
Five steps, and the first four have dates on them.
The fifth never does.
Why the last step slips
Deleting the old system is the only step with no upside on a roadmap. Nobody notices when it's done. It shows up in exactly one place: the cloud bill.
By the time anyone is looking at that number, the migration is six months in the past and the people who understood the cutover have moved to other work.
Meanwhile the old system is still:
- Taking writes from that one cron job nobody remembered
- Being scraped by a dashboard someone built in their first week
- Paged on, because the alerts are still wired up
What actually works
Put the deletion in the same plan, with the same date discipline, as the cutover. Two things make it stick:
Make the old system loud. Log every read and write that still lands on it, with a caller tag. A weekly count going to zero is a milestone you can point at; a count that plateaus at 400 is a list of the things you still have to go fix.
Set the date before you start. "We delete this on the 14th" written down in the original plan is a commitment. "We'll delete it once we're confident" is a system that runs forever.
The migration was never the hard part. Convincing an organisation to finish something that has already stopped being interesting is the hard part.