Most legacy modernization proposals are rejected for the same reason. They present a cost with no counterfactual. The board is asked to approve a large number to replace something that, as far as anyone can see from the outside, currently works. Without a credible figure for what standing still costs, the proposal is a request for spending rather than a comparison of options, and it loses to whatever has a revenue number attached.
A business case that survives that conversation needs three things: the current run cost stated honestly, the cost of delay quantified, and the risk expressed in money rather than adjectives. This is how to assemble them.
Key Takeaways
- Modernization business cases fail when they price the project but not the alternative. Always present the cost of doing nothing over the same period.
- Total run cost is larger than the licence and hosting line. Include the support burden, the change tax on every new feature, and the people risk.
- Quantify risk with expected value, not adjectives. A five percent chance of a two-week outage has a number attached.
- Phase the case so each stage funds itself. Progressive modernization lets you show a return before the full spend is committed.
- Get finance to own the baseline numbers. A business case that IT built alone is treated as advocacy.
Start by pricing the system you already run
Ask what the legacy system costs and you will usually be given the licence renewal and the infrastructure bill. That figure is typically less than half the real number, and using it makes the modernization case look worse than it is.
The full picture includes support and maintenance effort measured in actual engineer time rather than allocated headcount, the integration workarounds built to compensate for what the system cannot do, the manual processes that exist because a capability is missing, and the vendor or contractor premium paid for scarce skills on obsolete technology. Add the audit and compliance effort, which for older systems is frequently a manual evidence exercise repeated every cycle.
Then add the change tax. Estimate what a typical feature costs to deliver on the legacy platform, and what the same feature would cost on a modern one. Multiply the difference by your annual change volume. This is often the single largest line in the whole analysis, and it is the one most often left out because it is not a line item in any budget.
Quantify the cost of delay
Cost of delay: the value lost for each period a change is postponed, expressed as an annual figure so it can be compared directly against project cost.
Cost of delay is what turns a modernization case from a spending request into a timing decision. If modernizing costs a given amount and delaying it costs a meaningful fraction of that every year, the question stops being whether to spend and becomes when to start.
Build it from things the business already measures. Revenue that cannot be captured because a product cannot be launched on the current platform. Customers lost at onboarding because the journey requires steps a modern competitor has removed. Time to market on regulatory changes, where the UAE e-invoicing mandate and the Central Bank’s Open Finance Regulation both create dated obligations that a rigid platform makes more expensive to meet.
Where you cannot measure directly, state the assumption explicitly and let finance challenge it. A visible assumption that survives scrutiny is worth far more than a confident number nobody can trace.
Express risk in money
Technical audiences describe legacy risk qualitatively: unsupported versions, single points of failure, one person who understands the batch schedule. Boards discount that language because everything sounds urgent when described by the people who want it funded.
Convert it. For each significant risk, estimate the annual probability and the cost if it happens, and multiply. An unsupported database with a plausible annual probability of a serious incident, and a credible cost for two days of degraded service including recovery and remediation, produces a number. It will be an estimate, and that is acceptable, because the alternative is an adjective.
Key person risk deserves its own line. If a system depends on individuals who could leave, the mitigation cost, whether that is documentation, cross-training or retention, is a real annual expense that the modernized platform removes. Similarly, security exposure on unsupported components has an insurance and remediation cost that a security team can usually price.
Phase the case so it funds itself
A single large number invites a single large rejection. A phased case invites a smaller decision, and gives the organisation evidence before the full commitment.
Structure it so each phase has its own cost, its own measurable outcome and its own decision point. A first phase might carve out one high-friction capability and demonstrate a measured reduction in handling time or incident volume. The second phase is then justified partly by the first phase’s actual results rather than by the original forecast.
This maps naturally onto the strangler fig approach, where value lands throughout rather than at the end. It also gives finance something they rarely get on transformation programmes, which is a genuine option to stop.
Anticipate the four questions you will be asked
Why now, rather than next year. Answer with cost of delay and any dated external obligation, not with technical debt language.
What happens if we do nothing. Answer with the run cost trajectory, which rises rather than staying flat as skills get scarcer and workarounds accumulate.
How do we know it will not overrun. Answer with the phasing and the decision points, and be honest that a single-phase estimate eighteen months out is not credible from anyone.
Can we just do the minimum to stay compliant. Sometimes yes, and saying so when it is true buys you credibility for the cases where it is not. Compliance-only patching is a legitimate answer for a system with a known end date, and a poor one for a system the business expects to build on.
Frequently asked questions
How do we estimate modernization cost before doing discovery?
You do not, precisely, and claiming otherwise damages the case later. Give a range with the assumptions stated, and propose a short paid discovery phase that produces a firm number for phase one and a better range for the rest. A costed discovery is far easier to approve than a costed programme.
What if the legacy system genuinely works fine?
Then say so and do not propose replacing it. The strongest modernization cases are the ones that leave working systems alone. Focus the argument on the specific capabilities that are blocking the business, which is also usually the cheapest scope.
Should we include productivity gains in the case?
Include them, but separately from hard savings, and be conservative. Boards discount productivity claims heavily and with good reason. A case that lands on hard cost, risk and cost of delay, with productivity as upside rather than as the foundation, holds up better under scrutiny.
Who should present it?
Finance should own the baseline numbers and technology should own the delivery plan. A case presented solely by the team that wants to do the work is read as advocacy. One where finance has already validated the run cost and the assumptions is read as analysis.
How long should the payback period be?
For most mid-market modernization work, a three-year horizon is what gets scrutinised. If the case only works over five to seven years, it needs a non-financial driver such as a regulatory deadline or a stated product strategy to carry it, and you should lead with that driver rather than bury it.
Need the numbers before the board meeting?
Kentro runs short assessments that produce a costed modernization plan with the run-cost baseline, phasing and risk quantified, scoped against your actual estate rather than a template.
