.NET Framework support and migration to modern .NET
We maintain applications built on .NET Framework and migrate them to current .NET in stages, starting with the parts that change most, so the system stays in service throughout.
Vendor support
- .NET Framework 4.7 to 4.8.1
- Supported
- Security fixes
- No end date announced
What you probably want to know first
- Can you support our existing application?
- Yes, provided you hold the source code or can obtain it. An application still on 4.5 or 4.6 is retargeted to 4.8 first, usually a small job. Support gets harder where third-party components have no maintained version, or where the system relies on Web Forms or WCF, which have no equivalent on modern .NET.
- What happens in the first assessment?
- The first step is usually our fixed-price .NET upgrade assessment, which takes one to two weeks. It starts with a short call, then read access to the code. We build the solution, run automated compatibility analysis and read by hand the areas tools cannot judge. You get a written report with a staged plan, and a walk-through call.
- What access do you need?
- Read access to the source code and, where possible, read-only access to the hosting environment and the database. Nothing changes on the live system: we work from a copy of the code, and where we look at production it is with read-only access. A confidentiality agreement can be signed before anything is shared.
- What sets the cost and the timescale?
- For the assessment: the size of the solution, the number of separate applications, how many third-party components need individual investigation, and whether technologies are mixed, such as Web Forms, WCF and desktop clients together. The migration itself is quoted one stage at a time once you have the plan, and you can stop after any stage.
- What have you done with systems like ours?
- We have worked mostly on the Microsoft stack since 2012, and most of the systems we maintain were built by someone else. The Logtek case study describes taking over a custom asset management application, moving it to the cloud and maintaining and extending it since. The rest of our case studies are on the site.
Two things called .NET
Microsoft has two platforms with almost the same name, and the difference matters. .NET Framework is the original, released in 2002. It runs only on Windows and is built into the operating system. .NET, formerly .NET Core, is its replacement: faster, able to run on Linux and in containers, and where all new development now happens. Version numbers add to the confusion, since .NET Framework stopped at 4.8 and modern .NET carried on from 5.
A great deal of business software written between 2005 and 2020 is on .NET Framework. It still works, and on the latest version it is still supported. But it is a platform in maintenance, and the world around it is moving on.
What tends to go wrong
- Older Framework versions are out of support. An application still targeting 4.5 or 4.6 no longer receives security fixes for its runtime.
- Libraries move on. Third-party components and Microsoft’s own newer libraries increasingly support modern .NET only, so staying on Framework means staying on old versions of everything else.
- Framework-only technology has no future. Web Forms, WCF server, Windows Workflow and .NET Remoting were not carried forward. Code built on them has to be replaced to move.
- Windows-only hosting costs more. Framework applications need Windows servers and their licences.
- The skills are thinning out. Developers increasingly learn and prefer modern .NET.
Your options
Stay on 4.8 and maintain it. Reasonable for a stable application that changes little. It should be on 4.8, on a supported Windows Server version, with a team that can change it safely.
Migrate in stages. The usual choice for a system with years of life ahead and a steady flow of changes. New work is done on modern .NET from the start, and existing areas move across in order of value.
Replace it. Sensible only when the application no longer fits the business. Migration preserves years of tested business rules; a replacement has to rediscover them.
How we approach it
We keep the old application running and build its successor next to it. Shared business logic is converted first so that both can use it. Then a modern .NET application takes over one area at a time, with a router in front deciding which application handles each request. Users see one system throughout.
This approach means there is no single risky switch-over, each stage delivers something, and the programme can pause after any stage. It is the same method we describe under legacy software modernisation, applied to the .NET stack. For where each version stands, see the .NET end-of-support dates.
Talk to us
Describe the system and what you need. You will hear back from someone who can answer technical questions.
Discuss your .NET Framework application 0800 433 7990What we do with .NET Framework systems
- Maintain it where it is
- Fixes, changes and security updates for an application that stays on .NET Framework 4.8.
- Bring it up to 4.8
- Applications on 4.5 to 4.7 are moved to 4.8, usually a small job, which puts them back in support.
- Assess the route to modern .NET
- Which parts will move easily, which depend on technology with no equivalent, and in what order to tackle them.
- Migrate in stages
- New and frequently changed parts move to current .NET first and run alongside the old application.
- Replace what cannot move
- Web Forms, WCF services and other Framework-only pieces are replaced with their current equivalents.
- Modernise build and hosting
- Automated builds, tests and releases, and hosting on Windows or Linux in the cloud.
How a staged migration runs
Inventory
We list every project, library and third-party component and check each for a modern .NET version.
Get onto 4.8 and current tooling
A common, supported baseline makes every later step simpler.
Move shared code first
Business logic and data access are converted so that both old and new applications can use them.
Stand up the new application beside the old
A modern .NET application takes over one area at a time, with requests routed between the two.
Retire the Framework application
When the last area has moved, the old application is switched off.
Support dates
Status is worked out against today's date each time this site is rebuilt. Dates come from the Microsoft .NET support policy; check there before relying on them.
| Version | Released | Security fixes end | Status today |
|---|---|---|---|
| .NET Framework 4.7 to 4.8.1Supported for as long as the Windows version it is installed on. No new features. | 5 April 2017 | No date announced | Supported |
| .NET Framework 4.6.2 | 2 August 2016 | 12 January 2027 | Ending within a year |
| .NET Framework 4.5.2, 4.6 and 4.6.1 | 5 May 2014 | 26 April 2022 | Support ended |
| .NET 8 | 14 November 2023 | 10 November 2026 | Ending within a year |
| .NET 10 | 11 November 2025 | 14 November 2028 | Supported |
A good fit when
- The application is on .NET Framework 4.6.1 or earlier and out of support.
- You want to host on Linux or in containers to reduce cost.
- Libraries you depend on have stopped supporting .NET Framework.
- Hiring or retaining developers for the old stack is getting harder.
Probably not for you if
- The application is on 4.8, stable and rarely changed; staying put is a reasonable decision and we will say so.
- The system has only a short life left before it is replaced.
Questions we are asked
Is .NET Framework still supported?
Versions 4.7 to 4.8.1 are supported for as long as the Windows version they run on, and no end date has been announced. Versions 4.5.2, 4.6 and 4.6.1 went out of support in April 2022, and 4.6.2 follows in January 2027. Supported does not mean developed: .NET Framework receives security fixes but no new features.
Do we have to migrate?
Not if the application is on 4.8 and meets your needs. The pressure to move usually comes from elsewhere: third-party libraries dropping Framework support, hosting costs, performance, or difficulty recruiting. We help you weigh those against the cost of moving.
Can it be done without a rewrite?
For most applications, yes. Business logic and data access usually convert with modest changes. The user interface depends on the technology: MVC applications move fairly directly, while Web Forms pages have to be rebuilt.
Which version of .NET should we move to?
The current long-term support release, which is .NET 10. Long-term support releases are supported for three years, and moving from one to the next is a small job compared with leaving .NET Framework.
How long does a migration take?
A small MVC application can move in a few weeks. A large system with Web Forms, WCF and many third-party components is a staged programme over months. The inventory in the first step gives a specific answer.
Tell us about your system
Say what it does, what it is built on and what is worrying you. We will reply with what we would look at first and whether we are the right people to help.