How to hire for a migration without getting burned

The wrong hire for a legacy migration doesn’t usually fail loudly at the start. It fails quietly, months in, when the scope has crept, the timeline has slipped twice, and nobody can point to a clear reason why the new system still isn’t trustworthy enough to cut over to.

Ask what happens before any code changes

A vendor who wants to start migrating immediately, without first producing a written risk assessment of the current system, is skipping the step that catches the most expensive surprises. Ask specifically what the discovery phase produces, and whether it’s a real deliverable or just a few days of “getting familiar with the codebase” folded into the estimate.

Ask how they verify correctness

“We’ll test it thoroughly” isn’t an answer — it’s a placeholder for one. A vendor who’s done this before should be able to describe a concrete verification approach: how they’ll prove the new system produces the same results as the old one, across real data, before cutover. If the answer is vague, the migration’s data integrity is going to be someone’s best guess.

Ask about rollback, specifically

If a vendor’s cutover plan doesn’t include an explicit, rehearsed rollback path, ask why not. “We’re confident it’ll work” is not a rollback plan, and a vendor who hasn’t thought through what happens if it doesn’t work is planning for the easy case only.

Ask what happens after cutover

Vendors billing by project milestone sometimes treat cutover as the finish line. Ask directly whether support continues through the post-cutover period, when problems are most likely to surface under real load — and get that answer in the contract, not just in conversation.

The actual filter

The common thread across all of these questions is the same: does this vendor treat migration as a risk-management discipline, or as a coding project that happens to involve an old system. The answer to that question predicts the rest of the engagement better than anything in a proposal deck.