Legacy Application Modernization Services: What You Are Buying, and Why the Firm That Recommends It Should Not Be the Firm That Builds It

The phrase "legacy application modernization services" covers two fundamentally different things, and the market bundles them together in a way that is expensive for buyers. One is an assessment: someone examines your application estate and tells you what should change and why. The other is delivery: someone builds the replacement. The firms that sell both have a word for the first activity. They call it pre-sales.

That is not an accusation. It is a structural observation, and understanding it is the most useful thing you can do before you spend money in this market. The assessment that recommends a ten-million-pound transformation programme is worth a great deal to the firm that will charge ten million pounds to deliver it. That does not make the recommendation wrong. It does make the recommendation something you should check with someone who has nothing to gain from the answer.

What do legacy application modernization services actually include?

The taxonomy matters because it sets your expectations before you sign anything. Advisory services should produce a verdict: for each system, an explicit recommendation - invest, tolerate, migrate, retire - with the cost and risk case stated. Delivery services should produce working software. These are different skills, different incentives, and different measures of success.

What gets sold most often is delivery, with advisory folded in as the engagement ramp. A systems integrator runs a discovery workshop, maps your estate at a surface level, and returns with a proposal. The proposal recommends modernization. This is not surprising. Discovery workshops run by delivery firms have a consistent tendency to find that delivery is needed. The methodology used in those workshops is often proprietary, which means you cannot verify whether the conclusion follows from the evidence or from the revenue model.

The uncomfortable fact is that "legacy application modernization services" as a market category conflates the diagnostic with the surgery, and most buyers do not notice until the surgery is underway.

A genuine advisory engagement does something different. It goes into your estate, maps what actually runs, what it costs, who uses it, and what happens to the business when it fails. It measures the cost of the status quo against the cost of change, and it arrives at verdicts that include "leave it alone" and "retire it without replacing it" as serious options, not just the polite disclaimers before recommending a rebuild.

The three outputs a good assessment should produce are specific enough to be checkable. First, a complete inventory of the estate with usage data attached, not just a list of system names from a configuration management database. Second, a cost-to-run figure for each system that includes licensing, infrastructure, support, and the hidden cost of workarounds that your team performs manually because the system cannot do the job cleanly. Third, a prioritised verdict for each application, with the financial case for acting or not acting stated in terms a CFO can interrogate.

If the firm you are speaking to cannot describe what a "leave it alone" recommendation looks like, or cannot point to engagements where that was the conclusion, you are speaking to a delivery firm using advisory language.

Why does the conflict of interest in modernization services matter in practice?

This dynamic is not unique to technology consulting. It appears wherever the person doing the diagnostic also sells the cure: in financial advice, in engineering surveys, in legal work. The professions that handle it best have formal separation rules. Technology consulting has not developed those rules, partly because the market is fragmented and partly because the conflict is profitable for enough parties that there is no strong pressure to resolve it.

For the person sitting across the table from a systems integrator, the practical consequence is this: the assessment you receive has been shaped by what that firm knows how to build. If the integrator's main capability is cloud migration, the assessment will find cloud migration opportunities. If the main capability is SAP implementation, the assessment will find ERP consolidation opportunities. This is not cynicism; it is pattern recognition. People see what their tools prepare them to see.

The Standish Group's CHAOS research, tracking project outcomes across thousands of engagements over three decades, consistently shows that large technology projects run significantly over time and budget, with the 2020 report finding that projects with budgets above ten million dollars had a success rate of around fifteen percent by the strictest measures. The methodology counts challenged and failed projects separately, so the headline figure varies by definition - read their reports directly rather than relying on summaries. But the direction of the evidence is consistent: large modernization programmes carry substantial risk of delivering less than promised at greater cost than planned.

The implication is that the decision about whether to modernize deserves more rigour than the market currently applies to it, not less.

