Article
"Move it to Azure" isn't actually one decision - it's a choice between at least three different strategies, and picking the wrong one is how migrations end up either over budget or having solved nothing. This piece is a practical, decision-focused companion to our broader architectural writeup, Beyond Lift-and-Shift - if that one is the blueprint, this is the checklist for picking your starting strategy.
Three Strategies, Not One "Move to Azure" Plan
- Rehost (lift-and-shift) - moving the application to Azure infrastructure largely as-is, with minimal code changes.
- Re-platform - moving to managed Azure services (App Service, managed SQL) with modest code changes, gaining real operational benefits without a full re-architecture.
- Re-architect - changing the application's architecture itself as part of the move, not just where it's hosted.
Rehost (Lift-and-Shift): When It's the Right Call
Rehosting is fastest when the goal is genuinely just getting off aging on-premises infrastructure - the application's code and architecture aren't the problem, hosting and hardware maintenance are. It's the lowest-effort option, but it carries forward whatever performance or maintainability issues already existed; it doesn't fix them.
Re-platform: The Middle Ground
Moving to Azure App Service and a managed database, with targeted code changes rather than a rewrite, is usually where the best cost-to-benefit ratio lives for a legacy .NET application: real operational improvements (automatic scaling, managed patching, less infrastructure maintenance) without the cost and risk of changing the application's underlying architecture.
Re-architect: When the Application Itself Needs to Change
Re-architecting is worth the added cost and time when the actual constraint is the application's architecture, not just where it's hosted - inline SQL with no caching layer, a monolith that needs to scale independently by function, or a data layer with fundamental performance issues that no amount of better hosting will fix.
A Checklist for Choosing
- Is the underlying code and query performance sound, or is the real pain in the application itself?
- Is the primary driver hosting/ops cost, or a deeper performance or scalability constraint?
- What's the team's tolerance for downtime and disruption during the move?
- Does the budget support code changes, or does the project need to be infrastructure-only?
Real Example: Re-platforming as the Final Phase of a Broader Modernization
A logistics client's internal dashboard ran on ASP.NET WebForms and on-premises IIS 6, with inline SQL and no caching - reports took up to five minutes to load. The migration to Azure App Service was deliberately the last of four phases: application layer first (ASP.NET Core on .NET 8), then a query and indexing audit, then a Redis caching layer, and only then the move to Azure App Service - because the infrastructure move alone wouldn't have fixed the underlying performance problem. Load time dropped from roughly five minutes to under five seconds, with zero downtime. Read the full Legacy Dashboard Modernization case study.
Next Step
The right Azure strategy depends on whether your system's real constraint is hosting or the application itself - an assessment will tell you which.
Request a Legacy System Assessment - we'll respond within 48 hours with next steps.