WebForms, and the right order to retire it
There is no lift for WebForms, only a sequence. Which pages move first, what the grid becomes, and the trap in rewriting the whole UI at once.

WebForms is the one legacy .NET stratum with no bridge. WCF got a community port; WebForms got a eulogy: it ships with .NET Framework, it is not coming to modern .NET, and every year of waiting makes the eventual move dearer while the platform underneath (supported, but frozen) grows quieter. So the question is not whether but in what order, and order is everything here.
The trap is the full-UI rewrite: eighteen months of parallel development, a big-bang launch, and users discovering that forty screens changed on the same Tuesday. We have been called in twice to bury one of those. The alternative is the same strangler discipline as any other estate, applied at page level.
The sequence that works:
- Untangle the business logic from the code-behind first.
Every hour spent moving logic out of
Page_Loadinto plain, testable classes pays in both directions: the old pages keep working, and the new stack inherits logic instead of archaeology. This step is unglamorous and is the actual project. - Route by page, not by app. A reverse proxy in front (YARP does this well) sends migrated routes to the new stack and everything else to the old. Users never see the seam. First candidates: read-only pages, reports, anything without ViewState gymnastics.
- Rebuild the ugly ducklings last. The 400-control admin grid with nested UpdatePanels is the page everyone wants to kill first and should kill last: highest complexity, best-understood workarounds, lowest business urgency. Bank thirty easy pages of momentum before you duel it.
- Kill ViewState-dependent workflows on their own line. Anything doing postback state tricks needs a design conversation, not a port. Budget those as small products.
Session state is the hidden boss fight. Old and new stacks sharing users means sharing sessions, and in-proc session was WebForms' favorite bad habit. Move session out (Redis, SQL, anything out-of-process) while still on the old stack, before the proxy goes in. It is a contained change with a rollback, and it converts the migration from "impossible" to "gradual."
Target-wise, keep the decision boring: server-rendered pages move to Razor Pages with the least conceptual distance; genuinely interactive screens argue for Blazor; the API-plus- SPA rebuild is a bigger bet that should win on its merits, not by default. Land everything on the current LTS and give the estate a decade of quiet.
The pace nobody believes until they see it: a page a day, after the first month. Two hundred pages is a year of Tuesdays, not a moonshot. WebForms took fifteen years to accrete. Leaving it in fifteen months, without a single cutover weekend, is what winning looks like.