One figure that is frequently cited in this market deserves scrutiny. The claim that "seventy percent of digital transformations fail" appears in countless vendor presentations and analyst summaries. It traces to McKinsey research from around 2018, but as McKinsey itself has noted in subsequent work, what "failure" means in that figure was never precisely defined in public, and the original study was a survey of executives self-reporting on their own programmes. Use it as a directional signal, not a precise statistic. The directional signal is that large technology change is harder than it appears at the point of commitment.

What this means for buyers is straightforward. Before committing to a modernization programme, have the recommendation reviewed by someone who is not building the replacement. The cost of an independent review is small relative to the cost of the programme. The risk it mitigates is structural, not theoretical.

How should you evaluate what you are being sold?

There are four questions that separate an independent assessment from a pre-sales exercise. They are not combative. They are simply the questions a good buyer asks.

The first is the question above. Any genuine advisory firm can point to engagements where the conclusion was not to modernize. If the answer is that every system reviewed turned out to need modernization, that is statistically unlikely for any mature estate and commercially convenient for the reviewer.

The second question is about methodology. How does the firm arrive at a verdict, and can you see the framework before you commission the work? The Gartner TIME model - Tolerate, Invest, Migrate, Eliminate - is a widely used starting point. Pace-layering, also from Gartner, distinguishes between systems of record, systems of differentiation, and systems of innovation, and treats modernization decisions differently for each. These are publicly documented frameworks. A firm that cannot articulate a comparable methodology is working from instinct, which may be good instinct, but you cannot verify it.

The third question is about cost quantification. Can the firm put a number on what the status quo costs you? Not license fees alone. The full cost: infrastructure, support, the hours your staff spend on manual workarounds, the downtime events over the past three years, the integrations that broke and had to be patched. If the firm cannot help you establish the cost of doing nothing, it cannot demonstrate that the cost of change is justified.

The fourth question is the simplest and the one most buyers forget to ask. What happens if the recommendation is to leave the system alone? What does that engagement look like, and what does it cost? A firm oriented toward delivery will struggle to describe that scenario with any enthusiasm, because it ends the conversation without a contract.

What do legacy application modernization services cost, and what should that money buy?

The numbers above are real ranges, not marketing figures. What drives variability in assessment cost is not the seniority of the consultants; it is the state of the data. An estate where nobody has a complete application inventory, where cost-to-run figures must be reconstructed from finance records and infrastructure invoices, and where integration maps do not exist in any formal documentation takes longer to assess than one where that groundwork already exists. Most estates are closer to the first description than the second.

Forrester's Total Economic Impact studies on modernization often show significant benefits from replacing legacy systems. It is worth reading those studies carefully, because most of them are vendor-commissioned - Forrester conducts them on behalf of a named technology provider and interviews that provider's customers. They are professionally done, but they are not independent. The benefits shown in a vendor-commissioned TEI are real for the customers profiled; they are not a neutral estimate of what you should expect.

The useful question is not whether modernization can generate return - it can - but whether your specific systems, in your specific context, will generate enough return to justify the cost and the risk of the transition itself.

For systems that are operationally stable, handling functions that do not change frequently, and not blocking other investment, the answer is often that modernization would cost more than it saves over any reasonable time horizon. Gartner's application portfolio management research consistently identifies a category of systems that should be tolerated - kept running as-is, maintained at minimum cost, and not modernized - because the business disruption and capital cost of replacement exceeds the operational benefit. That verdict requires the same rigour as the decision to modernize; it simply produces a different answer.

The delivery side of the market is large. The global application modernization services market is estimated by multiple analyst firms to be growing at a compound annual rate of around fifteen to seventeen percent, reaching tens of billions of dollars by the mid-2020s. Those figures come from market research firms and vary depending on how the category is defined, so treat them as directional. What they signal is that there is an enormous volume of delivery work being done. What they do not tell you is how much of it was justified by rigorous independent assessment versus by an advisory process that was part of the delivery sales cycle.

A buyer who separates the advisory from the delivery, and who pays independently for the first before committing to the second, is in a qualitatively different position from one who lets the delivery firm define the problem. The cost difference between those two approaches is small. The decision quality difference can be significant.

