Analysis alone doesn't get funded. To act on a rationalisation you need a business case that puts a number on every recommendation — and that's what turns an architecture exercise into a board decision.
A rationalisation analysis typically concludes that thirty applications should be retired. It is well evidenced, the architects agree, and it does not get funded — because a finance director cannot approve "thirty applications should be retired". They can approve a number, a timeframe and an owner.
The business case is the translation layer. It converts an architecture conclusion into an investment decision, and its absence is the most common reason good rationalisation work dies quietly.
Start by establishing what each application genuinely costs, because the headline licence figure is usually less than half of it.
| Cost element | Commonly missed because |
|---|---|
| Licence and subscription | Rarely missed — but check for shelfware and unused seats |
| Vendor support and maintenance | Often on a separate contract and a separate cost centre |
| Hosting and infrastructure | Buried in a shared platform allocation |
| Internal run effort | Nobody logs the 0.3 FTE that keeps it alive, but it is real money |
| Integration maintenance | Attributed to the integration platform, not the application causing it |
| Compliance and audit | Each additional in-scope system carries a recurring audit cost |
Internal effort is the line most often omitted and the one that most often changes the answer. An application with a modest licence but half a support analyst's time is frequently more expensive than a costlier system that simply runs.
Credibility depends on separating savings by how real they are. Finance teams have seen too many cases where all three types below were added together and presented as cash.
Present all three separately with the hard savings first. A case claiming £2m that turns out to contain £400k of cash and £1.6m of soft benefit damages your credibility for every subsequent case. One claiming £400k hard and £1.6m avoided gets approved and remembered as accurate.
Decommissioning is a project and needs a project's budget. Data migration or archival to meet retention obligations. Interface rework for every consuming system. User migration and training. Parallel running during transition. Contract exit terms and any early termination penalties. The final decommission and evidence of destruction.
A rough rule from practice: retiring an application costs somewhere between six months and two years of its run cost, depending heavily on integration count and data retention obligations. A case that shows zero removal cost will be disbelieved, and it should be.
Some of the strongest cases are not about money at all. An unsupported system holding regulated data is a risk case, and risk cases often clear governance faster than savings cases because the downside is concrete.
Quantify where you can — potential regulatory exposure, cost of a plausible outage, remediation cost if a vulnerability is exploited. Where you cannot, describe the exposure plainly and let the risk committee price it. Frame it as risk removed, not just cost saved.
Sequence the moves so early wins fund later ones. Start with applications that are low-integration, low-user and high-cost — the ones you can genuinely switch off within a quarter. Visible early delivery buys patience for the harder migrations that follow.
Every recommendation needs a named owner, a target date, a cost, a saving and a dependency list. And state the counterfactual explicitly: what the estate costs in three years if nothing is done. Boards approve change far more readily when the do-nothing option is also on the page with a number against it.
The Applications Assessment & Rationalisation Toolkit quantifies cost by quadrant and consolidation savings, and includes an executive report and deck built for the boardroom.
