When your software goes out of support.

Many organisations run software built on a framework that was current when the system was written and has since reached the end of its life. That is normal, and it is rarely urgent on the day. It is worth a plan.

What out of support means

When a version goes out of support, the supplier stops issuing security fixes for it. Your software still runs, and nothing on screen changes. What changes is that any security flaw found afterwards in that version stays open. Over months and years the gap between what is known and what is fixed widens, most of all for systems reachable from the internet.

It also matters beyond the technical risk. Auditors, insurers and customers increasingly ask whether the software you depend on is still supported. "Yes, and here is our plan" is a much better answer than "we aren't sure". Our article on what out of support means goes into the detail.

Where to check the dates that matter

Last checked: 12 November 2026. For current .NET, these are the dates on Microsoft's .NET support policy:

For .NET Framework and the Windows Server and SQL Server versions bespoke systems most often run on, these are the dates on Microsoft's lifecycle pages:

Dates can change, so before you plan around one, check the publisher's own page:

For what the recent .NET dates mean in practice, see our articles on .NET 8 and .NET 9 going out of support and still being on .NET Framework. If you are running Windows Server, the operating system has its own end date, as we explained for Windows Server 2012.

Upgrade or move?

Most of the systems we are asked about fall into one of two cases.

A .NET Framework application. The usual route is to upgrade it to current .NET. Current .NET is the version Microsoft is actively developing, and it runs on modern, supported platforms. The work is not always small, because some libraries and Windows-specific features need replacing, so an honest assessment comes first.

An application on an older version of .NET. Moving to a newer .NET version is usually a smaller job. Our article on upgrading .NET 8 to .NET 10 walks through what it involves.

When moving to Azure makes sense. If the application runs on an ageing server, or the operating system or database underneath it is also going out of support, it often makes sense to upgrade the software and move it to Azure in one planned programme. If the server is healthy and only the framework is old, the upgrade alone may be enough. We will tell you which applies, and what each route involves.

How we upgrade safely

The risk in an upgrade is breaking something your organisation relies on without noticing. So we start by protecting what the system does today.

1. Tests first. We write behaviour specifications and automated tests for what the system does now, so that a change that breaks something is caught before it reaches you.
2. Upgrade in steps. We move the system forward in small stages, running the tests at each one.
3. Independent review. A separate agent reviews every change, and a named engineer approves anything that reaches a live system.
4. Release as a routine. The result goes out through a repeatable, documented release process, with monitoring in place.

This is part of our software care service, where we plan upgrades before versions go out of support. Your code and documentation stay in your own repository throughout.

Next step

Find out which versions your system uses, and check them against the pages above. If you would like a clear, independent answer, a software health audit records the support status of every part of one system, ranks the risks and gives you a fixed quote for what it would take to look after it. You can book an audit or talk to an engineer.