Use an assessment-driven mix of the Rs: pick a migration strategy per workload, establish a minimal landing zone, and run an initial low-risk wave before touching anything critical. Start with Azure Migrate assessments to build the inventory, build the platform foundation in parallel, then sequence execution around checkpoints rather than a fixed calendar date.
TL;DR:
- Migration planning should start with assessment-driven workload classification, selecting the appropriate R strategy based on business drivers and technical readiness.
- Building a simple but effective landing zone in parallel with assessments ensures a quick, controlled environment for initial waves and reduces delays.
- Transitioning workloads in carefully sequenced waves that respect dependencies, with validated rollback plans, minimizes risks and improves confidence.
- Cost estimation relies on assessment settings like region, sizing, and savings options, which should be finalized before presenting figures to finance.
- Continuous validation, stakeholder communication, and risk management are critical for a smooth migration, with post-move optimization focusing on security, rightsizing, and training.
Table of Contents
- Migration strategies at a glance: the Rs and how to pick one per workload
- Assess and inventory: discovery, Azure Migrate assessments, dependency mapping and prioritisation
- Prepare the platform: minimal landing zone and essential guardrails
- Choose methods and sequence: wave planning, cutover strategies and validated rollback
- Tooling and cost: using Azure Migrate, database migration tools and cost-estimation settings
- Execute, validate and optimise: the cutover checklist and post-migration steps
- Stakeholder communication, runbooks and governance during migration
- Risk management and mitigation strategies during migration
- Security considerations and compliance requirements in Azure migration
- Change management and training plans for teams
- Nexus practitioner perspective and pragmatic trade-offs
- How Nexus helps: managed migration, security and landing-zone build services
- Authoritative Microsoft documentation and Nexus references
- FAQ
Migration strategies at a glance: the Rs and how to pick one per workload
Every workload deserves its own answer, not a blanket policy. The eight strategies (retire, rehost, replatform, refactor, rearchitect, rebuild, replace, retain) each solve a different problem, and picking the wrong one wastes budget or drags out a migration programme by months.
- Retire: decommission the workload; use it when nobody can name an active business owner or the last usage log is stale.
- Rehost: move the virtual machine as-is, usually the fastest option for workloads with tight timelines or limited engineering capacity.
- Replatform: swap a component, such as moving a database to a managed Azure SQL instance, while keeping the application logic intact.
- Refactor: make targeted code changes to fit Azure services better, often chosen when a workload needs modest performance or cost gains without a full rebuild.
- Rearchitect: redesign the application structure, appropriate when scaling limits or licensing costs on the current platform are unsustainable.
- Rebuild: start from scratch on cloud-native services, justified when the existing codebase is unmaintainable or the business needs new capabilities entirely.
- Replace: adopt a SaaS alternative instead of migrating the workload, sensible when the function is commodity (email, ticketing, CRM).
- Retain: leave the workload where it is, usually because of contractual, latency or compliance constraints that make Azure a poor short-term fit.
The Azure Migration Hub offers prescriptive guidance for single-workload decisions, and it notes that rehost and replatform are commonly used to minimize risk on the first waves of a programme. That pattern holds for a reason: rehosting defers the harder architectural decisions until after the workload is safely off aging hardware.
Business drivers matter as much as technical readiness. A workload nearing a hardware refresh or a data centre lease expiry is a rehost candidate almost by default. A workload with tight coupling to on-premises Active Directory and no clear owner for remediation is a retain or a later-wave candidate. Red flags for rehosting include applications with hardcoded IP dependencies, license terms that forbid virtualization, or databases already near their performance ceiling; those need replatforming or rearchitecting instead. Before locking in a strategy, validate the choice with the application owner and compliance stakeholders. A workload subject to HIPAA or PCI-DSS may need its strategy revisited if the target Azure region or service doesn't meet the required control set.
Assess and inventory: discovery, Azure Migrate assessments, dependency mapping and prioritisation
A migration plan is only as good as the inventory underneath it. Discovery needs to capture more than a server list: CPU and RAM utilization, disk size and IOPS, network throughput, OS version, service account dependencies, FQDNs and any external integrations. Missing data here shows up later as a failed cutover.
- Run agent-based or agentless discovery across the estate and confirm every workload has complete data on compute, storage and network before moving to assessment.
- Feed discovery data into Azure Migrate assessments, which calculate readiness, rightsizing recommendations and monthly cost estimates in sequence.
- Set assessment properties deliberately: target region, sizing method, pricing preferences and the comfort factor (a buffer applied to sizing to absorb usage spikes) all materially change the recommended target size and the resulting cost.
- Map dependencies between servers and group them into logical applications rather than treating each VM as an isolated unit.
- Score each application on complexity, business criticality, technical readiness, migration effort and expected value to build a priority order.
Azure Migrate assessments produce readiness, rightsizing and cost estimates as a linked sequence, and changing a property like comfort factor or target region shifts all three outputs at once. That's worth knowing before you present a cost figure to finance: the number is only as stable as the assumptions behind it, per Azure Migrate's own documentation.
Dependency mapping is where most inventories fall apart. A database server that looks standalone in a spreadsheet often turns out to feed three reporting tools and a batch job nobody documented. Application grouping, not server-by-server planning, is what keeps a wave from breaking mid-cutover.
Prepare the platform: minimal landing zone and essential guardrails
Build the platform in parallel with assessment work, not after it. A minimal Azure landing zone is the recommended prerequisite for migration, and it doesn't need to be elaborate to do its job.
- Management groups: a simple hierarchy that separates platform, landing zones and sandbox subscriptions.
- Baseline Azure Policy: guardrails for allowed regions, required tagging and resource restrictions, applied at the management group level.
- Hub network with hybrid connectivity: a working path between on-premises and Azure before any workload moves.
- DNS reachability: name resolution that works across both environments during the transition period, not just after cutover.
- Identity baseline: a consistent pattern for how workloads authenticate, whether that's hybrid Azure AD join or federation.
- Central logging: one place to see platform and workload telemetry from day one.
Connectivity choices affect your timeline more than most teams expect. A VPN Gateway can be provisioned in hours; ExpressRoute typically involves a carrier order and a lead time measured in weeks. If ExpressRoute is the long-term plan, start the order early and use VPN as a bridge so the first wave isn't blocked on a circuit provisioning schedule.
Pro Tip: Decide platform versus workload responsibility in writing before wave one starts. Ambiguity over who owns DNS changes or firewall rules is a common source of delayed cutovers.
Landing-zone guidance itself warns against over-engineering governance before the first workloads move. A practical management group hierarchy and a handful of baseline policies, automated through Azure Policy, beat a six-month governance design exercise that delays every migration behind it.
Choose methods and sequence: wave planning, cutover strategies and validated rollback
Waves group workloads by shared dependencies, similar cutover windows and comparable complexity, not by convenience. Migration wave planning treats the sequence as a flexible tool: regenerate the plan whenever new assessment data surfaces a dependency you didn't know about.
- Compose the first wave from low-complexity, low-criticality workloads to validate your runbook and build institutional confidence before anything customer-facing moves.
- Respect dependency constraints: an application and its database move together, even if one looks simpler than the other.
- Choose a cutover pattern deliberately: blue/green for workloads that can run two live environments briefly, phased for large user bases moved in segments, canary for testing a small percentage of traffic first, and big-bang only for small, low-risk systems where a maintenance window is acceptable.
- Validate rollback in staging, not on paper. Plan-your-migration guidance treats a rollback plan as a testable artefact: simulate database failback and message-queue recovery to confirm rollback executes inside the maintenance window.
- Document explicit rollback triggers (error rate thresholds, failed health checks, data mismatch counts) so the decision to roll back isn't made under pressure without criteria.
Checkpoints inside a wave matter as much as the sequence between waves. Set gates at 25%, 50% and 75% completion, and use each one to confirm assumptions still hold, per migration wave planning practice. If a dependency surfaces that wasn't in the original mapping, that's the point to pause, not the point to push through on schedule.
Tooling and cost: using Azure Migrate, database migration tools and cost-estimation settings
Azure Migrate is the assessment and recommendation engine at the centre of most Azure migrations, supporting servers, databases and web apps in a single workflow. Its output feeds directly into strategy choice: a workload with a low readiness score and high rearchitecting effort is a signal to reconsider rehosting versus replatforming before committing a wave slot to it.
- Azure Database Migration Service: the right fit for moving relational databases with minimal downtime, particularly when schema compatibility is already confirmed.
- Azure Site Recovery: suited to server-level replication where continuous sync ahead of cutover reduces the final migration window.
- AzCopy: a straightforward option for bulk file and blob transfers over a network connection.
- Data Box: the practical choice when the dataset is large enough that network transfer would take unreasonably long, moving data via physical shipped storage instead.
Azure Migrate cost estimation defaults to pay-as-you-go pricing assumptions, including 730 hours of monthly compute, unless a savings option is explicitly applied. That single setting, whether you select Azure reservations or an Azure savings plan, is often the biggest lever on the estimate finance will see.
Review these assessment settings before presenting any number externally: savings options, VM uptime assumptions, Azure Hybrid Benefit eligibility for existing licenses, and the offer or licensing program tied to the subscription. Currency and region selection also shift the estimate, so confirm both match the actual deployment target. On the cost-control side, rightsizing based on real utilization data, choosing between reservations and a savings plan based on workload stability, and applying subscription-level budgets with minimal but consistent tagging for cost allocation cover most of the practical ground.
Execute, validate and optimise: the cutover checklist and post-migration steps
Cutover is where planning either holds up or doesn't. The sequence matters more than any individual step.
- Start replication and confirm initial sync completion before scheduling the final cutover window.
- Pause writes to the source system during the final synchronization window to guarantee data consistency at cutover.
- Shift DNS and traffic to the Azure environment, then monitor actively for the first 24 to 48 hours rather than assuming success once the switch is flipped.
- Run automated functional tests immediately after cutover, and use checksums to confirm data integrity matches the source system.
- Compare performance against baseline KPIs captured before migration, not against a general assumption of "faster."
Keep the fallback environment available for a defined stabilization window rather than decommissioning it immediately. Set explicit decommission criteria (a clean monitoring period with no rollback triggers fired) before tearing anything down.
Post-migration work doesn't end at a successful cutover. Clear a rightsizing backlog once real Azure usage data replaces the pre-migration estimate, harden the security baseline for the new environment, and schedule any planned modernization work that was deliberately deferred to keep the migration itself simple. Our guide to hardening an Azure security baseline covers the domains worth prioritizing first.
Stakeholder communication, runbooks and governance during migration
A migration runbook only works if it's specific enough to execute under pressure. It should contain ordered steps, documented rollback triggers, a DNS TTL strategy set well ahead of cutover, explicit sign-off criteria and verification gates that someone actually checks before moving to the next step. Our eight-step cloud migration checklist is a useful starting template for this artefact.
- Schedule distribution: everyone involved knows the exact cutover window, not a vague date range.
- On-call rosters: named people, not team names, for the migration window and the 48 hours after.
- Escalation paths: a clear chain for who decides on a rollback trigger firing.
- Pre-migration readiness review: a final check across teams before the window opens, not a rubber stamp.
Change control matters just as much as communication. Freeze non-essential changes during the migration window, define a fast-track approval path for genuine emergencies, and use CI/CD gates to block deployments into the workload being migrated until cutover completes. Confirm required Azure Policy assignments are active, subscription ownership is formally handed off, and minimal budget alerts are configured before calling the platform ready.
Risk management and mitigation strategies during migration
The biggest risk in most migrations isn't the technology, it's an assumption that was never tested. Treat every assumption in the plan (dependency maps, performance baselines, rollback timing) as something to validate rather than trust.
Build risk mitigation into the sequence itself. Starting waves with low-complexity workloads isn't just about confidence-building, it's a risk control: mistakes in the runbook surface on something recoverable rather than something customer-facing. Maintain a live risk register through the programme, not a static document written once at kickoff, and update it every time a checkpoint reveals a gap between plan and reality.
Data integrity risk deserves specific attention. Checksums and automated functional tests after cutover catch corruption or partial transfers before they reach end users. Network and connectivity risk is another common failure point: confirm hybrid connectivity is stable under load before the first wave, not just reachable in a quick test.
Vendor and licensing risk often gets overlooked until it's expensive. Confirm license portability and support terms for any software moving into Azure before migration, not after a support ticket gets rejected. Finally, budget for schedule risk explicitly: build slack into the wave calendar so a delayed dependency in one application doesn't cascade into missed windows for everything sequenced after it.
Security considerations and compliance requirements in Azure migration
Security and compliance requirements should shape strategy choice, not follow it. A workload subject to HIPAA, PCI-DSS or SOC 2 needs its target Azure services, region and data residency confirmed against those requirements before a strategy is locked in, not discovered as a blocker mid-wave.
Identity is the first practical control to get right. A consistent authentication pattern across the landing zone, whether hybrid Azure AD join or federation, avoids workloads ending up with inconsistent access controls that are hard to audit later. Our piece on workload identity decisions is useful background if your team is weighing whether to build or buy identity tooling for this.
Network exposure deserves a specific check during landing-zone design. Platform landing-zone guidance recommends against forced tunnelling of internet-bound traffic back through on-premises infrastructure unless there's an explicit compliance or inspection requirement, since it adds latency and a single point of failure without a clear benefit for most workloads.
Baseline policy assignments should enforce encryption at rest and in transit, restrict deployment to approved regions, and require logging on any resource handling regulated data. Data protection controls, backup encryption and disaster recovery testing all belong in the same conversation as the migration plan itself, not as an afterthought scheduled for later.
Change management and training plans for teams
The technical plan can be flawless and still stall if the people running it aren't ready. Change management for a migration programme means preparing the operations team, the application owners and the support desk for a different environment, different tools and different failure modes.
Training should be role-specific. Operations staff need hands-on time with Azure Monitor and the new alerting setup before they're on call for it. Application owners need to understand what changed in their workload's behaviour, even in a straightforward rehost, because latency characteristics and backup schedules often shift even when the application code doesn't.
Give the support desk a runbook for the first weeks after cutover, covering the most likely user-facing issues and who to escalate to. A migration that succeeds technically but leaves the help desk fielding confused tickets with no guidance creates a reputation problem that outlasts the actual technical risk.
Build in a feedback loop after the first wave. Whatever training gaps or communication failures show up should get fixed before wave two, not carried forward as a known issue.
Nexus practitioner perspective and pragmatic trade-offs
Governance work expands to fill the time you give it. Cap it at a minimal landing zone and start moving workloads. Sequence low-complexity systems first to build confidence and refine the runbook before anything critical moves. A rollback plan that's never been run in staging isn't a plan, it's a hope.
— Nick - Sr. Executive
How Nexus helps: managed migration, security and landing-zone build services
Running assessment, landing-zone build and wave execution in parallel takes a team that isn't also carrying its regular workload, which is where most in-house migration timelines slip. Nexus handles the full sequence as a managed engagement rather than a set of disconnected projects.
- Assessment and strategy mapping: workload-by-workload recommendations based on Azure Migrate data and business drivers, not a blanket rehost plan.
- Landing-zone build: a minimal, working platform foundation delivered before your first wave, not months into the programme.
- Wave execution and managed security: cutover support with a validated rollback plan and ongoing threat detection once workloads land in Azure.
If your team is planning an Azure migration and wants a second set of eyes on the assessment or wave plan, start with a call. Visit our Cloud Solutions and cybersecurity services page to see the full scope and get a plan built around your workload inventory.
Authoritative Microsoft documentation and Nexus references
For deeper technical detail, the Azure Migration Hub overview and Azure Migrate assessment properties documentation cover strategy selection and cost estimation in full. For landing-zone design, start with what is an Azure landing zone and its governance guidance.
On the Nexus side, our AWS migration guide is useful for teams running multi-cloud comparisons, and the eight-step cloud migration checklist gives a runbook template you can adapt directly. For DNS and URL considerations during cutover, this site migration planning guide covers the web-migration angle worth cross-checking.
FAQ
What are the 7 migration strategies?
The commonly cited set includes rehost, replatform, refactor, rearchitect, rebuild, replace and retain, with retire sometimes added as an eighth option for workloads that should simply be decommissioned. Each maps to a different balance of speed, cost and long-term fit, and the right choice depends on the workload's technical readiness and business criticality.
What are the best practices for migrating to Azure?
Best practice starts with a full Azure Migrate assessment to establish readiness, rightsizing and cost data, paired with a minimal landing zone built before the first wave moves. From there, sequence waves from low to high complexity and validate rollback in staging rather than relying on a written plan alone.
What are the best migration tools for Azure?
Azure Migrate handles assessment and recommendations, Azure Database Migration Service moves relational databases with minimal downtime, and Azure Site Recovery handles server-level replication ahead of cutover. For bulk data transfer, AzCopy suits network-based moves while Data Box fits datasets too large to move efficiently over a network connection.
What are the 7 R's of cloud migration?
The R's typically refer to rehost, replatform, refactor, rearchitect, rebuild, replace and retain, though some frameworks add retire as an additional option for workloads with no ongoing business need. The exact list varies by source, so treat it as a starting menu of strategies rather than a fixed standard.
How long does an Azure migration usually take?
Timelines depend heavily on workload count, complexity and how much landing-zone work is needed before the first wave, so there's no single figure that applies across programmes. Sequencing waves from low to high complexity, with checkpoints at set completion milestones, is the practical way to keep a variable timeline under control rather than committing to a fixed date upfront.