How to Migrate a Legacy .NET App to Azure

To migrate a legacy .NET app to Azure, you move your .NET Framework codebase to App Service, Azure SQL, and Key Vault using a strangler-fig pattern that routes traffic to new slices while the old app keeps running. No big-bang rewrite required.

What you need before you start

Gather the following before writing a line of migration code. For related Azure migration patterns, see the QServices guides hub.

• Application inventory: Every project in the solution, its target framework (.NET Framework 2.x through 4.8 or .NET Core), and its full NuGet dependency tree.
• Azure subscription with Owner or Contributor rights on the target resource group.
• Azure CLI and Docker Desktop installed locally for building and testing container images.
• .NET 8 SDK to build and run the upgraded application alongside the legacy version during parallel testing.
• Database schema and data dictionary: Every stored procedure, trigger, and application-enforced constraint that encodes business rules. These must travel with the code, not just the schema.
• Integration map: Every upstream and downstream system the app interacts with, including message queues, file shares, and third-party APIs.
• Access to the existing deployment environment so you can run old and new in parallel during cutover validation.

Review the official Microsoft .NET porting documentation for a framework-version compatibility checklist before your first session.

Step-by-step: migrate a legacy .NET app to Azure

1. Inventory the app. Run the .NET Upgrade Assistant against the solution to generate a compatibility report. Document the framework version, every NuGet package that lacks a .NET 8 equivalent, all external integration points, and the data integrity rules buried in stored procedures or application code. Missing a single integrity rule here is the most common cause of silent data corruption later in the migration.
2. Pick a migration strategy per component. Classify each module as rehost (lift-and-shift to Azure App Service on a Windows plan or Azure VMs), replatform (port to .NET 8 with minimal code changes and run on Linux App Service), or rebuild (rewrite a bounded slice as a clean .NET 8 service on Azure Container Apps). Document the rationale for every decision. Teams revisit these choices when timelines slip, and having the reasoning on record prevents scope creep.
3. Apply the strangler-fig pattern. Place an API gateway (Azure API Management or Ocelot) in front of both the legacy app and the new service endpoints. Route specific URL paths to the modernized slices; all other traffic falls through to the legacy app. The legacy system stays live throughout. Never decommission the old app until the replacement slice has processed real production traffic for at least two weeks.
4. Stand up Azure foundations. In the target resource group, provision Azure App Service (or Azure Container Apps for containerized workloads), Azure SQL migrated from your on-premises SQL Server, Azure Key Vault for all secrets and connection strings, and your chosen API gateway. Define all infrastructure as Bicep or ARM templates from day one so the environment is fully reproducible. Store no credentials in application configuration files; use Key Vault references only.
5. Migrate data with integrity rules intact. Use Azure Database Migration Service or a scripted SQL export to move data to Azure SQL. Before routing any live traffic to the new environment, run old and new databases in parallel and compare outputs from identical transactions. Every stored procedure, trigger, and constraint must produce the same result in Azure SQL as it did on-premises. Advance only after parity is confirmed.
6. Cut over slice by slice, monitor, and decommission. Shift production traffic to each modernized slice via the API gateway. Monitor Application Insights for error rate and latency regressions. Hold the previous slice in standby for at least 48 hours before decommissioning. Repeat per slice. Remove legacy components only after the final slice has been stable in production.

App Service vs. Container Apps: choosing the right compute target

The right Azure compute target depends on whether you are replatforming an existing monolith or rebuilding into independent services. Use the table below as a starting point.

If your app has Windows-only dependencies such as COM interop or IIS-bound Windows Authentication, start with App Service on a Windows plan. Containerizing those dependencies in the first migration pass adds weeks of unrelated work. You can move to Container Apps in a later phase once those dependencies are resolved.

Where this gets tricky

The big-bang rewrite. Teams scope a full .NET 8 rewrite from the start, spend six months building it, and then face a risky single cutover with no fallback path. The strangler-fig approach keeps the legacy app live until each new slice has proven itself in production. If your team is debating a full rewrite, see our Legacy System Modernization page for an honest look at phased-versus-big-bang cost and risk differences.

Leaving data integrity rules behind. A schema migration moves tables and columns. It does not automatically move a trigger that enforces a uniqueness constraint or application code that validates a business rule before writing to the database. Those rules need to be explicitly identified during the inventory step, re-implemented in the new environment, and verified through parallel data comparison before any traffic is switched. You find out about missing rules through corrupted production data, not a failing test.

Underestimating the integration surface. Every system that touches your app is a potential cutover blocker. Legacy systems on fixed-IP whitelists, SFTP file drops, and synchronous batch jobs all need explicit migration plans. Systems that appear read-only often write back through obscure paths that only surface under load.

How QServices handles .NET-to-Azure migrations

QServices has delivered .NET-to-Azure modernizations across manufacturing, wealth management, and enterprise software, including a VB.NET monolith-to-.NET 8 migration for a global EHS platform and a cloud migration for a stock analytics platform that replaced manual spreadsheets with an Azure-hosted dashboard delivering real-time financial metrics.

A standard engagement runs 16 to 52 weeks depending on integration complexity, with total cost typically between $60,000 and $500,000. We apply the strangler-fig approach by default. Every step that touches production data goes through a human review gate before cutover proceeds. This is a direct application of our Human-in-the-Loop governance model, where a human approves each high-stakes decision before it executes.

For a project-specific estimate, see our Legacy Modernization cost page or contact us directly.

Is App Service or Container Apps cheaper for a migrated .NET app?

App Service is typically cheaper for a single migrated .NET application. The Basic and Standard tiers cost less than Container Apps at low traffic volumes, and you avoid the Docker build pipeline overhead. Container Apps becomes cost-competitive when you have multiple independently scalable services, where scaling idle services to zero while others stay warm reduces compute cost compared to keeping a full App Service plan reserved at all times.