Migrating a legacy .NET Framework app to Azure, without a rewrite
Many small businesses run a critical application that nobody wants to touch. Here is a staged way to move it to Azure and modern .NET while the business keeps running.
If your business depends on an application built on .NET Framework, you are in good company. These systems are often stable and full of hard-won business rules. The trouble is that they are tied to Windows servers, hard to hire for, and increasingly awkward to secure, integrate and scale.
The good news is that moving to Azure does not have to mean starting again. The safest migrations are staged, and each stage delivers value on its own.
Why migrate at all?
- Hosting risk: ageing servers and operating systems are expensive to keep secure and patched.
- Limited integration: modern APIs, identity and analytics are easier to adopt on current platforms.
- Skills: new developers expect to work with modern .NET, cloud tooling and automated deployment.
- Resilience: backups, monitoring and recovery are far simpler on managed cloud services.
Step 1: Assess before you decide
Start with an inventory rather than a plan. Record the framework version, the libraries and NuGet packages in use, any dependencies on Windows-only features (such as the registry, COM components or Windows services), the database, and how the application is deployed and monitored. A short assessment like this usually reveals that most of the application is simpler to move than feared, and a few components are the real obstacles.
Always make the first deliverable a written assessment with a risk list and a cost range. It protects your budget and lets you stop or change course early.
Step 2: Choose a migration path
There are three broad routes, and many projects combine them.
| Approach | What it means | Best when |
|---|---|---|
| Rehost | Move the application largely as it is to Azure virtual machines | You need to leave a data centre quickly |
| Replatform | Move to managed services such as Azure App Service and Azure SQL with small code changes | You want lower running effort without a big rewrite |
| Modernise | Upgrade to current .NET and restructure parts of the application | You plan to keep growing the product |
For most small and mid-sized businesses, replatforming is the sweet spot. It captures most of the benefit of the cloud and keeps the risk contained.
Step 3: Move in layers
A sequence that works well in practice:
- Put the application under source control and automated builds so every later change can be tested and repeated.
- Add tests around the critical business rules before changing anything. These protect the logic your business relies on.
- Move the database to a managed Azure service and confirm the application runs against it.
- Move the application to Azure App Service or containers, with secrets held in Azure Key Vault rather than configuration files.
- Upgrade the code to current .NET, one project or library at a time, using Microsoft’s upgrade tooling as an aid rather than an autopilot.
- Add monitoring and backups so you can see problems before your customers do.
Treat migration as a series of small, reversible moves, not one big cut-over.
Common pitfalls
- Underestimating dependencies on old third-party components that no longer have modern versions.
- Skipping tests, then discovering behaviour changes only after go-live.
- Moving everything at once, which makes problems hard to isolate.
- Forgetting the people side: support staff and users need to know what is changing and when.
Where to start
Begin with the assessment. Within a short engagement you can know what your application depends on, which migration path fits, and what each stage would cost, before committing to the full project.
Running an ageing .NET application?
Book a free 30-minute call, or ask about a fixed-price migration assessment.
Book a call