Category:.NET
Moving a legacy .NET app to Azure without a rewrite
Cloud migration does not have to mean modernization-by-rewrite. A pragmatic path for moving .NET Framework, Web Forms, or WCF applications to Azure — lift-and-shift first, then modernize incrementally where it reduces risk and cost. What to move, what to re-architect, and what to leave alone.
If you are responsible for a legacy .NET application, "move to Azure" probably arrives as a mixed message. On one side: end-of-support deadlines, on-prem hardware that is aging out, and leadership that wants out of the data center. On the other side: every Azure architecture diagram you have seen assumes .NET 8, containers, and a rewrite you cannot afford.
Here is the message that gets lost: cloud migration and application modernization are different projects. You can move a .NET Framework application to Azure in weeks — without rewriting it. Modernization can then happen incrementally, at your pace, where it reduces risk and cost. You are not choosing between "stuck on-prem" and "full rewrite". There is a middle path, and it is the one most legacy systems should take.
Decouple the two decisions
The biggest mistake is bundling "move to cloud" with "rewrite the app". They have different risk profiles, different timelines, and different budgets. When they are bundled, the migration waits for the rewrite — and the rewrite never gets approved, so the app stays on dying hardware.
Decouple them:
- Decision 1: where it runs. This is the migration. It can be done with the application largely unchanged.
- Decision 2: how it is built. This is modernization. It happens incrementally, afterwards, in slices.
Nothing about Azure requires you to solve both at once.
The pragmatic migration path for .NET Framework / Web Forms / WCF
1. Rehost (lift-and-shift) first
For a .NET Framework application, the fastest and lowest-risk move is to run it on Azure as it is:
- Windows VMs running IIS, with the app deployed unchanged. This is the true lift-and-shift: same OS, same IIS, same code, new home.
- Azure App Service on Windows, which supports .NET Framework and is the natural next step if you want to shed VM management. Web Forms and MVC applications deploy to App Service with minimal changes — usually just connection strings and configuration.
- Azure SQL Database for the database, replacing on-prem SQL Server. The migration tooling handles schema and data; your queries mostly keep working.
This gets you out of the data center with a bounded effort. It does not fix the code — but it is not supposed to. It is the foundation that makes everything else possible.
2. Stabilize during the move
A migration is a rare opportunity: you are touching every configuration, every connection string, every deployment script anyway. Use the move to add the reliability basics that legacy systems are usually missing:
- Bounded timeouts on every external call, so a slow dependency degrades gracefully instead of hanging the app.
- Safe retry policies with caps and jitter — never infinite retries, never retry storms.
- Structured logging and correlation IDs, so the next incident is diagnosable. (This is where correlation IDs pay for themselves.)
- A runbook — because the people who "just know" how this system behaves will not be there forever.
None of this requires a rewrite. It is a stabilization pass done alongside the migration, and it transforms the risk profile of everything that follows.
3. Modernize incrementally — only where it pays
Once the app runs in Azure and is stable, you can modernize at your own pace, choosing slices by business value:
- Web Forms → ASP.NET Core, one feature area at a time, using the System.Web adapters that let old and new code run side by side during the transition. You do not migrate the whole app in one release; you run both, route traffic progressively, and cut over when parity is proven.
- WCF → modern HTTP/API — the modern equivalent of WCF services is a well-defined REST API. You can stand up the new API alongside the old WCF endpoints and migrate consumers one at a time. The strangler pattern applies to services exactly as it applies to apps.
- Containerization — once the app is on modern .NET, containerizing becomes an option. It is usually worth doing for new or heavily-deployed components, and rarely worth it for small internal services that App Service runs fine.
The rule: only modernize a component when it is causing a specific, measurable problem — end-of-support pressure, poor performance, or a change you need to make that the old stack blocks. Modernizing for its own sake is how you burn the budget that should have been spent on features.
What you can safely leave alone
Part of a good migration plan is the list of things you are not going to do:
- Business logic that works. If the order-processing rules are correct, battle-tested, and stable, do not rewrite them just because they are old. Preserve them; modernize the plumbing around them.
- Integrations that are happy. A legacy integration that has run reliably for a decade is a liability only when it breaks. Rebuilding it is optional, not required.
- Minor UI quirks. Web Forms code-behind is ugly, but if users depend on its behavior, changing it is a risk, not a cleanup. Modernize it in slices if you must, not as part of the migration.
The art of the migration is knowing what to preserve. A rewrite mindset treats everything old as debt. A modernization mindset treats working, revenue-generating behavior as an asset to protect.
What the roadmap looks like
A realistic sequence for a legacy .NET application moving to Azure:
- Assessment — inventory the app, its dependencies, its integrations, and the top risks. Decide what moves as-is and what must change first.
- Rehost — move the app and database to Azure (App Service + Azure SQL, or VMs if the app demands it).
- Stabilize — timeouts, retries, observability, runbooks. Stop the recurring incidents.
- Prioritize — the modernization roadmap, ranked by business value and risk, with the smallest first slice identified.
- Modernize incrementally — Web Forms to Core, WCF to API, one slice at a time, with parallel runs and safe cutovers.
That last point is why the roadmap matters more than the individual steps: a modernized legacy system is still a legacy system if nobody can safely change it. The goal is not "everything rewritten". The goal is a system that is cheap to run, safe to change, and still delivering the business value it always did.
The bottom line
Moving to Azure does not require a rewrite. Rehost first, stabilize during the move, then modernize incrementally where it pays. Preserve what works, change what hurts, and measure every step.
If you are weighing an Azure move for a .NET Framework, Web Forms, or WCF application, the Legacy .NET Modernization Assessment is built for exactly this decision: we assess what moves as-is, what must stabilize first, and what is worth modernizing — then tell you honestly the smallest set of changes that gets you there.
Related posts
Rewrite or modernize? How to decide for your legacy .NET application
The rewrite-or-modernize decision is a business decision, not a code decision. A practical framework for CTOs and engineering leaders running long-lived .NET Framework, Web Forms, or WCF applications — when a rewrite makes sense, when it does not, and how to find out without guessing.
Adding AI to an existing .NET application without replacing it
You do not need a greenfield build to add AI to your .NET application. A pragmatic path for engineering leaders: augment an existing system with AI capabilities — semantic search, classification, copilots — while preserving the business logic that already works.
Why your legacy .NET application keeps getting slower (and what to measure first)
Legacy .NET apps slow down for predictable reasons — query bloat, blocking I/O, lock contention, and compounding technical debt. A practical guide for engineering leaders: what to measure first, how to find the real bottlenecks in days, and why "it's just old" is not a diagnosis.
Next step
Legacy .NET rescue, modernization patterns, and production reliability guides.