The business case for fixing an application before its platform goes out of support is a short paper that sets the cost of each option against the risk of doing nothing, and asks the board to choose one by a date. This guide is for the IT manager at a medium or large organisation who has to write that paper, and for the finance or operations director who will read it.
It applies to any business application that depends on something with a support end date: Windows Server 2016 (support ends on 12 January 2027), SQL Server 2016 (support ended on 14 July 2026) or an old version of .NET Framework such as 4.6.2 (support ends on 12 January 2027). Our page on what happens when software reaches end of support explains the technical side. This guide is about getting a decision.
What the board actually has to decide
A board is not deciding whether the software is old. It is deciding three things:
- Which risk it is willing to carry, and for how long.
- Which option to fund, from a short list with costs.
- When the work must start, so that it finishes before the risk becomes unacceptable.
Papers fail when they ask for something vague, such as “approval to modernise”, or offer one option at one price. Give a real choice, including doing nothing, and say which you recommend.
The risks, in business terms
Directors need to know what could happen to the organisation, not how the platform works.
Security fixes stop. After the end date the vendor no longer fixes newly found weaknesses. Each one stays open and its details are published. For an application that holds personal data or can be reached from the internet, that is the risk that matters most. UK data protection law expects appropriate security measures, and unsupported software is hard to defend after a breach.
Cyber insurance. Proposal and renewal forms commonly ask whether any software in use is out of support. A yes may affect cover or premium, and a wrong answer may affect a claim. Ask your broker what your policy says, and quote the answer in the paper.
Cyber Essentials. The scheme requires software in scope to be licensed and supported by its vendor. Unsupported software has to be removed or isolated from the internet so that it falls outside the assessed scope. If the organisation holds the certificate, or a customer contract requires it, an unsupported platform puts that at risk at the next assessment. Your certification body decides what is in scope.
Customers and auditors. Customer security questionnaires and auditors ask the same question. A finding with a dated plan is far easier to answer.
Nothing switches off on the end date. Say so: it explains why the risk is easy to put off, and why the board should decide by a date, not after an incident.
The options to put in front of the board
Show each option with its cost, what it fixes, what it leaves unfixed and when it runs out.
1. Do nothing. No spending now. The application keeps running, but the risks above grow every month and the eventual work is done in a hurry. Its cost is the risk, plus a higher cost later. Include it so the board sees it costed and declines it deliberately.
2. Pay for extended security updates. For some products, including Windows Server 2016 and SQL Server 2016, Microsoft sells Extended Security Updates for a limited period after support ends, bought directly or through Azure. They are paid, time-limited and cover security fixes only. Nothing else improves, and the money buys time without leaving anything behind. Treat this as a bridge to one of the options below, never as the plan.
3. Upgrade in place. Move the server, database or framework to a supported version and keep the application as it is, apart from the changes it needs to run. For operating systems and databases this is often less work than people fear. Our guides to upgrading SQL Server 2016 and Windows Server 2016 upgrade options show what it involves. It fixes the support problem and little else.
4. Staged modernisation. Upgrade the platform and, in the same programme, replace the parts of the application that are hardest to support, one release at a time. This suits an application the organisation will rely on for years and keeps changing. It costs more than option 3, but each stage delivers something and can be stopped. Our page on legacy software modernisation describes the approach, and rewrite or modernise covers the choice between them.
5. Replace it. Buy a packaged product or build a new system. This is the right answer when the application no longer fits how the organisation works, or its platform has no upgrade route. It is the largest and slowest option, and the old system usually needs extended updates or isolation while the replacement is built.
How to estimate each option honestly
Boards distrust precise-looking estimates built on guesswork. Start with an assessment and present ranges.
An assessment answers the questions every option depends on:
- what the application is built from, with the version and support date of each part;
- what connects to it: other systems, reports, spreadsheets and scheduled jobs;
- which parts have no supported successor;
- whether the source code is complete and builds;
- who can test it, and how.
Without these answers, the upgrade estimate is a guess and the replacement estimate is a bigger one. With them, you can price options 3 to 5 properly and say where the uncertainty lies. For .NET applications our fixed-price .NET upgrade assessment produces this, and a code audit does the same for other systems.
When you cost each option, include:
- The work itself, internal and external.
- Licences and hosting, including any change of edition.
- Testing time from the people who use the system. It is often left out and is often the bottleneck.
- Running costs for the years after. An extended-updates bill recurs each year it is bought, and a replacement often brings new subscriptions.
- The next deadline. A supported version has its own end date. Name it, so nobody thinks the problem is solved for ever.
Get the prices for extended updates from Microsoft or your licensing reseller, in writing, for each year you might need them.
A one-page structure for the paper
Keep the paper to one page, with the detail in an appendix.
- Decision needed. One sentence: “Approve option 3 at a cost of £X to £Y, starting by [date].”
- Background. The application, what it does for the business, who uses it and its end-of-support date.
- Risk of doing nothing. Three or four lines in business terms: security, insurance, Cyber Essentials, customers.
- Options. A table with one row per option: cost range, what it fixes, what it leaves, when it runs out.
- Recommendation. Which option and why, in a short paragraph.
- Timing. When work must start to finish before the date, and the date by which the board must decide.
- What happens next. The first step, usually the assessment, with its cost and duration.
Name the assumptions behind each range. An estimate that survives a director’s challenge is more likely to be approved.
Timing: start before the date, not at it
Work backwards from the end-of-support date. Allow time for the assessment, the board decision, procurement, the work, testing by users and a release that avoids month-end and other busy periods. For a single server or database that may be a few months. For staged modernisation or replacement it is usually longer.
If the date has already passed, as it has for SQL Server 2016, the paper is the same. The risk section is simply stronger, and extended updates may be needed to cover the gap while the work is done.
The best time to put the paper to the board is when the date is far enough away that every option is still open. Our end-of-life pages list the dates for Windows Server, SQL Server, .NET and Access, and our page on unsupported software sets out what to check first.