Resource · Legacy Modernisation
How to choose a legacy modernisation partner.
A buyer’s guide for evaluating modernisation consultancies, written by one. Five criteria that matter, the engagement models that actually align incentives with yours, and the four situations where the honest recommendation is to not hire anyone. Useful even if you do not end up hiring us.
Modernisation engagements fail more often than they succeed, and they fail most expensively when the wrong partner is picked. The signal is rarely the partner’s logo or the polish of their pitch deck. It is in their answers to a small number of specific questions about how they work, how they price, and what they refuse to do. This page is the framework we wish more buyers brought to the first call.
What to evaluate by
Five criteria
These are the criteria that separate a successful modernisation from a stalled one. Track record matters less than people assume. Approach matters far more.
1
Approach: incremental or big-bang?
The single most important question. A partner who proposes to rewrite your system over 12-18 months while you keep paying for the old one is selling you a failure with a long lead time. The strangler-fig pattern (new system built alongside the old, traffic moved gradually as components prove themselves) is the only sane approach for non-trivial modernisations. If a partner cannot describe their incremental migration plan in concrete steps, they do not have one.
What to look for
A documented incremental approach with traffic-cutover milestones, dependency mapping, and a plan for running the two systems side by side during transition.
2
Accountability: phased milestones with stop-points
A serious engagement is broken into phases with their own milestones, acceptance criteria, and prices. At the end of every phase, you can stop, redirect, or extend. This protects you when the work surfaces something nobody planned for (which it always does). Open-ended retainers and lump-sum fixed bids fail the same way: by removing your ability to change your mind without losing everything.
What to look for
A phased plan where each phase is independently priced and acceptance-tested. Stop-points written into the contract.
3
Knowledge transfer baked into the engagement
When the partner leaves, your team has to maintain and extend what they built. If knowledge transfer happens only in the last sprint (or in a single handover document), it will not actually transfer. Real handover is pair programming during build, documentation as you go, ADRs for every meaningful decision, and a final phase where your engineers ship without the partner present.
What to look for
Knowledge transfer as a continuous activity, not a milestone. Pair programming. Architecture decision records. A defined exit ramp with your team operating solo.
4
Team continuity: who actually does the work?
The senior partner in the pitch room is rarely the person writing the code. The standard pattern is senior pitch, junior delivery, with the senior re-appearing only when escalations happen. This is fine for some kinds of work and ruinous for modernisations, because modernisation work needs continuous judgement. Ask explicitly who will be in the work, and ask them to be in the pitch.
What to look for
The people in the pitch are the people in the work. Named individuals, fixed allocation, no swap-outs without your approval.
5
Pricing transparency
How a partner prices their work tells you how they think about risk. Fixed price for the whole engagement transfers the risk to them, which means they will pad heavily for the unknowns. Time and materials transfers the risk to you, which means the meter runs whether or not you are getting value. Milestone-priced phases split the risk: each phase has a fixed price, but the engagement can stop or re-scope at any phase boundary. That is the model that aligns with the strangler-fig approach.
What to look for
Per-phase fixed pricing with explicit acceptance criteria, openly discussed before contracts are signed.
How the work gets priced
Three engagement models
How a partner prices their work tells you how they think about risk. Two of these three models do not fit modernisation work well, for opposite reasons. The third is the one to insist on.
Fixed price for the whole engagement
Fit for
Small, well-scoped work where the unknowns are minimal.
Risk shape
Bad fit for modernisations. The partner pads heavily for unknowns, then either underspends and pockets the margin or hits the cap and produces scope-cut deliverables. You have no way to redirect mid-flight.
Time and materials
Fit for
Open-ended exploratory work where you genuinely cannot scope anything.
Risk shape
Bad fit for modernisations. The meter runs whether or not value lands. Without milestones, there is no forcing function for the partner to ship.
Milestone-priced phases
Fit for
The right shape for modernisation. Each phase has a fixed price and acceptance criteria. You can stop, redirect, or extend at every phase boundary.
Risk shape
Requires both sides to scope each phase honestly. Some partners resist because it caps their upside on the easy phases.
When the right answer is "nobody"
When you should not hire a partner
Hiring a modernisation partner is the right move in many cases and the wrong move in some. Four situations where the honest recommendation is to not engage at all.
The system is small enough that two of your own engineers could do it in a quarter.
Partner overhead is real. If the work is genuinely a small project, your team is the cheaper and faster option, even accounting for the time they would not be doing something else.
Your team has the capability and the bandwidth.
A partner is most valuable when there is a real skill or capacity gap. If both exist internally, you are paying for an outside opinion, which is what an advisor is for, not a delivery partner.
You are not committed to the modernisation.
If the work will be paused every quarter when something else surfaces, the partner cannot deliver and you will lose the budget for both. Wait until the commitment is real.
The system is genuinely throwaway.
If the legacy system will be retired with the product, do not modernise it. Decommission it. The cheapest modernisation is the one you do not do.
Frequently asked
Questions we get
How long should the partner evaluation take?
Two to four weeks for most engagements. Past that, you are usually deferring a decision rather than gathering more information. A 15-minute fit call to confirm shape, a longer scoping conversation, and a written proposal is enough to make a real choice. Multi-month procurement cycles often select for the wrong things: the partners with the patience to navigate procurement, not the partners with the best judgement on your problem.
Should we put it out to formal RFP?
Usually no, for engagements under $500K. Formal RFPs select for sales operations rather than technical fit, which is the opposite of what you want for modernisation. A short brief shared with three to five named partners produces better matches in less time. RFPs make sense when procurement or regulatory rules require them, or when you genuinely cannot pre-shortlist the field.
How many partners should we evaluate?
Three is usually enough. Five if the work is unusually shaped and you need to triangulate. Beyond five, you are pattern-matching the partners against each other rather than against your actual problem. Better to invest the saved time in a deeper conversation with each finalist.
Do we need a partner with deep experience in our specific tech stack?
Less than you would think. Strong general engineering judgement transfers across stacks better than narrow specialism transfers across problems. Look for partners who can describe their general approach to systems like yours, not partners who tick the keyword box for your specific framework. The exception: regulated industries (finance, healthcare, defence) where domain knowledge dominates technical depth.
What about offshore or near-shore delivery teams?
They can work, with two caveats. First, the senior people in the pitch should be in the delivery, not on a different continent from it. Second, time zone overlap matters more than people admit; if there is a one-hour window each day for live conversation, modernisation work will slip because the back-and-forth tempo cannot keep up.
How is your Technical Assessment different from a pitch?
A pitch is a sales conversation. A Technical Assessment is a one-to-two-week paid engagement that gives you a phased modernisation plan with milestone-based pricing for the work that follows. It is the cheapest, lowest-risk way to evaluate us against any other partner: at the end of two weeks you have an artefact you can hold up against their proposal, or take to a different partner entirely. The assessment is the only fixed-price item; everything after it is scoped phase by phase.
The cheapest way to evaluate any modernisation partner is to put one to work.
Our Technical Assessment is a one-to-two week paid engagement that ends in a phased modernisation plan with milestone-based pricing for the work that follows. Fixed-price, no surprises. At the end of two weeks you have an artefact you can hold up against any other partner’s proposal, or take to a different partner entirely.