Supporting a legacy .NET Framework application without a rewrite
Plenty of businesses run on an ASP.NET Web Forms site, an MVC 5 portal, a WCF service or a WinForms or WPF desktop app, often written in C# or VB.NET years ago. It works, and you don't want a new system. You just need it kept secure and working. Here's what that takes.
Is .NET Framework still supported?
Mostly, yes, but it depends on the version. .NET Framework follows Microsoft's Component Lifecycle Policy: it's supported as part of the version of Windows it's installed on, rather than to a fixed date of its own.
| Version | Support status |
|---|---|
| .NET Framework 4.8 and 4.8.1 | Supported, for as long as the Windows version they run on is supported |
| .NET Framework 4.7, 4.7.1 and 4.7.2 | Supported under the same component policy |
| .NET Framework 4.6.2 | Ends 12 January 2027 |
| .NET Framework 4.5.2, 4.6 and 4.6.1 | Ended 26 April 2022 |
| .NET Framework 4.0, 4.5 and 4.5.1 | Ended January 2016 |
Check current dates on Microsoft's .NET Framework lifecycle page.
Two things follow from this. First, "supported as part of Windows" only helps if Windows itself is supported: .NET Framework 4.8 on an out-of-support server gets no more patches than the server does. Second, .NET Framework is finished. Microsoft still ships security fixes, but no new features, and new libraries increasingly target modern .NET only.
Where the real risks are
The framework is rarely what breaks. The risks build up around it:
- The server underneath. Framework applications need Windows, usually IIS and often SQL Server. SQL Server 2016 lost support in July 2026, and Windows Server 2016 follows on 12 January 2027. Once the operating system is out of support, so in practice is everything on it.
- Old NuGet packages. Libraries pinned years ago, such as JSON parsers, PDF generators or email components, may have known vulnerabilities, and the newer versions may no longer support .NET Framework.
- TLS and payment-provider changes. Payment gateways, banks and APIs regularly retire old encryption protocols and certificates. An application built against an older Framework version can depend on settings that stop it connecting, and the first you hear of it is failed payments.
- Nobody who knows it. Web Forms, WCF and VB.NET skills are getting harder to find. If the person who built it has gone, read what to do when your developer has left.
- Nobody can rebuild it. The live server holds the only working copy, with changes that never made it back into source control.
A rewrite is rarely the right first answer
A system that has run your business for years holds a great deal of knowledge: pricing rules, exceptions, reports people rely on. A rewrite has to rediscover all of it, costs far more than keeping the existing system healthy, and puts the business at risk while it happens. My view is simple: keep it running safely now, and modernise in stages when there's a real reason to.
What good ongoing support looks like
Supporting a legacy application well is mostly unglamorous, steady work. In roughly this order:
- Source control. Every line of code in a repository your business owns, matched against what's actually running live.
- A repeatable build and deployment. The application can be built and deployed from source by anyone with access, not just from one developer's machine.
- Backups that have been restored. Database and file backups, kept off the server, with a test restore done on a schedule.
- Monitoring. Uptime checks, error logging and alerts for certificate expiry, so problems are spotted before customers report them.
- Patching. Windows, IIS, SQL Server and .NET Framework updates applied on a schedule, plus a review of NuGet packages for known vulnerabilities.
- Moving to .NET Framework 4.8.1. If the application targets an older 4.x version, retargeting to 4.8 or 4.8.1 is usually a modest job and keeps it on a supported version with current security defaults.
- Moving off unsupported Windows and SQL Server. Migrating to a supported Windows Server and SQL Server, ideally as a new environment alongside the old one, so you have a fallback.
When it's time to migrate instead
Staying on .NET Framework is a reasonable choice for many systems. Moving to modern .NET makes sense when:
- you're adding significant new features, and want to build them on current technology
- a library, integration or AI service you need only supports modern .NET
- Windows hosting costs are high and Linux, containers or managed cloud hosting would cut them
- you're finding it hard to get developers to work on it
- the server needs replacing anyway, so the move is a good moment to modernise
Even then, it doesn't need to be a rewrite. Most applications can move to .NET 10 in stages while the old system stays live. See migrating .NET Framework to .NET 10 for how that works, and my .NET modernisation service, which starts with an upgrade audit from £1,500.
Need a hand?
I've built ASP.NET applications since the first release, and I've supported bespoke business systems for 30 years. One job, stock and invoicing system I built has been in daily use for more than 11 years. A care plan covers hosting, backups, monitoring, security patches and a set number of hours each month for fixes, from £195 a month, or from £450 a month with scheduled upgrades. Every plan starts with a short paid onboarding review of your system, so the plan fits what you actually run.