The Business Case for Legacy Modernization: How to Win Board Budget and Quantify the ROI

Most modernisation budget requests fail not because they are wrong on the substance but because they are written in the wrong language. The CTO arrives at the board with a list of architectural problems, a test coverage figure, and a dependency map, and across the table sit people who that same day are considering a proposal to enter a new market and another to expand the sales team. Those two have a calculated return. Modernisation does not, so it loses, even when it is the most profitable of the three investments.

The problem is not that boards fail to understand technology. It is that you cannot compare two investments when only one of them is expressed in numbers. What follows is a practical account of how to build the business case for modernisation: how to quantify current cost, opportunity cost, and the cost of deferral, how to present options, which metrics actually land with a board, and which mistakes most often cost the approval.

Why a Technical Case Loses to a Commercial One

A board evaluates investments against one shared test: what the company gets and when. A proposal to expand the sales team says plainly how many additional deals it should generate and over what period. A modernisation proposal usually says the architecture is tightly coupled, technical debt is growing, and the system represents a risk. All of that may be true, and none of it constitutes a basis for a decision, because it contains neither an amount nor a horizon.

The second cause of failure is framing. Modernisation presented as cleaning up after years of compromises sounds like the cost of fixing your own mistakes. The same modernisation presented as removing a barrier that blocks the growth plan sounds like an investment. The difference is not cosmetic: the first version competes against other costs, the second against other investments, and those are entirely different categories in a budget conversation.

The third cause is the absence of alternatives. A proposal that presents one solution and one number puts the board in a binary position. A proposal that lays out three scenarios with the consequences of each, including doing nothing, gives the board what it wants: the ability to make a decision rather than rubber-stamp one.

Pillar One: Current Cost

Current cost is the easiest part of the case to calculate and usually the most understated. It breaks into several items worth separating, because each speaks to a different member of the board.

The foundation is delivery cost. If a feature that once took two weeks now takes six, that can be expressed directly as engineering cost per unit of delivered value. In one system Altimi modernised, a quality management platform built on a 2016-era stack, the cost of delivering a feature had risen fivefold from its starting point. With a team of a dozen or more engineers, that difference converts into a number any CFO recognises without translation.

The second item is maintenance and infrastructure cost, best expressed as a share of revenue and tracked over time. A rising share against stable product margin is concrete evidence that the model is not scaling as planned.

The third is the cost of incidents and downtime, counted not only as engineering hours but as customer impact and exposure under service level commitments. The fourth, often omitted, is the cost of hiring and onboarding: if a new engineer needs a quarter before working independently, every headcount delivers value far later than the hiring plan assumes.

Pillar Two: Opportunity Cost

This is the hardest part to quantify and usually the largest. Current cost appears in reports; opportunity cost appears nowhere, because it concerns things that did not happen.

Three items are worth quantifying. The first is deals lost. If sales loses processes at the security questionnaire stage, or because of missing certifications enterprise buyers expect, the value of those deals is a direct cost of the technical position. Simply listing lost opportunities against the reason for rejection produces a number nobody will dispute.

The second is delayed time to market. If the plan called for launching a new product line in a given quarter and the state of the system pushed that by two, the cost is the revenue not earned in that window plus the ground conceded to competitors.

The third is features that were never proposed. This item has to be looked for deliberately, because by definition it is not in the backlog. In practice it is enough to ask product leaders what they stopped suggesting once they knew the system could not carry it. The answers are often surprising, and they frequently do the best job of showing a board that the problem is strategic rather than technical.

Pillar Three: The Cost of Deferral

This is the question asked least often and usually the most persuasive for a board weighing action now against a decision in a year's time.

Deferred modernisation does not cost the same a year later, for several reasons. More code gets built on the old assumptions in the meantime, so the scope grows. The window before component end of life narrows, which with a large customer base can determine whether migration is feasible on a sensible schedule at all. In the quality management platform mentioned above, one of the forcing factors was the sunset of the supported database version scheduled for 2027, which given the need to migrate the entire customer base required work to start well in advance.

Risk grows too. Every additional quarter on unsupported components raises the probability of a security incident and makes conversations with enterprise customers progressively harder. Presenting this as a curve rather than a one-off cost changes the nature of the discussion: the board stops choosing between spending money now and not spending it at all, and starts choosing between spending less now and more later.

How to Present the Options

A good proposal contains at least three options, each with a cost, a timeline, and consequences.

The do-nothing option is the reference point. It shows what current cost, risk, and delivery speed look like in two years if nothing changes. Without it, the board has nothing to compare the others against.

The incremental modernisation option is usually the recommendation: start with the modules carrying the highest risk and the greatest impact on the plan, deliver in phases, and keep the team shipping throughout. The critical point to make is that the first benefits arrive within months rather than at the end of the whole programme.

The full rewrite option is worth including even when it is not recommended, precisely to show its cost and risk. A rewrite assumes the team understands the existing system well enough to reproduce it, that requirements will hold still for many quarters, and that nothing important sits in the code being discarded. Setting those assumptions beside the incremental option usually settles the discussion by itself.

