.NET Framework modernisation

There's no switch-off date, which is why so much of it is still running. .NET Framework 4.8 ships as part of Windows and is supported for as long as the Windows version it came with, so an application on it isn't unsupported in the way a VB6 IDE is.

What's stopped is everything moving forward. New libraries target modern .NET only. Security fixes for the packages an old application depends on stop arriving. Hosting on anything but a Windows server is out. And the developers who'd take on a Framework codebase are the same developers who'd rather not. The application runs; the business around it can't move it. An application already on .NET Core, or on .NET 5 to 8, is a smaller job with its own page.

The date that does apply is the operating system's. Windows Server 2016 support ends in January 2027, and a .NET Framework application on it goes out of support with the server.

This is the question the assessment answers first, because it decides the shape of the whole project.

Upgrades in place, with work but no rewrite.

• Class libraries and console applications. Usually the easiest.
• WinForms and WPF desktop applications. Both exist on modern .NET; the migration is mostly package updates and API differences, and the screens survive.
• ASP.NET MVC and Web API. Different enough to be a port rather than an upgrade, but the controllers and views mostly carry across.
• Entity Framework 6 to EF Core. A real piece of work, and worth it: the data access layer is where a lot of the technical debt sits.

Doesn't upgrade. Needs a replacement.

• ASP.NET Web Forms. There is no Web Forms on modern .NET. Each page has to be rebuilt, usually in Razor Pages or Blazor, and the sensible way is one page at a time behind a proxy, with the old site still serving the rest.
• WCF services. The server side has a community port (CoreWCF) that can be a bridge, but the long-term answer is REST or gRPC, one service at a time.
• Anything built on Windows Workflow, Remoting or other frameworks that were never carried forward.

A typical application has some of each, which is why the plan is staged rather than a single upgrade.

1. Map the solution. Every project, its target framework, its package references, and which of them are dead. The assessment produces this as a dependency map.
2. Safety net first. Source control, a build that works on a current machine, a test environment, and tests around the processes that matter. Framework applications built years ago often have none of these.
3. Upgrade the libraries. Move shared code to .NET Standard or modern .NET so both the old and new applications can use it. This is the stage that makes everything after it possible.
4. Upgrade what upgrades. Desktop applications and services that have a direct path move across, one at a time, each tested in staging against the live database before switching.
5. Replace what doesn't, alongside. Web Forms pages rebuilt one at a time behind a reverse proxy, so the old site and the new one look like one application to users. WCF services replaced one at a time with the callers re-pointed.
6. Retire the old hosting when the last piece has moved.

Each stage has its own fixed price, and each ends with working software you've already paid for.

Usually SQL Server, and usually it stays exactly where it is. Modern .NET talks to the same database, so old and new applications share it throughout the migration and there's no data move at all. Where EF6 moves to EF Core, the generated queries change and are tested on a copy, then in staging against the live schema, before anything connects to live.

Yes, and for a mixed solution it's the only safe way. Libraries first, then whichever application carries the most risk or the most value, then the rest in order. Web Forms and WCF replacements run alongside the old code behind a proxy, so users never see a cutover. Stop after any stage and keep everything.

The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a .NET Framework solution it maps every project and package, tests whether the thing builds, identifies what upgrades in place and what doesn't, and prices the stages as fixed numbers. What drives the price and the payment terms each have a page.

The server date, first: January 2027 for Windows Server 2016. Then the slow ones. Each year the gap between .NET Framework and modern .NET widens, more packages drop Framework support, and the upgrade gets harder rather than easier. And the developer who knows the solution is a single point of failure for as long as it's on a platform nobody new wants to learn.

Map it, make it safe, upgrade what upgrades, replace what doesn't, one piece at a time. Marc Allington has built on .NET Framework for years and builds on modern .NET now, so both sides of the migration are familiar. Everything we build runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment.