Application Modernization Services: How to Buy the Advice Without Buying the Build

The same meeting happens in organisations everywhere. Someone from a large consulting or systems integration firm stands at the front of the room and presents a modernization roadmap. It is detailed. It is convincing. It recommends a substantial programme of work. What it does not say out loud is that the firm presenting it would also like to build everything on slides seven through forty-two. That is not a scandal. It is simply how application modernization services are usually structured, and it is worth understanding before you sign anything.

The conflict is not invented. It is mechanical. A firm that earns its revenue from delivery projects has a rational interest in recommending delivery projects. The analysis that precedes the recommendation is real work, often good work, but it is conducted inside an incentive structure that points in one direction. The buyer who does not account for that is not naive; they are simply operating without the full picture.

This post is about how to get the full picture. Specifically, how to buy modernization advice in a way that separates the diagnosis from the prescription, and what that separation is actually worth.

What do application modernization services actually include?

The term "application modernization services" gets applied to a wide range of commercial offerings. At one end, it describes a pure advisory engagement: an outside team comes in, examines the application portfolio, and tells the organisation which systems deserve investment, which should be retired, and which to leave alone. At the other end, it describes a full delivery programme: a systems integrator takes a legacy platform and replaces it with something newer. Most of what the market sells sits somewhere between those poles, and that middle ground is where the conflict of interest lives.

The pattern typically runs like this. A firm is engaged to assess the estate. The assessment is genuine work. Workshops are run, architects are interviewed, licence costs are pulled from procurement, and a heat map appears showing which systems are in trouble. Then the same firm presents a roadmap for what to do about it. The roadmap is also genuine work. But it has been shaped, consciously or not, by the fact that the firm's revenue model depends on delivery contracts.

The critical question is not whether the assessment is accurate. It is whether the assessment would have reached the same conclusions in the hands of someone with nothing to build.

Martin Fowler's writing on the strangler fig pattern and related modernization approaches is rigorous and widely cited. The patterns themselves are sound. The issue is not technical; it is commercial. Good patterns can still be applied to systems that did not need them, recommended by people who would benefit from applying them.

A clean separation looks like this: one firm assesses and produces a disposition for every system in the estate. A different firm, or multiple firms competing for discrete pieces of work, executes against that disposition. The buying organisation holds the assessment as an independent reference point. When a delivery proposal arrives recommending something different from the assessment, the organisation can ask why. Without the independent assessment, there is no reference point.

How do I tell whether a modernization recommendation is independent?

There is a simple test, and most vendors will answer it honestly if asked directly. Ask whether the advisory practice and the delivery practice share a revenue target or sit inside the same commercial unit. Ask whether the advisory team is compensated, in whole or in part, based on work that flows from their recommendations. Ask for a list of the last ten clients who received assessments and then did not engage the same firm for delivery.

That last question is the useful one. If a firm's assessments reliably conclude that modernization is necessary, and the same firm reliably delivers that modernization, the two facts together are worth examining. A genuinely independent assessor will sometimes conclude that the right answer is to leave a system alone, or to retire it without replacing it, or to make a small configuration change that costs almost nothing. Those conclusions do not generate delivery revenue. Advisors who reach them regularly are demonstrating something about their incentive structure.

The Standish Group CHAOS reports have tracked IT project outcomes for decades. Their methodology is debated - they count partial successes and outright failures together in ways that researchers have criticised - but the persistent finding that large software delivery projects regularly overrun time and budget is consistent with other evidence. McKinsey research on large-scale IT programmes (read critically: McKinsey also sells delivery services) has found similar patterns. The point is not that delivery firms are incompetent. The point is that every project has optimistic assumptions at the start, and an advisor with a financial interest in the project proceeding has less reason to scrutinise those assumptions.

What you are buying when you buy an independent assessment is the scrutiny that the delivery proposal did not receive.

Gartner's TIME model (Tolerate, Invest, Migrate, Eliminate) provides a structured framework for making system-level decisions in an application portfolio. The model itself is freely described in Gartner's application portfolio management research. What it cannot supply is the organisational will to reach a Tolerate or Eliminate verdict and hold it against a delivery firm that would prefer an Invest or Migrate conclusion.

