From an on-prem .NET Framework 4.5 app to .NET 10 on Azure

Map what the system actually does before touching any code.

• Inventory all pages, controllers, and background jobs, and flag any with no clear owner
• Trace direct SQL dependencies and stored procedure usage against the codebase
• Identify third-party libraries and NuGet packages with no .NET 10-compatible version
• Document authentication, session state, and any Windows-specific dependencies (e.g. System.Web, IIS modules)
• Rank modules by business risk and change frequency to sequence later phases

Turn the audit into an ordered, phased migration path.

• Group the application into vertical slices (e.g. by feature area) that can migrate independently
• Choose the strangler fig pattern: new Blazor app runs alongside the legacy app during transition, routed by URL path or subdomain
• Define the target Azure App Service tier, region, and networking (VNet integration if the on-prem SQL Server needs a private connection during transition)
• Agree rollback criteria for each phase before work starts on it

Move logic and UI into the new stack, one vertical slice at a time.

• Introduce Entity Framework Core against the existing SQL Server schema, without altering it yet
• Rebuild the highest-risk, most-changed slice first in Blazor, reusing existing business logic where it's sound
• Extract inline SQL and business rules from code-behind files into testable service classes
• Write regression tests for the slice being migrated before changing its behavior
• Keep the legacy app serving every slice not yet migrated, routed via the strangler pattern from Phase 2

Ship each slice behind a CI/CD pipeline, validated against legacy behavior.

• Stand up Azure DevOps or GitHub Actions pipeline: build, run automated tests, deploy to a staging App Service slot
• Use App Service deployment slots to swap staging into production with zero downtime
• Run the migrated slice in parallel with the legacy version briefly, comparing output where practical
• Cut over DNS/routing for that slice once validated; keep the legacy code path available as a fallback for a defined window

Decommission the old system and keep the new one from becoming tomorrow's legacy.

• Once every slice has migrated, decommission the on-prem server and legacy IIS deployment
• Set up Azure Monitor and Application Insights for the App Service, replacing informal error reporting
• Schedule regular dependency and .NET version updates so the app doesn't drift back into legacy status
• Hand over documentation covering architecture, deployment process, and known technical decisions