Ask HN: Advice for leading a software migration?

Migrations are painful, thankless and always run over budget and time. Unless I've been at the company long enough, have enough confidence and rapport with my reporting head and skip level, I'd rather not do it.

I'm never taking any big (more than 2-3 month) migrations. Only small predictable subsystems that i can rollback or run both v1 and v2 in parallel. First one third time is for discovering by making changes and seeing where things break and possibly come up with fast tests (manual or automated). Last one third is for actual testing, trying out small pieces in production and fixing unexpected issues. So take your dev estimate and multiply by 3.

Even then, you have to shoot down any demands to use new frameworks, new processes and new dependencies. And resist your own temptation. Remember no one gives a shit about migrations.

You will be asked a thousand times on the progress by people incapable of fathoming the complexity. They expect a percentage. Have one ready with a small roadmap, of cornerstones and publish as a report or something. Everytime someone asks, point to the report. No one ever opens that report.

You often can’t replace old systems without also changing the org chart.

Every task that involves someone outside you team will need the t-shirt size doubled for every group outside yours. Possibly triple if it’s a vendor (some are better than others). This can easy turn a 1 line fix into a month long project if you need to coordinate the change.

It is not uncommon to get 90% finished with a migration, only to find out some job needs to still happen in the old system. That old system will survive another 4years. If you’re lucky, you’ll find a way to rope it off so it can quietly do that one job, without effecting anything else.

It is not uncommon that some team starts trying to use the old system midway through the migration, usually because it’s there. This will seem fine, because “they can easily change to the new system”. This will inevitably add 6months to the project, because changing is never easy. If the organization is big enough, these adds will happen with enough frequency that the project is guaranteed to last forever.

Politics is not your friend. Any large system change is going to require other teams to do work. Managers will attempt to position themselves so that their team is not the one “responsible” for calendar slips that were likely unrealistic to begin with.

I’m sure I could think of some other things, but these were the thoughts that came quickly having lead large migrations away from legacy systems.

Good luck.

Then see whats left