Move off .NET Framework only if you actually need to

Framework 4.8 and 4.8.1 are still supported. The usual deadline is the Windows Server under the app, a WCF service, or a vendor SDK — not a fake Framework end date. We will tell you whether to stay or leave.

Book a free 30-minute discovery callTalk through your Framework app

Australian .NET team. We look at the app before anyone talks about a rebuild.

Still running .NET Framework?

The app still works. That is why it has been left alone.

“.NET Framework” is the Windows-only, machine-wide runtime. “.NET” — Core, 5, and now 10 — is the side-by-side product. A lot of line-of-business systems we hear about were built on 4.x, then the person who understood the WCF endpoints left, and “4.8 has no end date” became the whole strategy.

You might recognise one of these:

  • The app is Framework 4.6, 4.7, or 4.8, and someone said you must move this year
  • WCF, Windows Workflow, remoting, or COM+ is load-bearing
  • A payment, ERP, or device SDK is still Framework-only
  • Two apps on the same box need different 4.x behaviour
  • You “just moved to .NET 8” and are now looking at another hop
  • You are not sure whether to stay on Framework or leave it

You do not need a new brand, or a cloud pitch. You need a clear read on the application you already have.

Why these apps stall

Microsoft’s 2026 guidance is that the latest .NET — currently .NET 10 — is the preferred version for new server work. Reasons to stay on Framework are specific and limited. That is not the same as “Framework is unsupported”. 4.8 and 4.8.1 are Active. They follow the parent Windows version.

Windows clock

WCF / WF

One runtime

Vendor SDKs

“No Framework EOL” is true, and it is how OS debt accumulates.

4.8 and 4.8.1 have no listed end date. 4.7.x is still Active. 4.6.2 ends 12 January 2027. 4.6.1, 4.6, and 4.5.2 already ended on 26 April 2022. The dates that usually bite first are the host OS: Windows Server 2012 and 2012 R2 extended security updates end in mid-October 2026; Windows Server 2016 extended support ends in mid-January 2027. Those are hosting clocks. The Framework app does not die that day.

An in-place 4.x runtime bump is not modernisation.

Microsoft wants customers to hear this: 4.6.2 and later are compatible in-place updates on top of earlier 4.x. Recompile is not required to run on a newer 4.x runtime. That is support hygiene. It is not a move to modern .NET.

Whole technologies do not come across.

AppDomains, remoting, Code Access Security, COM+, and Windows Workflow Foundation have no first-party home on modern .NET. WCF server is not in-box — community CoreWCF exists, it is not a Microsoft port. Web Forms and anything tightly coupled to System.Web force a UI rewrite, not a csproj retarget.

One Framework 4.x per machine.

The 4.x runtime is machine-wide. Side-by-side runtimes are a modern .NET advantage. If this app needs 4.6-era behaviour and that one needs 4.8, operations owns a problem the project file cannot fix.

Vendor SDKs and Windows-only ops sit outside the solution.

Payment, ERP, and device libraries that are still Framework-only are a reason Microsoft itself lists for staying. IIS modules, the GAC, Office interop, and Oracle.DataAccess stall “just retarget net8.0” the same way. Shared libraries have to move leaf-first, ideally to .NET Standard 2.0 or multi-target, before the web head moves.

A .NET 8 landing in late 2026 is a short stay.

.NET 8 LTS is in maintenance and ends 10 November 2026. .NET 10 LTS is Active until 14 November 2028. That is a planning fact, not a scare headline: if you are leaving Framework now, 10 is the runway. Finishing an 8 migration this year still means another hop if you want LTS.

None of that makes the business rules worthless. It does mean “everyone must be on .NET 10 this year” is the wrong first sentence.

How we work

We start with the app, not with a destination.

1

Look at what you have

Framework version, WCF / WF / remoting / COM+, System.Web coupling, vendor SDKs, Windows-only dependencies, and the Server version under it. We will tell you what can stay on 4.8.1, and what has no official port.

2

Decide the job

There are three honest outcomes. We recommend one, not all three.

3

Do the work in stages

Libraries first, then new ASP.NET Core services beside the monolith, then the routes that actually get used. Reporting, workflow, and EDI often replace better than they port.

4

Hand it back so the next person can run it

Source, a short record of what changed, and an app someone else can understand.

Three honest outcomes

  • Stay on Framework 4.8.1, move the OS to a supported Windows Server, and modernise only the sharp edges — TLS, SQL driver, identity. Microsoft: you often do not need to migrate existing Framework apps.
  • Extend with modern .NET — multi-target the shared libraries and put new services on ASP.NET Core beside the monolith, without moving the whole thing.
  • Incremental web migration toward .NET 10 LTS when you are actually leaving. Official path is a new Core front, a reverse proxy, and adapters where they help. Modules that are really WF or WCF often get replaced, not ported.

We will not tell you Framework is dead. We will not tell you WordPress is the answer to a line-of-business system. If you already know you want to stay on 4.8 forever, that can be a responsible choice on a current Windows Server. If you want an honest fork in the road, talk to us.

What we need for the first call

A solution name and a rough Framework version is enough to start.

  • Which Framework version each app targets, and whether anything is still on 4.5.2 or 4.6.1
  • Whether WCF, WF, remoting, or COM+ is in the solution
  • Which vendor SDKs are Framework-only
  • Whether the web head is Web Forms, MVC5, Web API, or a mix
  • Which Windows Server it runs on, and whether other 4.x apps share the box
  • Hosting today (old Windows box, Azure, someone else’s IIS)
  • What “done” looks like: stay on 4.8, start leaving, or get a clear picture first

The first call is 30 minutes. You leave with a recommendation you can take to a manager, not a person-day figure pulled from thin air.

Related work

We have taken over and modernised ageing .NET systems for Australian organisations, including work with Data#3, Hastie, NESS, and NSW Health. Hastie was SharePoint 2007 plus ASP.NET 3.5. NSW Health TESL was SharePoint plus ASP.NET 4.0. NESS is nopCommerce and Dynamics NAV. That is related Framework-era work, not a published Framework-to-.NET 10 case study. Your app still starts with its own assessment. We will not pretend it is a project we have already published.

FAQ

Is .NET Framework unsupported?
No. 4.8 and 4.8.1 are Active and follow the parent Windows version. 4.7.x is still Active. 4.6.2 ends 12 January 2027. Older 4.5.x and 4.6 / 4.6.1 are already out of support. Do not treat a 4.x runtime bump as a move to modern .NET.
What is the real deadline?
Often the OS, not Framework. Server 2012 extended security updates end in October 2026. Server 2016 ends in January 2027. Those dates do not switch the app off. They do change whether the box is a supported place to run it.
Can we just retarget to .NET 8?
Not if WCF, WF, Web Forms, or a Framework-only SDK is load-bearing. And .NET 8 itself ends 10 November 2026. If you are leaving, .NET 10 LTS is the current preferred server target.
Do we have to leave Framework?
No. Microsoft still describes staying on Framework as the right call for many existing apps — especially when a vendor SDK has not moved. Leaving only makes sense when the OS, the missing technologies, hiring, or containers and Linux are the real problem.
We only have a backup and an old server.
That is common. Bring that.

Talk through the Framework app you already have

Thirty minutes. Bring a version number and what the app does. We will tell you whether to stay on 4.8, start moving toward .NET 10, or leave it alone for now.

Book a free 30-minute discovery call