.NET Core and early .NET upgrades

Microsoft ships a new .NET every November. Even-numbered releases are long-term support and get three years; odd-numbered ones get two. An application built by a contractor in 2019 or 2021 is usually on whichever version was current that month, and nobody has moved it since.

Finding out which you're on takes a minute: the TargetFramework line in each project file reads netcoreapp3.1, net6.0, net8.0 and so on. The assessment reads every project file and lists them.

.NET Framework applications are stuck because Web Forms and WCF were never carried forward, so parts of them have to be rebuilt. Nothing like that applies here. .NET Core 3.1, .NET 6 and .NET 10 are the same platform at different ages. ASP.NET Core MVC, Razor Pages, Web API, Blazor, worker services and Entity Framework Core all exist on .NET 10 in recognisable form.

So the upgrade is a change of target framework, a round of package updates, and a list of breaking changes to work through, one version step at a time. What takes the time is the list: what changed between the version you're on and the version you're going to, and what in your code touched it.

The recurring ones, from applications we've moved:

• 2.x to 3.x. The hosting model changed and endpoint routing arrived. Newtonsoft.Json stopped being the default serialiser in favour of System.Text.Json, which handles dates, enums and case differently. Entity Framework Core 3 stopped silently running parts of a query in memory, so queries that used to work started throwing.
• 3.1 to 6. Mostly smooth. Nullable reference types and the minimal hosting model are optional and worth adopting. Packages that stopped at 3.1 need replacing.
• 6 to 8 and 10. The application code barely notices. The packages do. IdentityServer4, which a lot of applications of the era used for login, ended support in November 2022 and its successor is commercially licensed. MediatR and AutoMapper moved to commercial licences in 2025, free below a team-size threshold. Each is a decision: pay, replace, or in the case of login, move to ASP.NET Core Identity.
• Anywhere. Windows-only APIs that need a flag or a replacement if the target is Linux. An EF Core migration history that nobody has run from the start. A build that only ever worked on the contractor's machine because the SDK version was never pinned.

None of these is a rewrite. Each is a known change with a known fix, and the assessment lists which ones apply before the price is set.

1. Get it building. The right SDK pinned in a global.json, packages restoring, the solution compiling on a clean machine. This is where an unpinned SDK or a package that has vanished from NuGet shows up.
2. Safety net. Source control, a test environment, a staging environment, and tests around the processes that matter, before any version changes.
3. Step the version. One long-term release at a time for an old application (3.1 to 6, 6 to 8, 8 to 10), or straight to 10 for a small one. Fix the breaking changes at each step, run the tests, move on.
4. Replace what stopped. The packages that ended at an old version, the login library, the licences that changed.
5. Test the data layer. EF Core generates different SQL after an upgrade. Queries run against a copy, then in staging against the live schema.
6. Deploy to hosting you own. The IIS hosting bundle on a current Windows Server, or Linux, or a container, decided on cost and what else you run.

Each stage has its own fixed price, and each ends with the application running on a supported version.

Usually SQL Server or PostgreSQL, and it stays where it is. The upgrade changes the code that talks to it, so the data layer never meets a change until the change has proven itself somewhere else: tested against a copy in a test environment, then run in staging against the live schema with results reconciled, before anything connects to live.

Yes. A single web application upgrades in version steps, each of which leaves it running and can be deployed on its own. A system made of several services moves one service at a time, with the rest untouched until their turn. Where a solution mixes .NET Framework and .NET Core projects, the Framework page covers the other half and the two plans run together.

The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a .NET Core application it reads every project file and package reference, confirms whether the solution builds, lists the breaking changes between your version and .NET 10, and prices the steps as fixed numbers. What drives the price and the payment terms each have a page.

The date, first: .NET 8 and .NET 9 both end on 10 November 2026, so an application that felt current in 2024 is about to be unpatched. Then the compounding. Every version skipped adds a step and a set of breaking changes to the eventual upgrade, and each year more packages drop the old target frameworks. And an unpatched web application facing the internet is the one part of the estate an insurer or a customer's security questionnaire will ask about.

Get it building, put the safety net under it, step the version, replace what stopped, test the data layer. Marc Allington builds on modern .NET now and has taken applications through these version steps, so the breaking changes 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.