DEV Community: Graham

Making the business case before end of support

Graham — Wed, 21 Oct 2026 06:14:27 +0000

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.

Originally published on CodeFirst, a UK company that maintains and modernises business software.

The 4 best support ticket systems, and how to choose one

Graham — Wed, 14 Oct 2026 06:11:27 +0000

A support ticket system records every fault report and request about a piece of software, who is dealing with it and how long it has taken. The best software support ticket system for a given company depends mainly on two things: who raises the tickets, and where the developers who fix the problems do their work. On that basis our shortlist for a company of 10 to 500 people is Jira Service Management, Zendesk, Freshservice and Zammad. Each suits a different situation, and they are not listed in order of merit.

What makes supporting software different

A general help desk mostly answers questions. Supporting software also means passing some tickets to developers, because the answer is a change to the code. That adds requirements a shared mailbox cannot meet:

A link to the developers' work. The ticket stays with the person who reported it, and a linked item in the developers' own tracker (Jira, Azure DevOps or GitHub Issues) carries the fix. Each side can see the other's progress.
Severity and response targets. A fault that stops the business is treated differently from a spelling mistake, and the system times each ticket against the target agreed for its severity.
A history. Every ticket is kept, so recurring faults can be spotted and a dispute about what was reported, and when, can be settled by looking it up.
A way in for users. Email at least, and usually a web form or portal where the reporter can see the status without asking.

How we chose these four

We did not test every product on the market, and we have not ranked these. We looked for products that:

take requests by email and through a web portal;
can time tickets against response targets;
can link a ticket to an item in a developer tracker;
publish how they charge, and can be tried before buying;
were being sold and actively developed when we checked in October 2026;
make sense for an organisation of 10 to 500 people.

The earlier version of this article included ServiceNow. It is still a major product, but it is built for large organisations with a dedicated service management team, so we have left it out on the sixth test.

The four systems compared

Product	Suits	Hosting	How it is charged
Jira Service Management	Teams whose developers already work in Jira	Vendor's cloud	Free plan for up to three agents, then per agent
Zendesk	Support for customers outside the company	Vendor's cloud	Per agent, free trial
Freshservice	An internal IT desk that also supports business systems	Vendor's cloud	Per agent, free trial
Zammad	Organisations that want open source or their own server	Self-hosted or vendor's cloud	Free to self-host, hosted per agent

An agent is a person who works on tickets. These products charge for agents, and the people who raise tickets do not normally need a paid seat.

Jira Service Management

Jira Service Management is Atlassian's service desk, now sold as part of what Atlassian calls its Service Collection. Its advantage is that it sits on the same platform as Jira, the tracker many development teams use, so a support ticket and the developers' work on it are linked without any extra integration.

One change matters if you host your own software. Atlassian stopped selling the self-hosted Data Center edition to new customers on 30 March 2026, and that edition reaches the end of its life on 28 March 2029. For a new buyer, Jira Service Management is a cloud product.

It is the natural choice where Jira is already in use. Where it is not, it means adopting Atlassian's way of working for the sake of a service desk.

Zendesk

Zendesk is a customer service product first. It handles email, web chat, messaging and telephone in one place, with a help centre where customers can find answers for themselves. That makes it a good fit for a company supporting its own software product for outside customers.

Zendesk publishes a free integration that links its tickets to Jira issues. Check which plan you need before comparing costs: response and resolution targets, for example, are not included in the entry-level plans.

Freshservice

Freshservice is the IT service management product from Freshworks. Besides tickets it covers the wider duties of an internal IT team, such as recording changes and keeping a register of equipment and software. Connectors are available for both Jira and Azure DevOps, which is relevant if your developers work on the Microsoft stack.

It suits an organisation whose IT team supports staff and business systems from one desk. Freshworks sells a different product, Freshdesk, for customer-facing support, and the two are easy to confuse.

Zammad

Zammad is an open source ticket system, released under the AGPL licence. You can install it on your own server without a licence fee, or pay the company behind it to host it. It takes tickets by email, telephone and chat, supports response targets, and can link tickets to issues in GitHub and GitLab.

It is worth a look where tickets will contain data you need to keep on your own servers, or where per-agent charges would mount up. The trade-off is that a self-hosted system is one more piece of software for you to update, back up and secure.

If a supplier supports your software

Many companies never choose a ticket system at all, because the supplier that maintains their bespoke system provides one. In that case the questions are different:

Can you see all your tickets and their current status, not just the ones you raised yourself?
Is the severity of each ticket recorded, and can you see whether the agreed response target was met?
Can you export the full history? It is your record of how the system has behaved, and a new supplier will want it.
Is there a telephone number for urgent faults, so that a serious problem does not wait in a queue?

The response targets themselves belong in the contract. We cover those in why a service level agreement is a good idea and in what a software support contract should include.

Checks to make before you commit

Run a trial with real tickets. Take the last twenty problems your users reported and put them through the system as if they had just arrived. This shows more than any feature list.

Test the link to the developers' tracker. Raise a ticket, pass it to a developer and follow it back. If the link is clumsy, people will stop using it and go back to forwarding emails.

Count the seats. Per-agent pricing depends on who counts as an agent. Find out whether a developer who only comments on a ticket now and then needs a paid seat.

Find out where the data is held. Tickets contain names, email addresses and often screenshots showing customer records. Check where the vendor stores them and what its contract says about personal data, and take advice if you are unsure of your obligations.

Check you can leave. Confirm that the full ticket history can be exported in a form another system could import.

A shared mailbox is a reasonable start for a small team. The time to move on is when two people answer the same email, or a report goes unanswered because each assumed the other had it.

Originally published on CodeFirst, a UK company that maintains and modernises business software.