What a legacy migration specialist actually does

The title “legacy migration specialist” gets used loosely, so it’s worth being specific about what the work actually involves — because it’s a narrower job than “engineer who’s willing to work on old code.”

The job starts with risk, not code

Before any migration work happens, the specialist’s job is to understand exactly what the system does, what depends on it, and what would go wrong if it failed during a migration. That’s the audit phase, and it’s the part generalist contractors most often skip in favor of jumping straight to rewriting — which is also why generalist migrations tend to have more surprises.

Then it’s about verification, not velocity

Once execution starts, the work is less about writing new code quickly and more about proving the new code produces the same results as the old system, continuously, across real data. A specialist spends a disproportionate amount of time building verification tooling — diffs, reconciliation jobs, dry-run environments — relative to the amount of time spent on the migration’s actual business logic.

And it doesn’t stop at cutover

The engagement isn’t over when traffic moves to the new system. The period right after cutover, under real production load, is when problems that didn’t show up in testing tend to surface — so a specialist stays engaged through that window and through safely decommissioning the old system, rather than considering the job done the moment the new system is live.

Why this is a narrow specialty

Being good at building new systems and being good at safely retiring old ones are different skills. The second one requires comfort with constraint — working within what an existing system already does, rather than what you’d build if starting fresh — and a level of paranoia about verification that most feature-development work doesn’t require. That’s the actual specialty.