Legacy System Modernization: What an Independent Assessment Produces in Nine Weeks (and What It Deliberately Leaves Out)

The steering committee has seen the report. It lists seventeen systems as "high risk" and recommends a modernization programme. The consultancy that wrote the report has also attached a proposal to run that programme. Nobody in the room finds this suspicious, because it has always worked this way. The question that never gets asked is what a report would look like if the person writing it had nothing to sell on the back of it. Legacy system modernization assessments can be structured that way. Most are not.

That gap between what an assessment is and what it usually becomes is the subject of this post. Not the technology. Not the architecture patterns. The specific, bounded question of what nine weeks of structured independent analysis produces, what it costs, what it does not cover, and how a senior decision-maker should use the output when it arrives on their desk.

What is legacy system modernization, and why does the definition matter to the person funding it?

The word "legacy" is used loosely, and the looseness is expensive. A legacy system is not simply an old system. Martin Fowler defines legacy code as code without tests, which is a useful technical framing, but for a business decision-maker the more practical definition is: a system whose cost of change has grown to the point where it limits business capability. By that definition, a five-year-old system can be legacy and a thirty-year-old one might not be.

The definition determines the scope of the problem, and the scope determines the size of the budget someone will ask you for. If every system older than ten years is classified as legacy, the modernization backlog becomes large enough to justify a programme that runs for years and costs eight figures. If the question is instead "which systems are limiting a business capability we care about right now?", the list is usually much shorter and much more fundable.

This is the first thing an honest independent assessment does: it refuses the broad definition and forces the question to become specific. Which capabilities are being limited? By how much? At what cost to the business? What would change if the constraint were removed? Only when those four questions have answers does the assessment move to asking what should be done about the system underneath.

What does an independent legacy system modernization assessment produce in practice?

The output of a nine-week assessment is a document, not a programme. That distinction matters more than it sounds. A document records a judgement and its reasoning. A programme commits resources and momentum. Conflating the two is how organisations end up running a seven-figure transformation that nobody can stop, even when the original reasoning no longer holds.

The decision register covers each significant system in the estate. For each one it records: what the system does, who depends on it, what it costs to run (licence, infrastructure, and staff time), what risks it carries (security, vendor support, integration fragility), and how well it serves the business capability it was built for. Against those inputs, the register records a disposition and the reasoning behind it.

The dispositions are four. Retire: the system serves a function the business no longer needs, or serves it in a way that creates more cost than value. Replace: the system is limiting a capability that matters, and the cost of replacement is justified by the reduction in running cost or risk. Retain with investment: the system is worth keeping but needs targeted improvement in a specific area. Leave alone: the system is stable, understood, and not on a deteriorating path. No action is warranted.

The "leave it alone" category is not a failure of analysis. It is usually the most important finding. An estate of forty systems typically produces four or five candidates for replacement, three or four for retirement, a handful for targeted investment, and the rest as leave-alone. If an assessment produces a different distribution, with most systems in the replace column, the reader should ask what the assessment firm earns from that outcome.

The register also includes a cost-to-proceed estimate for each system in the replace or invest category. This is not a build estimate. It is a range, based on comparable projects, intended to let the steering committee prioritise and fund the next stage of decision-making. The range will be wide. That is honest. A precise figure at this stage would require the kind of detailed design work that belongs in a separate, later exercise.

Why does the assessment take nine weeks, and what happens in each stage?

The timeline breaks into three stages, and each one has a different failure mode if it is rushed.

Weeks one and two are inventory and interview. The goal is to establish what systems exist, what they do, and what they cost. The documentation is almost always incomplete. Systems that were decommissioned two years ago still appear on the register. Systems that are business-critical appear nowhere because they were built by a team that has since left. The interviews are not technical deep-dives; they are structured conversations with the people who depend on each system: operations, finance, compliance, and the support team. These conversations produce the information that no CMDB has ever captured.

Weeks three through six are analysis. The assessment team works through the inventory against the four scoring criteria: business criticality, cost to run, risk, and strategic fit. Each score is documented with the evidence that supports it. Where the evidence is thin, the register records that explicitly rather than substituting an assumption. This stage also produces the first draft of the dispositions, which are circulated internally before any stakeholder sees them.

Weeks seven and eight are validation. The draft dispositions go back to the stakeholders who contributed to the interviews, with the reasoning visible. The goal is not to negotiate the findings but to catch errors in the evidence. A system scored as low-criticality because it appears rarely in support tickets may turn out to be critical precisely because nobody touches it: it runs quietly and the business would stop if it failed. Validation catches that kind of error before it becomes a decision.

Week nine is production of the final register and a presentation to the steering committee. The presentation is not a sales pitch for the next engagement. It is a structured walk through the dispositions, the reasoning, and the cost-to-proceed ranges, followed by a recommendation on which systems warrant a funded next step and in what order.

What does the assessment deliberately leave out?

This is the boundary that separates an advisory exercise from a sales process, and it is worth being specific about what sits on each side.

The assessment covers: what the system does, what it costs, what risks it carries, whether it is worth keeping, and roughly what it would cost to change. It does not cover: how to change it, which technology to change it to, which vendor to hire, or what the implementation plan looks like.

Those exclusions are not a limitation of the advisory model. They are the point of it. The moment an assessment firm specifies an architecture, it has an interest in that architecture being selected. The moment it names a vendor, it has an interest in that vendor winning. The moment it produces an implementation plan, it has an interest in being hired to run it.

Gartner's TIME model - Tolerate, Invest, Migrate, Eliminate - is useful here. It frames modernization as a portfolio decision, not a technical project. The decision is "what do we do with this system?" The technical project is what happens after the decision is made. Gartner has consistently argued, across multiple research notes, that organisations conflate these two stages and hand the second stage to whoever answered the first. That conflation is expensive.

