How to choose a legacy modernization company (and the questions that expose the weak ones)

01Ask what they will not modernize

A firm that answers 'all of it' is either selling you a rewrite or has not looked at your estate. The correct answer names subsystems that should be left alone: things that are stable, rarely changed and carry no strategic value. Modernizing those spends budget and adds risk for no return.

The follow-up matters more. Ask how they decide. You are looking for a framework that scores systems on change frequency, business value and failure cost, not a preference for whichever technology the firm likes selling.

02Ask how they handle the cutover they got wrong

Everyone has had a migration go badly. A firm claiming otherwise has either not done many or is not being straight with you. What you want is a specific story: what broke, how quickly they knew, what the rollback looked like and what changed in their process afterwards.

The detail is the tell. People who have lived through a bad cutover remember the shape of it precisely, because it cost them a weekend and a difficult conversation. Vague answers here usually mean the war stories are borrowed.

03Ask who is actually doing the work

The people in the pitch are frequently not the people on the keyboard. This is normal in larger firms and not automatically a problem, but you should know before you sign, not in week three.

Ask for the names and seniority of the engineers who will be on the engagement, and whether they are committed or provisional. Ask what happens when someone rolls off. A firm that has thought about continuity will have an answer about documentation and pairing; one that has not will reassure you vaguely.

• Who writes the code, and what is their level?
• Are they dedicated to this engagement or shared across several?
• What is the handover process when someone leaves the team?
• Who owns the architecture decisions - them, you, or jointly?

04Ask what you own at the end

Modernization done badly replaces one dependency with another. If the new system can only be operated by the firm that built it, you have not reduced risk, you have moved it to a vendor relationship.

The deliverables that matter are the boring ones: runbooks, architecture decision records explaining why things are the way they are, a working local environment, and enough test coverage that your team can change the system without the original authors. Ask to see examples from a previous engagement.

05Ask for the sequencing, not the timeline

A timeline for a modernization programme is a guess, and everyone in the room knows it. The sequencing is not a guess: it reflects whether the firm understands how to reduce risk early.

Good sequencing puts a real slice of production traffic on the new path within the first couple of months, on something small enough to fail safely. Bad sequencing spends the first quarter on discovery documents and puts the first cutover at the end, when the budget is spent and the pressure is highest.

06Where the price differences actually come from

Quotes for the same programme routinely differ by a factor of three. Very little of that is margin. The gap is usually scope interpretation: one firm has priced a rearchitecture, another a replatform, a third a rewrite, and the proposals do not make that explicit.

Before comparing numbers, make each firm state which of the three they are quoting for, per subsystem. Once the scope is comparable the prices usually converge, and the remaining difference tells you something real about seniority and delivery model.