Rehost, refactor or rearchitect: choosing the right Azure migration strategy.
Azure migration is often described as a technical choice. That framing is too narrow. The approach should be determined by business requirements, operational tolerance for change, timeline constraints and the organisation's ability to run the target environment after migration — decided workload by workload, not by migration slogan.
See the per-workload decision frameworkA strong Azure migration strategy decides, workload by workload, whether to rehost (move with minimal change), refactor (targeted changes to use Azure services better), rearchitect (redesign for cloud-native), retain temporarily (keep it where it is until dependencies or timing resolve), or retire or replace (avoid carrying forward systems that should not be). The method determines long-term cost, operational complexity and performance — and the decision belongs before landing zones are built and before the first workload moves.
Azure migration is a business-risk decision before it is a technology decision.
A manufacturing system that supports production has a different risk profile from a development environment. A client management system has different availability requirements from an internal HR system. A VMware estate under renewal pressure may need a fast exit for some workloads, while others need a more deliberate path into Azure-native services. Most migration problems trace back to mismatched approaches: rehosting applications that needed refactoring for performance or cost; rearchitecting stable applications that worked adequately; attempting rearchitecture without the skills, timeline or business appetite to support it; moving workloads before the landing zone is ready; and treating technical migration success as operational migration success. The strategy decision shapes every downstream outcome — cost, performance, supportability, operational complexity and long-term technical debt. Execution discipline matters, but if the strategy is wrong, execution alone cannot save the project.
Six factors determine the migration approach.
The migration method determines long-term cost, operational complexity and performance characteristics. Wrong choices create technical debt that compounds over time and becomes expensive to unwind, which is why the strategy is decided before the landing zone is built.
- Workload criticality and stability requirements
- Technical debt and application architecture
- Timeline pressure and business requirements
- Operational complexity and change tolerance
- Cost constraints and optimisation opportunities
- Skills availability and operational capacity
Every migration uses one or more of three approaches — and the right answer may differ across workloads in the same estate.
A database layer might be refactored to Azure SQL while a web tier is rehosted to Azure VMs; a legacy application may be retained temporarily while surrounding services move. The approach should follow the workload, not the migration slogan.
Moving workloads to Azure with minimal or no application change, often using Azure Migrate or Azure Site Recovery to replicate existing VMs, storage and network. Best where stability, speed and business continuity matter more than immediate optimisation: mission-critical systems, time-constrained migrations, VMware or data centre exit deadlines, and applications where business risk outweighs the benefit of redesign. The benefit is speed and lower change risk; the trade-off is that the workload may carry old design assumptions into Azure, including cost inefficiency and technical debt.
Targeted changes so the workload uses Azure services more effectively without fundamentally changing the application architecture — moving a database to Azure SQL, using Azure networking and security, improving monitoring and backup, adjusting identity integration. Best where the workload is viable but would benefit from selected Azure services: performance issues, integration challenges, or clear cost-optimisation opportunities that do not justify full rearchitecture. The benefit is better long-term fit; the trade-off is more planning, testing and change management than a straight rehost.
Redesigning the application for cloud-native patterns — containers, serverless, managed PaaS, microservices, event-driven architecture, modern identity and redesigned data layers. Best where the existing application has significant technical debt or the business case justifies redesign: legacy applications with major limitations, systems requiring substantial scalability improvement, or workloads modernised as part of a broader product strategy. The benefit is stronger long-term architecture; the trade-off is cost, time, delivery risk and organisational change. Rearchitecture should be used when the workload genuinely needs it, not to demonstrate technical sophistication.
Migration approach is not about what is technically possible — it is about what is appropriate and achievable.
Decisions should be based on objective criteria rather than technology preference or a desire to standardise the whole estate into one path. Six criteria decide the approach for each workload.
Criticality assessment
How much operational disruption can the business absorb? Mission-critical systems often suit rehost or staged migration even where a refactor is technically attractive; lower-risk internal workloads can tolerate more change.
Technical complexity
How complex is the architecture and dependency pattern? Complex interdependencies favour rehost or staged migration; self-contained applications with clear APIs are stronger candidates for refactor or rearchitecture.
Performance requirements
Is current performance acceptable, and can Azure improve it? Workloads with performance issues may benefit from refactor to managed services; well-performing applications may be rehosted without unnecessary change.
Timeline constraints
Is there a hard deadline? VMware exit, data centre lease expiry, hosting exit or compliance timing may force rehost or AVS-bridge approaches, even where refactor would be preferable in a slower programme.
Cost profile
Will the approach improve or worsen long-term cost? Rehosting a steady-state workload is fast but not always cost-effective; refactor or rearchitecture may reduce cost, but only if the business case supports the extra change.
Operational capacity
Can the organisation operate the target model after migration? A technically elegant Azure design still fails if the team does not have the skills, processes, monitoring and support model to run it.
Six criteria, and the right approach differs for every workload. A migration strategy applies them across your estate — deciding what to rehost, refactor, rearchitect, retain or retire before the first workload moves.
Map your workloadsVMware customers usually have two Azure paths — and they are not mutually exclusive.
Many organisations use Azure VMware Solution for immediate exit while planning longer-term movement to Azure-native services for selected workloads. AVS gives speed; Azure IaaS gives VMware independence.
- Runs VMware workloads in Azure without immediate re-platforming
- Preserves the VMware operating model (vSphere, vCenter, NSX, vSAN)
- Suits time-constrained exits and complex VMware-dependent apps
- Useful while a longer-term phase is planned
- Moves workloads to Azure VMs, managed disks and Azure networking
- Removes the VMware dependency rather than recreating it
- Opens the door to Azure-native services over time
- Suits smaller footprints and long-term cost optimisation
Related: VMware exit strategy, Azure VMware Solution and VMware workload placement.
Landing zones must be built before migration begins.
Migration projects usually fail because of foundation decisions, not migration execution. Every migrated workload inherits the landing zone's decisions on governance, security, networking and cost management — which is why the foundation architecture matters more than the migration technique, and why getting it wrong creates compounding problems that are expensive to retrofit. The migration strategy's job is to confirm the foundation is ready and sequence around it. The foundation must settle five things before workloads move:
- Subscription and governance structure (management groups, subscriptions, policy)
- Network architecture and connectivity (hub-and-spoke, routing, connectivity)
- The security baseline and monitoring
- Identity and access management
- Backup, recovery and cost governance
The detailed design of subscription structure, hub-and-spoke networking, Azure Policy governance-as-code and identity belongs to Azure landing zones, which this strategy depends on.
Sequencing should minimise risk and maximise learning.
The early waves should prove the landing zone, tooling, operational processes, monitoring, backup behaviour and support response before mission-critical systems move. A sensible sequence usually runs:
Low-risk workloads that validate landing zone architecture, migration procedures and operational processes — learning without major business impact if issues occur.
File servers, backup, monitoring and other supporting services — building operational confidence while providing real business value.
Applications with business impact but manageable downtime tolerance — validating application migration patterns and performance characteristics in Azure.
Core business applications, moved after patterns are proven and operational procedures validated — minimising business risk through proven execution.
Each wave should include operational validation, performance testing, backup validation, security review, business acceptance and post-cutover stabilisation. A workload is not truly migrated until the business can operate it confidently. Cross-platform sequencing detail is covered on Hybrid infrastructure workload migration.
Migration readiness is operational, not just technical.
Many failed migrations had sound technical execution but inadequate operational readiness. Business readiness includes skills, procedures, cost governance, change management and stakeholder alignment.
The team needs Azure administration, monitoring, troubleshooting and optimisation capability. The question is not only whether the partner can move the workload, but whether the organisation can operate it after cutover.
Change management, incident response, backup verification, capacity planning and support escalation need to be adapted for Azure. On-premises procedures rarely transfer cleanly without adjustment.
Azure cost management requires budget controls, spending monitoring, resource optimisation and ownership for cost review. Cloud cost models behave differently from on-premises capex, and without governance, cost drift undermines the business case.
Continuity plans need to account for cloud service and identity dependencies, recovery testing and communication protocols. Assuming cloud automatically improves DR is a common mistake — the recovery model has to be designed and tested.
Cost optimisation needs to be designed into the strategy, not fixed afterwards.
Azure can be commercially efficient when the workload fit and operating model are right; it can become expensive when workloads are rehosted without resizing, governance, reserved-capacity planning, shutdown policies, storage lifecycle rules or clear ownership. Cost optimisation is not only a finance concern — it is part of the technical design. The strategy should consider:
- Workload sizing before migration, and rightsizing after stabilisation
- Reserved instances or savings plans where usage is predictable
- Storage tiering, lifecycle policy and backup retention settings
- Monitoring and log ingestion cost, network egress and data transfer
- Tagging, ownership, budget alerts and a regular cost-review cadence
What good looks like after migration.
A good strategy should leave the organisation with an environment that is easier to operate, govern and improve than the one it replaced.
- Workloads migrated using the right method — each rehosted, refactored, rearchitected, retained, retired or replaced on its own requirements
- An Azure foundation in place before production migration — landing zones, identity, network, security, monitoring, backup and cost governance established before workloads depend on them
- A clear operating model — who owns monitoring, patching, backup, incident response, cost review, access control and lifecycle improvement after cutover
- Better cost visibility — Azure cost monitored, governed and reviewed rather than discovered through invoice shock
- Lower migration risk over time — early waves create learning that reduces risk for later, more important workloads
- A practical next-step roadmap — which workloads to optimise, modernise, retain, retire or move later
Strategy designed for business outcomes, not technical complexity.
Migration approach decisions should follow workload characteristics, business requirements and supportability rather than vendor preference or a desire to standardise the estate into one path. Both the AVS fast-exit and Azure IaaS migration paths are assessed, with the recommendation following timeline, cost, dependency complexity and operating-model requirements. Migration strategy is designed around proper landing zone foundations, so governance, security, identity, networking and cost controls are in place before workloads move; operational readiness — skills, procedures, cost governance, backup verification, support model and change management — is assessed before migration begins; and migration waves are sequenced by business impact and learning opportunity, not technical convenience, so low-risk workloads validate the model before mission-critical systems move.
As an illustration of the pattern rather than a headline: in recent Azure migration work, the successful approach was not "move everything to cloud." The work started with workload assessment, landing zone readiness, sequencing, backup posture, identity, monitoring and operating ownership. Some workloads moved to Azure, some required stronger foundation work first, and some stayed connected to retained local infrastructure because performance, dependency or business-process requirements made blanket migration the wrong answer. That is the right pattern: the strategy should reduce risk while creating a stronger operating model after cutover.
Migration flexibility is the benefit. Matching the approach to workload requirements and business constraints is the discipline.
The migrations that go wrong are rarely the complex ones — they are the ones sequenced by convenience instead of dependency.
Sequence it properly →Azure migration strategy questions we hear most.
What is the difference between rehost, refactor and rearchitect?
What is an Azure landing zone and why does it matter?
How does VMware to Azure migration work?
What is the typical timeline for Azure migration projects?
How do you determine which migration approach to use?
Should every workload move to Azure?
What business readiness factors affect migration success?
What should be done before the first workload moves?
How is cost controlled during and after migration?
Where does Azure migration strategy sit in the cloud structure?
Choose the migration approach before workloads start moving.
A migration strategy decides, workload by workload, what to rehost, refactor, rearchitect, retain or retire, confirms the landing zone is ready, and sequences the waves by risk, so execution follows a plan rather than a slogan.
Explore Managed Cloud and Migration