Many businesses still run important systems on ASP.NET WebForms. They work, but they are getting harder to maintain, hire for and secure. This guide explains how to move to modern ASP.NET Core step by step, without stopping the business for a risky "big bang" rewrite.
Why migrate at all?
WebForms runs on the .NET Framework, which Microsoft still patches for security as part of Windows but no longer develops. ASP.NET Core is where new features, performance work and tooling go. Staying on WebForms means:
- Fewer developers want to work on it, so changes take longer and cost more.
- Hosting is limited to Windows servers with IIS, while ASP.NET Core also runs on Linux and in containers.
- Performance and modern features such as minimal APIs, built-in dependency injection and better security defaults are out of reach.
There is no WebForms in ASP.NET Core, so this is a migration of the user interface, not just an upgrade. The good news is that much of your business logic can usually come across almost unchanged.
Step 1: Assess what you have
Start with an inventory. For each part of the application, note:
- Pages and user controls, how often they are used, and how complex they are.
- Where business rules live. Code-behind files often mix UI and logic, and logic hidden in code-behind takes the most work to move.
- Dependencies: third-party controls, Crystal Reports, WCF services, COM components and anything that only works on Windows.
- Session state, authentication (Forms authentication, Windows authentication) and how other systems call the application.
This inventory turns "rewrite the system" into a list of pieces you can estimate, prioritise and move one by one.
Step 2: Separate business logic from the UI
Before any new UI is built, move business rules and data access out of code-behind into class libraries. Target .NET Standard 2.0 where possible: the same library can then be used by both the old WebForms app and the new ASP.NET Core app. This step pays off even if the migration pauses, because the code becomes easier to test and change.
Step 3: Migrate incrementally with the strangler fig pattern
Instead of replacing everything at once, put a new ASP.NET Core application in front of the old one. Microsoft's recommended approach uses YARP (a reverse proxy library) and the System.Web adapters:
- The new ASP.NET Core app receives every request.
- Routes you have migrated are handled by the new app; everything else is forwarded to the existing WebForms app.
- The System.Web adapters let both apps share authentication and session state, so users don't notice which app served a page.
- You migrate pages in priority order, release each batch, and eventually switch off the old app.
The system keeps running throughout, each release is small and testable, and you can stop or reprioritise at any point.
Step 4: Choose the new UI technology
- Razor Pages is closest to WebForms' page-based model and is a natural fit for forms-heavy business apps.
- MVC suits larger applications with many shared views and APIs.
- Blazor offers a component model that will feel familiar to WebForms developers, written in C# rather than JavaScript.
- A JavaScript front end (React or similar) with an ASP.NET Core API makes sense if you also plan mobile apps that share the same API.
Step 5: Bring the data layer across
If you use Entity Framework 6, you can keep it in the early stages (EF6 runs on modern .NET) and move to EF Core later. ADO.NET and stored procedures carry over directly. Treat the database as shared between the old and new apps until the migration is complete, and avoid schema changes that would break the old app.
Step 6: Test and release in small slices
Write automated tests around the business rules you extracted in step 2, and add end-to-end browser tests (for example with Playwright) for the key journeys before migrating them. Release each migrated area behind the proxy, monitor errors, and keep the old page available as a fallback until you are confident.
Don't forget hosting
ASP.NET Core on IIS needs the ASP.NET Core Hosting Bundle installed on the server. Many shared hosts don't have it by default; if they are missing it, the site fails with an HTTP 500.19 error. Confirm support before you deploy, or plan a move to a VPS or Linux hosting. Our guide to Windows vs Linux hosting for ASP.NET covers what to check.
How long does it take?
It depends on the size of the application and how much logic sits in code-behind. A small internal app may move in weeks; a large line-of-business system is usually migrated over several months in planned stages, with the old and new apps running side by side.
We modernise WebForms, MVC 5 and older .NET applications for businesses in India and abroad. Read about our web application development and legacy migration services, or request a free code review to get a migration plan for your system.