When should you leave the legacy system alone?

This is the question the market does not want to ask loudly, because the answer is inconvenient for firms selling delivery. But it is the question that honest advisory work must be willing to answer.

Konnectedly's core position is that "leave it alone" is a real recommendation, not a placeholder before the modernization pitch. Some systems in almost every estate sit in this category. They run reliably, they are cheap to maintain on an ongoing basis, the team knows them, and the function they perform does not change. Replacing them would consume capital and management attention, would introduce transition risk, and would produce a newer system doing the same job for a higher total cost over five years once you account for the migration, the new licensing model, the retraining, and the integration work.

The decision to leave a system alone is not the same as ignoring it. It means making a deliberate, documented choice to hold it at current investment levels, monitoring for the conditions that would change the verdict - cost escalation, vendor end-of-life announcements, integration failures, regulatory change - and revisiting the decision on a defined schedule.

What changes the verdict? Four things, primarily. First, if the vendor announces end-of-life and support costs are about to rise sharply. Second, if the system is actively preventing a business capability that matters competitively. Third, if the failure rate is increasing and the cost of outages is growing. Fourth, if the integration burden has become so heavy that every change to adjacent systems requires expensive workarounds because of this one. Any of those conditions warrants reopening the decision. None of them is the same as the system being old.

The discipline of "leave it alone as a real verdict" is what separates an advisory firm from a sales process dressed as a consulting engagement.

Frequently Asked Questions

What are legacy application modernization services?

Legacy application modernization services are professional engagements that help organisations evaluate, restructure, replace, or retire software systems that no longer serve the business adequately. They split into two categories: advisory services that assess what should be done, and delivery services that do the work. Buying both from the same firm creates a structural conflict of interest.

How much do legacy application modernization services typically cost?

Advisory assessments of a mid-sized application estate typically run from £40,000 to £150,000 depending on scope and estate complexity. Delivery engagements - the actual rebuild or migration work - run into millions and take years. The assessment cost is the cheapest insurance you can buy before committing to the larger number.

Why should the firm recommending modernization not be the firm building it?

A firm that earns revenue from delivery has a financial incentive to recommend delivery. That incentive is structural, not a question of individual ethics. Even a genuinely capable and honest integrator cannot fully escape it. An advisor who has nothing to sell on the back of the recommendation gives you a different quality of answer.

What does an independent modernization assessment actually produce?

A good independent assessment produces a verdict on each system in the estate - invest, tolerate, migrate, or retire - with the financial case for each decision stated explicitly. It names which systems are worth modernizing, which should be left alone, and which are absorbing cost without delivering value. It does not produce a blueprint for how to build anything.

How long does a legacy application modernization assessment take?

For an estate of twenty to sixty applications, a thorough independent assessment typically takes six to twelve weeks. Faster engagements exist but tend to rely on surface indicators rather than actual usage data, integration mapping, and cost-to-run figures. Speed is worth trading away when the decision is worth millions.

What is the difference between modernization and replacement?

Modernization covers a range of interventions: re-hosting on new infrastructure, re-platforming to a managed service, refactoring the internal code without changing what it does, or re-architecting the system fundamentally. Replacement means retiring the old system and building or buying something new. Many engagements sold as modernization are replacement projects with a softer name.

Which legacy systems should not be modernized?

Systems that handle a stable, low-change function and are not causing operational problems often do not warrant modernization regardless of their age. The question is not how old the system is but what it costs to run, how often it fails, how much it limits adjacent change, and whether a replacement would be cheaper over five years than leaving it alone.

How do I evaluate a legacy application modernization services provider?

Ask one question first: does this firm earn revenue from delivering the work it recommends? If yes, treat its assessment as a proposal, not an independent opinion. Then ask what methodology it uses to reach a verdict of "leave it alone" or "retire it" - firms oriented toward delivery rarely produce those verdicts in volume, because neither generates a follow-on engagement.