Why the Evaluation Stage Matters More Than the Execution Stage
What "Legacy Modernisation" Actually Covers
The Six Criteria That Actually Predict Delivery
1. Do They Assess Before They Propose?
2. Can They Cover the Full Delivery Stack?
3. Is There Strategic Leadership in the Engagement?
4. How Do They Handle Scope Change?
5. What Does Their Track Record Look Like in Comparable Situations?
6. What Is Their Approach to Handover and Knowledge Transfer?
Red Flags to Watch For
Questions Worth Asking in Every Vendor Conversation
The Structural Problem with Talent Marketplaces for Modernisation Work
Why the Approach to AI in Modernisation Matters Now
Putting It Together: A Practical Evaluation Framework
What Good Looks Like
FAQs
Choosing a legacy modernisation partner is one of the highest-stakes vendor decisions a scale-up will make. Get it wrong and you inherit a half-finished migration, a codebase in worse shape than when you started, and a bill that has grown well past the original estimate. Get it right and you emerge with a system that can actually support the next phase of growth.
The problem is that most evaluation frameworks focus on the wrong signals. They ask about technology certifications, team size, and case study logos rather than the questions that actually predict whether a vendor will deliver. This article gives you a structured way to evaluate a legacy modernisation partner before you commit — covering the criteria that matter, the red flags that are easy to miss, and the questions worth asking in every vendor conversation.
Why the Evaluation Stage Matters More Than the Execution Stage
Most modernisation failures are decided before a single line of code is written. A vendor is selected on price or familiarity. Scope is agreed at a high level. The engagement starts. Three months in, the original estimate has doubled, the architecture decisions made in week two are already creating problems, and the client has no visibility into why.
The evaluation stage is where you set the conditions for everything that follows. A vendor who cannot answer precise questions about their approach in a pre-sales conversation will not suddenly become precise once the contract is signed.
This is not a small decision. Legacy modernisation engagements typically run for months, touch every part of your product, and require deep access to your infrastructure, codebase, and team. The vendor you choose will have more influence over your technical trajectory than almost any other partner you bring in.
What "Legacy Modernisation" Actually Covers
Before evaluating vendors, be specific about what you are actually buying. Legacy modernisation is not a single service. It covers several distinct types of work, and vendors vary significantly in which of these they can actually execute.
Codebase modernisation involves refactoring or rewriting existing application code, addressing technical debt, and improving architecture — whether that means breaking a monolith into services, migrating from an outdated framework, or replacing a component that has become a liability.
Infrastructure modernisation involves moving from on-premise or legacy hosting environments to cloud-native infrastructure, implementing CI/CD pipelines, and adopting infrastructure as code practices.
Data modernisation involves migrating data between systems, improving data quality, and building pipelines that support the product's current and future needs.
System integration and replacement involves replacing or integrating enterprise systems — ERP or HRM platforms, for example — that have become bottlenecks.
A vendor who is strong at codebase refactoring may have no experience with infrastructure engineering. A vendor who specialises in cloud migrations may have no capacity to handle the application layer. Define which categories your engagement falls into before you evaluate anyone, because a vendor's answer to "can you do this?" is almost always yes.
The Six Criteria That Actually Predict Delivery
1. Do They Assess Before They Propose?
A credible legacy modernisation partner will not send you a proposal until they understand what they are working with. The codebase, the infrastructure, the team, the dependencies, the risk surface. All of it.
If a vendor produces a fixed-price proposal after a single discovery call, that is a signal they are pricing to win the work rather than pricing to deliver it. Legacy systems are complex by definition. A vendor who has not looked at yours cannot accurately estimate the effort involved.
Ask directly: what does your assessment process look like, and what does it produce? A structured technical assessment should result in a documented output — not just a verbal summary. We offer a fixed-scope Technical Readiness Report as a standalone engagement before any modernisation work begins. That kind of structured front-end assessment is what separates a vendor who understands the problem from one who is guessing.
2. Can They Cover the Full Delivery Stack?
Legacy modernisation rarely stays in one lane. You start with a codebase refactor and discover the infrastructure cannot support the new architecture. You start with a cloud migration and find the application layer needs to change to take advantage of it. You replace an ERP system and realise the data migration is more complex than anyone anticipated.
A vendor who can only handle one layer of the stack will either stop when the work goes out of scope or bring in subcontractors you have never vetted. Neither outcome is good.
Evaluate whether the vendor has genuine capability across architecture, development, DevOps, QA, and — where relevant — enterprise system implementation. Not just as named services on a website, but as demonstrated delivery capacity with the people to back it up.
3. Is There Strategic Leadership in the Engagement?
Technical execution without strategic oversight produces technically correct work that does not serve the business. Someone in the engagement needs to be making architecture decisions with the full picture in mind: where the product is going, what the investor or board expects, what the team can maintain after the vendor leaves.
Many modernisation vendors provide execution capacity with no strategic layer. They ship what they are told to ship. If the client does not have a CTO or a senior technical leader who can direct the work, that is a serious gap.
Ask who in the vendor's team is accountable for architecture decisions. Ask how that person communicates with you. Ask what happens when a decision arises that was not covered in the original scope.
A firm that combines Fractional CTO leadership with embedded engineering execution solves this problem structurally. The strategic layer and the delivery layer sit in the same engagement, which means architecture decisions are made by someone who is also accountable for the outcome.
4. How Do They Handle Scope Change?
Legacy modernisation almost always uncovers work that was not in the original scope. The question is not whether scope will change — it is how the vendor handles it when it does.
A vendor who responds to every unexpected finding with a change order will drain your budget on administration. A vendor who absorbs every scope change without discussion will eventually stop delivering because they have run out of margin.
Ask for a specific example of a past engagement where scope changed significantly. How did they identify it? How did they communicate it? How was it resolved? That answer tells you more about how the engagement will actually run than any contractual language.
5. What Does Their Track Record Look Like in Comparable Situations?
Case studies matter, but not all case studies are equal. A vendor who has modernised a retail e-commerce platform may have no relevant experience with a FinTech product under regulatory scrutiny. A vendor who has rebuilt a consumer app may have never dealt with the complexity of a B2B SaaS product with deep integrations.
Look for case studies that share meaningful characteristics with your situation: similar scale, similar technical environment, similar business stakes. The specifics matter.
We have documented case studies across post-cyber-attack infrastructure recovery, custom platform builds, and AI-assisted analysis. The post-cyber attack recovery case study, for instance, involved a codebase that had operated for a decade without C-level technical leadership — with all the accumulated debt that implies. That is a different engagement profile from a greenfield build, and the approach reflects it.
6. What Is Their Approach to Handover and Knowledge Transfer?
A modernisation engagement that ends with the client dependent on the vendor for ongoing support has not fully succeeded. The work should leave your team in a better position to own and operate the system — not more reliant on external help.
Ask specifically: what documentation do you produce? How do you transfer knowledge to our team? What does a completed engagement look like from our side?
If the vendor is vague on this, that is a signal. Either they have not thought about it, or they have a commercial interest in keeping you dependent.
Red Flags to Watch For
Vague discovery process. If a vendor cannot describe a structured approach to understanding your system before proposing a solution, they are guessing. Legacy systems are not generic. The approach has to be grounded in what is actually there.
No clear owner for architecture decisions. If you ask "who makes architecture decisions in your engagement?" and the answer is unclear, that is a problem. Architecture decisions in a modernisation engagement have long-term consequences. Someone has to own them.
Overemphasis on technology stack. A vendor who leads with their preferred frameworks and tools before understanding your constraints is optimising for their delivery process, not your outcome. The technology should follow the requirements, not the other way around.
No evidence of QA as a discipline. Modernisation work that is not tested properly introduces new risk while removing old risk. Ask how QA is integrated into the engagement — not bolted on at the end.
Inability to describe what "done" looks like. A credible vendor should be able to describe, in concrete terms, what a completed engagement produces. If the answer is vague, the engagement will be vague.
Security treated as an afterthought. Legacy systems often carry significant security debt. A vendor who does not raise security considerations early in the conversation either lacks the expertise or is not looking at the full picture. For organisations handling sensitive data, that gap can have serious consequences well beyond the engineering work itself.
Questions Worth Asking in Every Vendor Conversation
These questions are designed to surface what actually matters, rather than giving the vendor an opportunity to run their standard pitch.
Walk me through your assessment process. What do you produce before you propose a solution?
Give me a specific example of a legacy modernisation engagement that did not go to plan. What happened, and how did you handle it?
Who in your team is accountable for architecture decisions, and how do they communicate with us?
How do you handle scope change when you discover something in the codebase that was not in the original brief?
What does a completed engagement look like from our side? What can our team do after you leave that they could not do before?
How do you integrate QA into the engagement, and at what stage?
What is your approach to security risk during the modernisation process?
The answers to these questions will tell you more than any proposal document.
The Structural Problem with Talent Marketplaces for Modernisation Work
It is worth addressing a common mistake directly. Talent marketplaces — whether they place individual contractors or developers — are not legacy modernisation partners. They provide people. They do not provide strategy, architecture ownership, QA discipline, or delivery accountability.
When you hire an individual developer through a marketplace to work on a legacy modernisation project, you take on the coordination, the architecture decisions, the QA, and the risk. That may be appropriate in some situations. It is not appropriate when the work is complex, the stakes are high, and you do not have the in-house technical leadership to direct it.
The distinction matters because the evaluation criteria are different. A marketplace is evaluated on the quality of individual candidates. A modernisation partner is evaluated on the quality of their process, their team structure, and their delivery track record.
Why the Approach to AI in Modernisation Matters Now
Legacy modernisation work has changed meaningfully since production AI agents became a practical tool in 2024. The ability to analyse a large, poorly documented codebase quickly — identifying dependencies, surfacing risk areas, generating documentation — is no longer theoretical.
The 57-page analysis in 3 hours case study illustrates what this looks like in practice. Work that previously required weeks of manual analysis can now be completed in hours, which changes the economics and timeline of the assessment phase significantly.
When evaluating a legacy modernisation partner, ask specifically how they use AI in the assessment and delivery process. Not as a marketing claim — as a practical question. What does the AI do? What does it produce? How is that output validated by a human engineer?
A vendor who cannot answer this specifically either does not use AI in any meaningful way, or uses it in ways they cannot explain. Neither is reassuring.
Putting It Together: A Practical Evaluation Framework
Before you start vendor conversations, define the following:
Which categories of modernisation work are in scope — codebase, infrastructure, data, systems?
What does success look like in concrete terms, and by when?
What does your team need to be able to do after the engagement ends?
What is the risk surface if the engagement goes wrong?
Then evaluate each vendor against the six criteria above: structured assessment, full-stack delivery capability, strategic leadership, scope change handling, comparable track record, and handover approach.
Use the questions from the previous section to probe beyond the standard pitch. Pay close attention to how vendors handle uncertainty — because legacy modernisation is full of it.
If you want a structured starting point for the modernisation process itself, the 12-week legacy modernisation framework on the WireApps blog provides a phased approach to the work that maps directly to the evaluation criteria above.
What Good Looks Like
The right legacy modernisation partner does a few things consistently. They assess before they propose. They own architecture decisions. They integrate QA from the start. They communicate scope change clearly and early. They leave your team in a better position than they found it.
They also have the range to follow the work wherever it goes — whether that is into the infrastructure layer, the application layer, or an enterprise system that turns out to be more entangled with your product than anyone realised.
We work with scale-ups on exactly this kind of engagement, combining Fractional CTO leadership with embedded engineering pods and production AI agents in a single team. Over 200,000 users are on live products built or supported through that model. If you are at the point of evaluating partners for a modernisation engagement, a strategy call is the right starting point. You can find out more at wireapps.co.uk.
FAQs
What is a legacy modernisation partner?
A legacy modernisation partner is a vendor or firm that takes accountability for upgrading, refactoring, or replacing an outdated technical system. Unlike a talent marketplace that provides individual developers, a modernisation partner owns the process, the architecture decisions, and the delivery outcome.
How do I know if a vendor can handle legacy modernisation or is just saying they can?
Ask them to describe their assessment process in detail, then ask for a case study from an engagement with similar characteristics to yours. A vendor who cannot describe a structured assessment approach — or cannot point to comparable work — is unlikely to have the depth the engagement requires.
What is the difference between a legacy modernisation partner and a staff augmentation firm?
Staff augmentation provides people. A modernisation partner provides a process, strategic leadership, and delivery accountability. For complex legacy work, that distinction matters significantly. The coordination, architecture decisions, and risk management all fall to you when you are working with augmented individuals rather than a team with a structured approach.
How long does a legacy modernisation engagement typically take?
It depends heavily on the scope and the state of the existing system. A well-structured engagement runs in phases, with the first phase focused on assessment and stabilisation before any significant architectural change begins. Engagements can run from three months for targeted modernisation work to twelve months or more for a full system overhaul.
What should a legacy modernisation assessment produce?
A credible assessment should produce a documented output covering the current state of the system, the key risk areas, the recommended approach, and a realistic estimate of the effort involved. Verbal summaries are not sufficient. That documentation becomes the basis for every decision that follows.
How do I evaluate whether a vendor's AI capabilities are real?
Ask specifically what the AI does in their process, what it produces, and how a human engineer validates the output. A vendor with genuine AI capability will answer this concretely. Vague claims about "AI-powered" or "AI-assisted" development without specifics are not meaningful.
What happens if the scope changes significantly during a modernisation engagement?
This is one of the most important questions to ask before committing. A good vendor will have a clear process for identifying scope change, communicating it early, and agreeing how to handle it. Ask for a specific example from a past engagement. How a vendor handled scope change before is the best predictor of how they will handle it in yours.
Share