What does an honest assessment cost, and what should it produce?

The figure varies, and any range should be treated as a starting point for a conversation rather than a quote. What drives the cost upward is not the number of applications but the state of the evidence. An estate with current architecture diagrams, clean procurement records, and engineers who have time to be interviewed costs less to assess than one where the documentation is scattered across shared drives and three of the most important systems were built by people who left five years ago.

What a credible assessment should produce is a disposition for every system in the scope: invest, migrate, tolerate, or retire. Those dispositions should be supported by evidence, not just categorised by gut feel. The evidence should include an operating cost estimate (licence, infrastructure, and the hidden cost of engineer time spent maintaining rather than building), a risk assessment (what happens if this system fails, and how hard is it to recover), and a business criticality judgement (does this system do something the organisation genuinely cannot operate without).

Critically, the assessment should name systems that do not need to change. An assessment that recommends investment or migration for every system in the estate has not done the work; it has produced a sales document with a methodology attached.

The Harvard Business Review has published research on decision-making under uncertainty in IT governance, and the consistent finding is that organisations over-invest in visible, active interventions and under-invest in the discipline of deciding not to intervene. A system that has run reliably for fifteen years, serves a stable function, and costs a predictable amount per year may be the least interesting thing in the estate to an outside advisor, but it may also be the system that most deserves to be left alone.

There is a worked example worth carrying. A manufacturing company with 90 applications in its estate commissions an assessment. The assessment finds that 20 systems are good candidates for retirement, 15 for investment, 8 for migration to newer platforms, and 47 for the simplest possible disposition: leave them alone, monitor them, and revisit in three years. If the firm delivering that assessment had also been trying to sell a delivery programme, the 47 "leave alone" calls represent a substantial reduction in potential revenue. That tension is not theoretical.

When does "leave it alone" become the right answer for a legacy system?

The word "legacy" has become detached from its useful meaning. A legacy system is not simply an old system; it is a system that constrains the organisation's ability to do something it needs to do. A system running on a 2003 platform that processes payroll without incident, costs a fixed and affordable amount per year, and requires no changes because payroll has not changed is not a problem. It is infrastructure. The fact that it runs on old technology is an argument for having a continuity plan, not an argument for a replacement programme.

The Stack Overflow Developer Survey tracks what technologies engineers are actually working with, and it consistently shows that the gap between "what is being built new" and "what is running in production" is enormous. That gap is not, by itself, a risk. It becomes a risk when systems cannot be maintained because the people who understand them have left and there is nobody to replace them, when systems cannot connect to other systems the business needs them to connect to, or when systems fail in ways the organisation cannot recover from cleanly.

The question is not "how old is this system?" but "what can we not do because of this system, and what would it cost to change that?"

The case for leaving a system alone is strongest when the answers to those questions are "not much" and "more than we would gain." That is a financial and operational judgement. It requires numbers. The figure that matters is not the age of the platform or the obscurity of the programming language. It is the annual cost of running the system, including the cost of engineer time spent on maintenance, compared to the cost and risk of replacement, including the probability that the replacement project overruns.

Large systems integrators sometimes present modernization as a risk reduction exercise: replace the old system before it fails. That argument deserves scrutiny. What is the actual failure scenario? How likely is it in the next three to five years? What would recovery cost if it occurred? And how does that expected cost compare to the certain cost of a replacement programme? Those are the numbers that belong in an honest conversation, and they are numbers an independent assessor has less reason to shade than a delivery firm does.

How should a buying organisation structure the engagement to protect itself?

The structural safeguard is straightforward even if it requires some organisational discipline to hold. Commission the assessment first, as a standalone engagement, with a firm whose business model does not depend on delivery revenue. Take the output - system dispositions, cost evidence, risk ratings - and treat it as the buyer's reference document. Then go to market for the delivery work, separately, with the assessment in hand.

