Assess your Web Forms app before anyone talks about a rewrite

Microsoft has not put an end date on Web Forms. It also does not exist on ASP.NET Core. We will tell you whether to keep it on supported Windows, or start leaving it, without a rebuild from scratch.

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

Still running Web Forms?

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

Most of the Web Forms systems we hear about were built when .aspx and the designer were the default. Then the person who understood the postbacks left, and the control suite became the product.

You might recognise one of these:

  • Nobody on the team wants to open the .aspx files
  • Telerik, ComponentArt, Ajax Control Toolkit, or another bought control pack is the UI
  • Someone said “Microsoft deprecated Web Forms” and you are not sure that is true
  • The box is still Windows Server 2012 or 2016
  • You have been told the only option is a full rewrite to Blazor
  • You are not sure whether to keep the app or leave Web Forms

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

Why these apps stall

Web Forms is still a documented Microsoft framework. It ships inside .NET Framework. Support follows the Windows version under it. The problem is rarely “Web Forms died on a calendar date”. It is the gap between the app you have and a stack you can still hire for, host, and change.

No Core port

Control suites

Windows clock

ViewState

There is no compile onto ASP.NET Core.

Microsoft’s own guidance is blunt: ASP.NET Web Forms are only available in .NET Framework. ASP.NET Core cannot run them. Server controls, the page lifecycle, postbacks, and ViewState have no 1:1 destination. Microsoft’s migration docs start a new Core project and proxy to the old app. Pages are rewritten, not retargeted.

Third-party control packs block a clean move.

Telerik, ComponentArt, Ajax Control Toolkit, and the rest of that era’s .aspx suites have no Core equivalent. If the screens are those controls, a csproj change will not save them.

The clock you actually have is Windows Server.

Framework 4.8 and 4.8.1 are still supported, as a Windows component, for as long as the host OS is supported. There is no standalone Web Forms end-of-life date. What does end: Windows Server 2012 and 2012 R2 extended security updates, in mid-October 2026; Windows Server 2016 extended support, in mid-January 2027. Older Framework runtimes (4.5.2, 4.6, 4.6.1) already ended on 26 April 2022. The app does not switch off when those dates pass. The box under it stops being a supported place to run it.

“Supported” is easy to misunderstand.

Framework 4.8 gets OS-tied security servicing. Web Forms is not receiving new framework investment. Security of your pages still depends on IIS, the libraries you bolted on, and the custom code from 2012. A Framework patch does not fix an old Forms Auth setup or a TLS endpoint you wrote yourselves.

Auth and session have to be redesigned if you leave incrementally.

HttpContext, Forms Authentication, and session are different APIs on Core. Microsoft documents System.Web adapters and remote session / remote authentication as a bridge, not as the finish line.

None of that makes the business rules or the data worthless. It does mean “the app will die in 2026” is the wrong first sentence, and “flip a compiler flag” is the wrong first move.

How we work

We start with the app, not with a destination.

1

Look at what you have

Framework version, page count, third-party controls, session and auth, how much of the logic lives in code-behind versus class libraries, and the Windows Server under it. We will tell you what can stay, and what has no path onto modern .NET.

2

Decide the job

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

3

Do the work in stages

If you are leaving, we follow the path Microsoft documents: a new ASP.NET Core front, a reverse proxy, adapters where they help, and a rewrite of routes that actually get used. Unused screens do not come across.

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

  • Keep running on Framework 4.8.1 on a supported Windows Server, with OS and dependency hygiene only. Microsoft itself says many existing Framework apps do not need to migrate.
  • Leave incrementally with a new ASP.NET Core front (YARP and System.Web adapters), rewriting route by route. Preferred new target, if you are leaving, is .NET 10 LTS — support through 14 November 2028. Landing on .NET 8 in late 2026 is a short stay: that LTS ends 10 November 2026.
  • Rewrite the UI, or replace the app, when the screens are mostly CRUD or the control suite is the whole product. That might be ASP.NET Core MVC, Razor Pages, Blazor, or a packaged line-of-business product. We will not pick one in the first conversation.

We will not tell you Microsoft deprecated Web Forms. We will not tell you WordPress is the answer to a line-of-business app. If you already know you want to stay on Web Forms 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 URL or a screenshot of the app, and a rough Framework version, is enough to start.

  • Which Framework version the app targets (4.5.2, 4.6.x, 4.8, 4.8.1)
  • Which Windows Server it runs on
  • Whether Telerik or another control suite is in the UI
  • How users sign in, and whether session state is in-process, SQL, or something else
  • Whether the business logic can be separated from the pages
  • Hosting today (old Windows box, Azure, someone else’s IIS)
  • What “done” looks like: keep it, 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 rewrite estimate 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 a SharePoint 2007 plus ASP.NET 3.5 portal. NSW Health TESL replaced a ColdFusion / Classic ASP leave system with SharePoint and ASP.NET 4.0. That is related Microsoft web work, not a published Web Forms-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 Web Forms end-of-life?
No. Microsoft has not published a Web Forms end date. Support follows Framework 4.8 / 4.8.1, which follows the parent Windows version. That is not the same as “safe forever”, and it is not the same as deprecated.
Will the app stop working in 2026?
Not because it is Web Forms. The near-term dates are the host OS: Server 2012 extended security updates end in October 2026; Server 2016 extended support ends in January 2027. The app keeps running. The box may no longer be a supported place to run it.
Can we just retarget the project to .NET 10?
No. There is no Web Forms on modern .NET. Microsoft’s path is a new Core app plus a proxy, then rewritten pages. Control suites do not come with you.
Do we have to leave Web Forms?
No. Keeping a stable app on Framework 4.8.1 and a current Windows Server is a path Microsoft still describes. Leaving only makes sense when the OS, the control suite, hiring, or a feature you cannot build on Web Forms is the real problem.
We only have a backup and an old server.
That is common. Bring that.

Talk through the Web Forms app you already have

Thirty minutes. Bring a URL and a Framework version if you know it. We will tell you whether to keep it on supported Windows, start leaving Web Forms, or leave it alone for now.

Book a free 30-minute discovery call