Moving legacy applications to the cloud on Azure is one of the most consequential decisions an engineering organization makes. It’s not a binary choice between staying put or rebuilding from scratch. You’re choosing a migration path that matches each application’s architecture, risk tolerance, and business priority, then executing in a sequence that keeps production stable throughout.
This guide covers the assessment process, the rehost versus replatform versus refactor decision, and a phased approach that works for most Azure migrations.
Key takeaways
- Legacy applications carry assumptions that need to be surfaced before migration begins, not during it.
- Three paths exist: rehost, replatform, and refactor. Most organizations use all three on different applications.
- Sequencing migrations by dependency and risk produces better outcomes than sequencing by size or team preference.
- Networking and identity configuration need to be in place before any application moves.
- Cost monitoring after cutover is as important as the migration itself.
Why Legacy Applications Stall on Premises
Most legacy applications were built for a world where hardware was provisioned in advance and capacity was fixed. They carry assumptions that no longer serve engineering teams well: single-server deployments, local file system dependencies, hardcoded connection strings, and session state stored in memory rather than a distributed cache.
None of these are migration blockers on their own. But each one adds work. The assessment phase exists to surface these issues before the migration begins, not partway through it.
Common findings in legacy application assessments:
- Windows Server versions that require specific Azure VM families
- SQL Server instances with linked servers, SSRS reports, or SQL Agent jobs
- Applications with .NET Framework dependencies that don’t run on modern runtimes
- File share dependencies that need to be redirected to Azure Files or Azure Blob Storage
- Authentication patterns built on NTLM or Kerberos that require Active Directory integration
The goal of the assessment isn’t to produce a reason to avoid migration. It’s to produce an accurate effort estimate and a migration sequence that accounts for dependencies. Our earlier guide covers the four viable approaches to legacy migration at a platform-neutral level.
What’s the Difference Between Rehost, Replatform, and Refactor
Each path carries a different cost-of-change and a different operational outcome. Choosing the right one for each application is the most important decision in a migration program.
Rehost is the fastest option. You move the application to an Azure virtual machine with minimal changes. It behaves the same as it did on premises. This works for applications with complex dependencies, limited development resources, or a planned retirement date. The operational overhead stays high because you’re still managing the VM, the OS, and the runtime.
Replatform makes targeted changes to take advantage of managed services without a full rewrite. A common example is moving a .NET application to Azure App Service, which eliminates VM management while preserving the application’s core logic. SQL Server moves to Azure SQL Database or Azure SQL Managed Instance. File dependencies move to Azure Files. This is the most common migration path for applications with a long expected lifespan.
Refactor involves rearchitecting the application to run as containerized workloads on Azure Container Apps or to adopt cloud-native patterns like event-driven processing and stateless APIs. This takes more time upfront but produces applications that scale efficiently and cost less to operate. Winmill’s post on migrating from AKS to Azure Container Apps covers this in detail.
For broader context on how Microsoft maps out these migration strategies, the Microsoft Learn cloud adoption framework is worth reading before you finalize your approach.
Building the Migration Sequence
Sequencing migrations by dependency and risk produces better outcomes than going by application size or team preference.
Start with applications that have the fewest external dependencies and the clearest modernization path. These early migrations build team confidence and produce reusable patterns that reduce effort on later, more complex applications.
A practical sequence for most organizations:
Wave one covers stateless web applications with no local file system dependencies and standard database connections. These move to App Service with minimal changes and produce early wins.
Wave two covers applications with file share dependencies and SQL Server usage. Azure Files handles shared storage. Azure SQL Managed Instance handles SQL Server workloads that need agent jobs or linked servers.
Wave three covers applications with complex integrations, legacy authentication, or significant technical debt. These may require refactoring before or during migration, and they benefit from the patterns established in earlier waves.
Each wave should include a period of parallel operation where both the on-premises and cloud versions run simultaneously, followed by a planned cutover and a defined rollback window.
If you’re evaluating which migration path fits your applications, Winmill’s cloud engineering team can help you work through the assessment.
How Do You Handle Networking and Identity When Moving to Azure
Most legacy applications assume they’re running inside a corporate network and can reach Active Directory, internal APIs, and shared infrastructure directly. On Azure, that assumption requires deliberate configuration.
Azure Virtual Network, ExpressRoute or site-to-site VPN, and Microsoft Entra ID Domain Services handle these requirements. They need to be in place before application migration begins, not after. Identity is particularly important. Applications that rely on Windows Authentication for database connections or service-to-service calls need to adopt managed identities or modern authentication patterns.
Monitoring After Migration
Moving legacy applications to the cloud doesn’t end at cutover. Many teams treat cutover as the finish line and then discover performance problems, unexpected costs, or broken integrations weeks later.
Azure Monitor, Application Insights, and Log Analytics provide the observability layer that legacy applications typically lacked on premises. Instrumenting the application with Application Insights during the replatform phase produces a baseline of response times, error rates, and dependency calls that makes post-migration troubleshooting much easier.
Cost monitoring matters too. Legacy applications that ran on fixed hardware often generate unexpected Azure spend when moved to pay-per-use infrastructure. Microsoft Cost Management with resource tagging and budget alerts keeps the financial picture clear from the start.
Working With Winmill on Legacy Migration
Winmill’s Modern App and Cloud Engineering team works with organizations at every stage of this process: assessment, architecture, phased migration, and post-migration operations. We help teams make accurate rehost versus replatform versus refactor decisions and design landing zones that support the full migration sequence.
Frequently asked questions
What does moving legacy applications to the cloud on Azure involve?
It involves assessing each application’s dependencies, choosing the right migration strategy, configuring Azure networking and identity services, executing a sequenced migration, and monitoring performance and cost after cutover.
What’s the difference between rehost and replatform on Azure?
Rehost moves an application to an Azure virtual machine with minimal changes. Replatform makes targeted modifications, such as moving to Azure App Service or Azure SQL, to use managed services without a full rewrite. Replatform is the most common path for applications with a long expected lifespan.
How do you handle Active Directory dependencies when migrating to Azure?
Microsoft Entra ID Domain Services provides domain services in the cloud for applications that require Windows Authentication or Group Policy. ExpressRoute or site-to-site VPN maintains connectivity to on-premises Active Directory during phased migrations. Managed identities handle service-to-service authentication for modernized applications.
What’s the right migration sequence for multiple legacy applications?
Start with the applications that have the fewest dependencies and the clearest modernization path. Then progress to applications with shared file dependencies and SQL Server usage, and tackle the most complex integrations in later waves.
How do you control Azure costs after migrating legacy applications?
Use Microsoft Cost Management with resource tagging to track spend per application. Set budget alerts at the application or resource group level. Right-size virtual machines and App Service plans based on actual usage data.
Keep reading
Turning Enterprise Data Into Decision-Ready Intelligence on Azure
Data intelligence consulting addresses a problem most enterprises can name precisely: the organization has data, plenty of it, but the...
Building an Enterprise AI Strategy on Azure
AI strategy consulting has become one of the most requested conversations Winmill has with technical leaders.
Designing a Microsoft Fabric Architecture for Enterprise Data
Microsoft Fabric architecture decisions made early in a deployment determine whether the platform scales well or accumulates technical debt.