When a delivery firm proposes a scope that is larger than the assessment recommended, ask what evidence changed the conclusion. Sometimes the answer is legitimate: the assessment was high-level, the detailed technical analysis found something the assessment missed, and the additional scope is genuinely justified. That happens. But sometimes the answer reveals that the delivery firm's proposal is based on assumptions the assessment already examined and rejected. Without the independent assessment, the buyer has no way to make that distinction.

Konnectedly's model is built around exactly this separation: assessment and disposition without delivery, so the recommendation has no commercial attachment to any particular outcome. That is not a unique invention; it is a straightforward structure that removes a known conflict. Any firm offering the same structure deserves the same consideration.

The practical steps are worth spelling out. Before engaging any firm for modernization work, ask for a system-by-system inventory and cost baseline. If one does not exist internally, that inventory is the first deliverable to commission. Without it, any modernization recommendation is based on incomplete information, and the gaps tend to be filled with assumptions that favour more work rather than less.

Then apply a simple filter to any proposal that arrives: for each system the proposal touches, what is the specific business or operational problem that the proposed change solves? Not "it is old" or "it is not cloud-native" or "it uses a programming language that is out of support." A specific problem: the system cannot integrate with the new CRM, or it fails under load conditions the business now regularly encounters, or it cannot be audited in the way the regulator now requires. If the proposal cannot name the specific problem for each system it proposes to touch, that is useful information.

The buying organisation's leverage is exactly proportional to the quality of the independent information it holds going into the conversation.

Frequently Asked Questions

What are application modernization services?

Application modernization services are advisory or delivery engagements that assess aging software systems and recommend - or carry out - changes to extend their usefulness, reduce operating cost, or replace them. They range from pure assessment and strategy work to full rebuild and migration projects. The two categories have fundamentally different incentive structures.

What is the difference between an assessment and a modernization project?

An assessment answers the question of what to do and why. A modernization project does it. A firm that sells both has a financial reason to recommend more work than necessary. An independent assessment, delivered before any vendor is selected, gives the buying organisation a basis for evaluating project proposals rather than accepting them.

How much do application modernization services typically cost?

Assessment engagements for a mid-sized application estate typically run from £30,000 to £150,000 depending on the number of systems, the availability of documentation, and the depth of technical analysis required. Full modernization projects are orders of magnitude larger. Conflating the two in a single contract is where the cost control problem usually starts.

How do I know if a modernization recommendation is biased?

Ask who benefits from the recommended path. If the firm advising you will also build the replacement, refactor the codebase, or manage the migration, it benefits from a larger scope and a longer timeline. That is not corruption; it is a structural incentive. The safeguard is separating the advisory engagement from the delivery contract, with different firms or at minimum a formal independence barrier between them.

What should an application modernization assessment actually deliver?

A credible assessment should deliver a system-by-system disposition for the full estate - invest, migrate, retire, or leave alone - with the financial and operational evidence for each call. It should name systems the organisation can safely ignore. Any assessment that recommends modernization for every system in the portfolio has not done the work.

Can a large systems integrator provide independent modernization advice?

Rarely in practice. Large integrators earn most of their revenue from delivery work, so their advisory practices are commercially connected to their project pipelines. Some maintain formal separation, and a few individuals within those firms are genuinely rigorous. But the institutional incentive runs toward recommending work, and a buyer who understands that is in a better position to push back on the findings.

When is "leave it alone" the right modernization recommendation?

When the system is stable, the cost to run it is predictable, it does not block anything the business urgently needs to change, and the disruption of replacement would exceed any foreseeable benefit. A system that has run without significant incident for a decade and serves a function that will not change materially is often best left alone. The burden of proof should sit with the case for change, not the case for stability.

How long does an application modernization assessment take?

For an estate of 50 to 150 applications, a rigorous assessment typically takes eight to sixteen weeks. Shorter engagements are possible for smaller estates or when documentation is unusually good. Assessments that conclude in under four weeks for large estates are almost always based on interviews and financial proxies rather than genuine technical analysis, and their recommendations carry that limitation.