Skip to content
MERVENORBook a triage call

Guide · .NET Framework migration

The hard parts: WebForms, WCF and System.Web

By MervenorPublished Last reviewed 3 min read

In short

Most of a .NET Framework application moves to modern .NET with mechanical changes. Three parts do not: WebForms pages, WCF services and code that leans on System.Web. Each has a known path; choose it per screen or per service, not for the whole application at once.

WebForms: no direct port, three options

WebForms exists only on .NET Framework, so every WebForms page has to be rebuilt in something else. There are three sensible targets:

OptionSuitsWatch out for
Razor Pages or MVCForm-heavy pages that map cleanly to request and responseRe-creating postback behaviour, validation and state that ViewState handled silently
BlazorRich, stateful screens; teams used to components and event handlers (Microsoft's e-book Blazor for ASP.NET Web Forms Developers maps the concepts)Hosting model and connection handling for server-side Blazor
A separate front end (for example React)Screens due for a redesign anywayTwo codebases to run, and an API to design

Third-party control suites (grids, schedulers, report viewers) are usually the longest pole: list each one and check its modern equivalent before estimating. While screens are rebuilt, the remaining WebForms pages keep running on the old host behind the same proxy that serves the new application, so users never notice which screen moved last.

WCF: keep the contract or replace it

  • Keep the contract with CoreWCF when other systems call your services with SOAP contracts you cannot change. CoreWCF is a port of WCF to modern .NET, and Microsoft publishes a support policy for it: the current release, 1.9, is supported on .NET 10 until 14 November 2028. Check every binding your services use against what CoreWCF supports.
  • Replace with ASP.NET Core Web API or gRPC when you control the callers. REST suits public and browser clients; gRPC suits fast service-to-service calls.
  • Calling WCF services from modern .NET is possible with the System.ServiceModel client packages, so the clients can move before the services do.

System.Web: the invisible dependency

System.Web hides in more places than the web pages: HttpContext.Current inside business logic, session state, Forms Authentication and Membership, HTTP modules and handlers, Global.asax events and per-environment web.config files. Their modern equivalents are middleware, explicit dependency injection, ASP.NET Core session (with different behaviour), ASP.NET Core Identity and the options pattern for configuration. During the move, Microsoft's System.Web adapters let shared libraries keep compiling against HttpContext and let both applications share session and sign-in.

Other things that bite

  • Windows-only libraries: COM components, the registry, printing, some imaging and PDF libraries.
  • Scheduled tasks and Windows services that become hosted background services.
  • Synchronous I/O that performs badly on the modern server; plan the async changes.
  • Global and static state that assumed one process per application.
  • Build servers and deployment scripts written for the old tooling.

How to sequence the hard parts

  1. Inventory every WebForms page, WCF endpoint and System.Web call before estimating anything.
  2. Move the easy routes first (Web API and MVC), behind a proxy, to prove the pipeline.
  3. Decide WCF per service: callers you control move to Web API or gRPC; external contracts stay on CoreWCF.
  4. Rebuild WebForms screens last, in order of business value, and delete each old page as its replacement ships.

Questions people ask

  1. Can WebForms run on .NET 10?

    No. WebForms is part of .NET Framework only; the pages have to be rebuilt.

  2. Is CoreWCF safe for production?

    Microsoft publishes a support policy for it, tied to the .NET versions it runs on; stay on its current release.

  3. Do we have to move everything at once?

    No. A proxy in front of both applications lets each page and service move on its own schedule.

If this is your application

Renascia, the upgrade and migration sprint, plans these parts in the Perlustra audit before any price is quoted, then moves them in slices.

.NET Framework migration

01Start

Tell us about the application

Thirty minutes, no slides, no sales script. You leave with a view on what to check first.

Length
30 minutes
Cost
Free
You leave with
A view on what to check first