ASP.NET Web Forms migration to .NET 10.
ASP.NET Web Forms migration to .NET 10 without a rewrite: the application moves to ASP.NET Core one route at a time while it keeps serving production traffic, with one login and one session across both stacks.
ASP.NET Web Forms applications moved to ASP.NET Core and .NET 10 in production, one route at a time, with one login across both stacks and no code freeze.
- Typical duration
- 3–9 months
- Shape
- Phased, fixed scope per phase
- Starts with
- Modernization assessment
The incremental path has an awkward first month: nothing visible moves while the machinery that makes moving things safe is built. That month is the whole trick. Once one entry point, one identity and one session hold across both stacks, pages move in small releases, and any one of them can be taken back without the rest of the application noticing.
What this includes
- One entry point: YARP in the new ASP.NET Core application, forwarding anything not yet migrated to Web Forms
- One identity: System.Web Adapters remote app authentication, so nobody signs in twice
- One session: remote session support for the Session state Web Forms code leans on
- Route-by-route migration, ordered by risk and business value
- Re-implemented business logic parallel-run against the original
- Each Web Forms page retired once its replacement has carried production traffic
Migrate Web Forms to ASP.NET Core, in production
Both applications sit behind a single routing layer serving one domain, one certificate and one cookie scope. The new ASP.NET Core application owns routing and forwards anything it does not yet handle to the Web Forms application, so from the first release the old stack starts to shrink.
A route moves only once a user crossing between the two stacks cannot tell. Attempting it earlier produces the classic failure: the page works in isolation, and users get signed out when they click into it.
Web Forms to .NET 10, without a code freeze
Feature work continues on the pages that have not moved yet, because nothing is ever globally frozen. Each migrated route is a small, independently deployable release, and if one misbehaves it goes back to Web Forms while the rest of the application carries on.
The five steps, from drawing the routing boundary to deleting the last Web Forms page, are written out in full with the architecture they produce.
The migration methodFurther reading
- Migration
Moving a live ASP.NET Web Forms application to modern .NET
The route-by-route method in full: what has to be true before the first page moves, how one identity and one session are held across two stacks, how re-implemented business logic is proved correct against the original, and what goes wrong. Written to be executed, including by someone who never hires us.
- Validation
Parallel run testing: proving re-implemented business logic
How to be sure a rule you rebuilt from a specification behaves like the one it replaces, when the specification is incomplete and the original is unreadable. Where to run the comparison, what to compare, how to read the differences, and what to do when the old system turns out to be wrong.
Other services
- Multi-tenant platform development
Multi-tenant platforms built end to end, including the operational surface a business needs in order to actually run the thing.
- Legacy .NET modernization
ASP.NET Web Forms and .NET Framework applications moved to modern .NET, incrementally and in production, without a code freeze.
- Modernization assessment
Two weeks, fixed price. A written migration plan for your legacy system that is useful whether or not you hire us to execute it.