For each option it is worth stating not only the cost but the point at which the first benefits appear, and what happens to product delivery while the work runs. For a board, the second piece of information is often more decisive than the first.

Metrics That Land With a Board

Not every engineering metric belongs in a board pack. The ones that work connect the technical position to a financial outcome or to the plan.

The first group covers speed: time from feature decision to production, and releases per month. This is the simplest way to show whether investment in foundations translates into delivery capability.

The second is unit cost: engineering cost per delivered feature, and infrastructure cost per customer. The third is risk expressed in business terms: open critical vulnerabilities, components without vendor support, and the state of requirements that gate sales into the enterprise segment.

The fourth, and most important, is impact on the plan: how many planned product initiatives are blocked by the state of the system, and how that number moves over time. This is the metric that best explains to a board why modernisation competes for budget with growth initiatives rather than with administrative costs.

It is worth agreeing up front how these indicators will be reported once the programme starts. A proposal that commits to a specific way of measuring outcomes is considerably easier to approve than one that ends in a promise of improvement.

Four Mistakes That Cost the Approval

The first is one large number with no phases. A request for a big budget covering a multi-year programme invites natural caution. The same programme split into phases, the first of which is small and ends in a concrete result, passes far more easily.

The second is promising benefits that cannot be measured. Phrases like better code quality or greater architectural flexibility cannot be settled against, so they undermine the credibility of the whole case. Better to promise less in terms that can be verified.

The third is omitting the do-nothing option. Without a reference point, the board compares the cost of modernisation against zero, which always looks unfavourable. With a do-nothing option, it compares two numbers, one of which grows over time.

The fourth is basing the case on unsupported estimates. If the cost and timeline come from the team's instinct, the first question about the basis for those numbers ends the discussion. This is why a business case should come out of a structured assessment run against real code rather than a whiteboard workshop.

Where the Numbers Come From

This is the most common obstacle: the team knows the system is a problem but has no data to prove it in financial terms. A technical assessment designed around an investment decision solves this, because it delivers the diagnosis and its costing together.

Altimi's AI Refactoring Assessment runs for four weeks and is built so that its output can be put in front of a board. It consists of two linked workstreams. The first is an architecture and technical debt assessment: identifying which parts of the system are blocking growth and scalability, with quantified technical debt, an AI readiness assessment, and an infrastructure risk review. The second is a technical spike, a hands-on validation of the riskiest part of the codebase against real production code, producing hard data on migration risk and the actual impact of AI tooling before any budget is committed.

The output is a decision pack prepared for board and investor level: an executive summary, a risk map, an AI-driven modernisation roadmap, a prioritised technical debt backlog, spike findings, and a business case with financial metrics. It is delivered in a readout workshop, which matters in practice: leadership gets to question the people who ran the analysis rather than read a document without context.

The AI impact element is particularly significant for the return calculation. The analysis identifies which modernisation tasks AI tooling can accelerate by 50 to 80 percent and which still require senior engineering judgment. That distinction changes the costing of the programme, and therefore the outcome of the whole business case, which is why basing it on general assumptions instead of validation against your own code produces numbers that cannot be defended.

The demand on the team is light, with work running read-only and two or three sessions a week with architects or tech leads, and no roadmap freeze. Altimi's track record covers more than 150 legacy systems assessed across SaaS, FinTech, EdTech, and cybersecurity, from founder-built monoliths to scaling mid-market platforms under delivery pressure.

The European Context

For companies operating in Central and Eastern Europe, the DACH region, and the wider European market, the regulatory dimension is often the strongest argument in the case, because it converts most readily into revenue. GDPR compliance, requirements from frameworks such as ISO 27001, and enterprise customers' expectations around security and auditability effectively determine access to the most valuable market segments. If the architecture makes meeting them impossible, the cost of that position can be stated directly as the share of the market the company cannot reach.

Where source code is processed during an AI-assisted assessment also matters. Working with an EU-based, ISO 27001-certified partner keeps sensitive code inside the European data protection perimeter and documents how AI is used, which can matter in audits and in enterprise customer conversations.

How to Win Board Budget and Quantify the ROI? Conclusion

Modernisation loses the budget fight not because it is unprofitable but because it is rarely presented as an investment with a calculated return. A case that stands a chance rests on three pillars: current cost, which is visible in the numbers; opportunity cost, which has to be sought out deliberately; and the cost of deferral, which shows that the figure grows with every quarter of delay.

Three further elements are needed: options rather than a single proposal, metrics that connect the technical position to financial outcomes, and numbers derived from an assessment run against real code rather than from estimates. A case built this way stops competing with administrative costs and starts competing with growth initiatives, which is the correct category for it.

If you are preparing such a case and need numbers that will hold up in front of a board, the fastest way to start is a short conversation about the system and what is currently blocking the plan.