The practical test is simple: could the firm that wrote the assessment earn money from the opposite recommendation? If a firm recommends leaving a system alone and that recommendation costs them a rebuild contract, the firm has demonstrated that its incentives are aligned with the client. If the firm earns nothing from "leave it alone" because it only earns from builds, the recommendation to modernize should be treated as evidence of incentive, not evidence of need.

What does an independent assessment cost, and how should that cost be evaluated?

The range is wide because the inputs vary significantly. An estate of twenty systems with reasonable documentation and a stable team to interview runs faster and cheaper than an estate of eighty systems where half the institutional knowledge left with the people who built them. The honest answer to "what will it cost?" at the outset is a range, with the variables that drive it stated clearly.

What the cost should be evaluated against is the alternative. The Standish Group's CHAOS reports have tracked software project outcomes for decades. Their methodology has limitations - they define "failure" as projects that miss time, budget, or scope targets, not as projects that produced the wrong outcome - but the directional finding is consistent: large software projects, particularly transformation programmes, regularly overrun their original estimates by factors of two or three. A programme that is scoped at £2 million on the basis of an inadequate or conflicted assessment commonly reaches £5 or £6 million before the steering committee is told the number has changed.

The assessment fee sits at the front of that chain. It is the cost of knowing what you are deciding before you decide it. For a programme of any material size, the fee is rounding error relative to the downside it is designed to prevent.

The other cost to consider is the internal time the assessment requires. Senior stakeholder interviews take time. Access to system owners takes time. Validation sessions take time. A realistic estimate is fifteen to twenty days of internal staff time across the nine weeks, spread across operations, finance, IT, and the support team. That cost is real and should be in the business case for the assessment.

Konnectedly's model is built on this separation: a fixed-scope assessment with no downstream commercial interest in the outcome, so the register means what it says.

What should a steering committee do with the findings?

The register arrives with a list of dispositions and cost-to-proceed ranges. The natural instinct is to treat the top five systems as a programme and issue a tender. That instinct is usually wrong.

Each system is a separate problem. The system that should be retired has a different owner, a different timeline, and a different risk profile from the system that needs a targeted investment in its integration layer. Bundling them creates a programme with a scope that is too broad to manage and a governance structure that is too heavy for the smaller items.

The right response to a decision register is a series of small, funded next steps, each scoped to a single system or a tightly related group. The next step for a system in the retire column is a decommission plan, which is a different kind of work from a modernization project. The next step for a system in the replace column is a detailed options analysis, which is the kind of technical scoping work that a specialist firm or an internal architect should produce. The next step for a system in the invest column is a backlog of specific improvements, costed individually.

For the systems in the leave-alone column, the next step is to record that decision and review it at the next portfolio cycle. The assessment has bought the steering committee permission to stop worrying about those systems for a defined period. That is not a small thing. The systems that absorb attention because they appear on every risk report, without anyone ever deciding what to do about them, are a significant drain on management capacity. A formal "leave it alone" decision removes them from the agenda.

Frequently Asked Questions

What does an independent legacy system modernization assessment produce?

An independent assessment produces a prioritised decision register: a list of systems scored against business criticality, cost to run, risk exposure, and strategic fit, with a recommended disposition for each one. The dispositions are retire, replace, retain, or leave alone. It does not produce a build plan, a vendor shortlist, or an implementation roadmap.

How long does a legacy system modernization assessment take?

A structured independent assessment of a mid-sized application estate typically runs seven to nine weeks. The first two weeks are inventory and interview work. Weeks three through six are analysis. The final two weeks are validation with stakeholders and production of the decision register. Larger estates with poor documentation take longer.

Why should the firm doing the assessment not also build the replacement?

Because the financial incentive to recommend modernization is structural when the same firm will build it. An adviser who earns nothing from a "leave it alone" recommendation is the only one whose recommendation to modernize is worth taking seriously. This is not a criticism of systems integrators; it is a description of how incentives work.

What does a legacy system modernization assessment cost?

Fees for an independent assessment of a mid-sized estate typically run from £40,000 to £120,000, depending on the number of systems, the quality of existing documentation, and the depth of stakeholder interviews required. That figure is a fraction of the cost of a wrongly directed modernization programme, which commonly runs to seven figures before the error is visible.

What is the difference between a legacy system modernization assessment and an application portfolio management exercise?

Application portfolio management is an ongoing governance discipline, usually supported by tooling, that maintains a live picture of the estate. A modernization assessment is a point-in-time exercise that answers a specific question: which systems warrant investment now, and which do not. The two are complementary, but an assessment can be completed without a full APM programme in place.

What systems does a legacy system modernization assessment recommend leaving alone?

Systems that are stable, cheap to run, well understood by the team, and not on a path to losing vendor support are strong candidates to leave alone. The question is not whether the system is old. The question is whether its current state is costing money, creating risk, or blocking a business capability that matters. If the answer to all three is no, the honest recommendation is to leave it alone.

How do you measure the cost of a legacy system before an assessment?

Licence and infrastructure costs are usually visible. The harder numbers are staff time spent on workarounds, the cost of integration failures, the opportunity cost of features the business cannot build on the current stack, and the carrying cost of known defects nobody has fixed. A structured assessment puts a number on all four categories, which is what makes funding a decision possible.

What should a steering committee do with a legacy system modernization assessment when they receive it?

Use it as the basis for a funded portfolio decision, not as a prompt to issue an RFP. The assessment tells you which systems warrant further action. The next question for each one is what kind of action and who should perform it. Those are separate decisions, made by separate parties, and keeping them separate is what prevents the assessment from becoming a sales document.