dotnet-legacy-aspnet

Web Forms has no direct ASP.NET Core equivalent, so map pages to Razor Pages, Blazor Server, or MVC depending on your needs. Replace server controls with Tag Helpers or components, move code-behind logic to PageModel handlers, and replace ViewState with explicit state management.

Replace RouteConfig with endpoint routing, migrate action filters to ASP.NET Core filter contracts, move from third-party containers to built-in DI, and replace Web.config with appsettings.json. Cookie authentication middleware replaces Forms Authentication.

Yes, use incremental migration or the strangler fig pattern: run an ASP.NET Core app alongside the legacy app, route traffic with YARP or a reverse proxy, and migrate one vertical slice at a time. Full rewrites are only recommended for small, well-understood applications.

No, classic ASP.NET has different hosting, lifecycle, and configuration rules. Middleware, built-in DI, HttpContext.Current, and Global.asax events do not transfer directly, so mixing Core guidance into legacy maintenance causes breakage.

Extract business logic from code-behind into standalone service classes, wrap static dependencies like HttpContext.Current and ConfigurationManager behind interfaces, and use extract-and-override test seams. Introduce a DI container compatible with System.Web such as Autofac.

Common pitfalls include assuming API compatibility, ignoring IIS pipeline dependencies, expecting sticky session behavior, relying on ViewState, and using HttpContext.Current, which does not exist in Core. Capture performance baselines and run both stacks in parallel to mitigate risk.