Modernization proposals look interchangeable. Every vendor shows a target architecture, a phased roadmap and a slide about reducing technical debt. None of that predicts whether the programme lands, because the target state is the easy part - the hard part is getting from a system nobody fully understands to that target without stopping delivery. These are the questions that separate vendors who have done it from vendors who have drawn it.
01Ask what happens when discovery contradicts the proposal
Every modernization proposal is written before anyone has read the code. That is unavoidable. What matters is what the contract does when discovery finds the system is materially different from what was assumed - and it usually is, because the undocumented behaviour is the reason modernization is needed.
A vendor who has done this work will tell you their proposal has a re-planning gate after discovery, and will be specific about what triggers a change of scope. A vendor who insists the plan holds regardless has either not looked closely at systems like yours, or intends to absorb the difference by cutting quality somewhere you will not see until later.
02Find out who owns the data model
The data model is where modernization programmes succeed or fail. A vendor who intends to lift the existing schema into a new runtime is not modernizing, they are relocating - you get a newer stack wrapped around the same constraints that made the old system hard to change.
Equally, a vendor who wants to redesign the model from first principles without understanding why the current one is shaped the way it is will discover, midway through migration, that several apparently redundant fields encode business rules nobody wrote down.
- Ask how they establish what the current model actually means, not just what it stores
- Ask which parts of the model they expect to change and which they expect to preserve
- Ask how they validate that the new model produces the same answers as the old one
- Be wary of any answer that treats the schema as a technical detail rather than the core of the work
03Sequencing tells you more than architecture
A credible modernization plan delivers value before it finishes. If the first business-visible outcome arrives in month nine, the programme has no way to prove it is working, and no way to recover if the assumptions were wrong.
Good sequencing usually means putting a facade in front of the legacy system early, moving consumers onto it, and replacing what sits behind it incrementally. Each step is reversible and each one reduces the dependency count on the system you are retiring.
| Proposed sequence | What it usually means | Risk |
|---|---|---|
| Discovery, then big-bang rebuild | Vendor is comfortable with greenfield, less so with migration | High - no reversibility, no early proof |
| Facade first, then incremental replacement | Vendor has retired real systems before | Low - each step independently reversible |
| Lift-and-shift, then optimise later | Fast to deliver, defers the actual problem | Medium - cost moves, constraints do not |
| Rewrite in parallel, cut over at the end | Two systems to maintain and a single cutover | High - divergence grows for the whole programme |
04Check they will tell you not to modernize
Some systems should be left alone. A stable back-office system that changes twice a year, has no scaling pressure and is not blocking anything is not a modernization candidate, however old the stack is. Age is not a business case.
A vendor whose assessment never concludes 'leave this one' is selling capacity rather than judgement. Ask directly which parts of your estate they would not touch, and why. The answer tells you whether they are optimising for your outcome or their utilisation.
05The commercial shape should match the uncertainty
Fixed price on a system nobody has read is a bet, and the vendor prices the bet by padding it. You pay for uncertainty whether or not it materialises, and the vendor is incentivised to resist scope discovery that would have improved the outcome.
The shape that usually works is a fixed-price discovery producing a costed plan, then time and materials or capped phases against that plan. You buy the estimate before you buy the build, and both sides are working from the same evidence.
- Fixed-price discovery: appropriate, bounded, produces a real artefact
- Fixed-price build before discovery: priced for risk you may not have
- Open-ended time and materials with no plan: no cost ceiling, no accountability
- Capped phases against a discovery output: usually the right balance
Topics
Marcus Hale
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.