Migration Strategy Framework: The 8 Rs
Rehost (Lift and Shift)Move workloads to Azure with minimal or no changes. VM to Azure VM using Azure Migrate replication. Fastest path with lowest risk. Does not leverage cloud-native features but provides immediate cloud benefits (OpEx model, elastic capacity, reduced datacenter costs).Replatform (Lift, Adjust, Shift)Make minimal platform changes to leverage managed services. Example: on-premises SQL Server to Azure SQL Managed Instance, or file server to Azure Files. Reduces operational overhead while requiring minimal application code changes.RefactorRestructure application code to better leverage cloud services without changing core architecture. Example: Replace file-based logging with Application Insights, replace custom auth with Entra ID, replace local caching with Redis. Moderate code changes, significant operational improvement.RearchitectRedesign application architecture for cloud-native patterns. Example: Monolith to microservices on AKS, batch processing to event-driven with Functions. Highest effort and risk, maximum cloud benefit.Azure MigrateThe central hub for Azure migration. Provides discovery and assessment of on-premises VMs (VMware, Hyper-V, physical), dependency mapping, cost estimation for Azure equivalents, and replication-based migration for VMs. Integrates with Site Recovery for replication.Azure Database Migration Service (DMS)A managed service for online (minimal downtime) and offline database migrations to Azure. Supports SQL Server to Azure SQL Database/Managed Instance, PostgreSQL, MySQL, and MongoDB. Online migrations use continuous replication to minimize cutover downtime to minutes.8 Rs Quick Reference
| Strategy | Effort | Risk | Cloud Benefit | Typical Timeline |
|---|---|---|---|---|
| Rehost | Low | Low | Low | Weeks |
| Replatform | Medium | Low-Medium | Medium | 1–3 months |
| Refactor | Medium-High | Medium | High | 2–6 months |
| Rearchitect | Very High | High | Very High | 6–18 months |
| Replace (SaaS) | Medium | Medium | High | 1–3 months |
| Retire | Low | Low | High (cost savings) | Immediate |
| Retain | Minimal | Low | None | N/A |
| Rebuild | Very High | Very High | Maximum | 6+ months |
Migration Planning and Execution
Five-Phase Migration Journey
| Phase | Key Activities | Key Tools |
|---|---|---|
| Plan | Discover, assess, dependency map, cost estimate | Azure Migrate Assessment, Azure Pricing Calculator |
| Prepare | Landing zones, networking (VPN/ExpressRoute), RBAC, team training | Azure landing zones framework |
| Execute | Replicate, test failover, cut over, validate | Azure Migrate Replication, DMS |
| Evaluate | Performance vs. baseline, security posture, cost validation | Azure Monitor, Cost Management |
| Decommission | Retire source systems, license savings | Manual or automated |
Hybrid Connectivity During Migration
| Option | Bandwidth | Latency | Setup Time | Best For |
|---|---|---|---|---|
| VPN Gateway | 100 Mbps–10 Gbps | Variable (internet) | Days | Small-scale, temporary |
| ExpressRoute | 1–100 Gbps | Consistent, low | Weeks–months | Large-scale, mission-critical |
| Both (recommended) | ExpressRoute primary + VPN backup | ExpressRoute latency | Weeks–months | Enterprise migrations |
VM Migration Pattern
The cutover process minimizes downtime:
- Initial replication (full disk copy) — hours to days
- Delta sync (continuous, catch changes)
- Test failover — validate in Azure without stopping source
- Final sync and stop source application
- Cutover (minutes of actual downtime)
- Redirect DNS/load balancer to Azure VMs
Database Migration Strategies
| Approach | Downtime | Use Case |
|---|---|---|
| Offline migration | Hours | Small databases, acceptable maintenance window |
| Online migration (DMS) | Minutes (cutover only) | Large databases, minimal downtime requirement |
| Backup/restore | Hours to days | Simple, no DMS complexity |
| Transactional replication | Near-zero | Complex, requires schema compatibility |
Online DMS migration: Uses continuous replication during the cutover window. Only a brief transaction-replay period at cutover creates minutes of downtime versus hours for offline migration.
Azure Data Box for Large Data Transfers
| Tool | Volume | Transfer Method | Use Case |
|---|---|---|---|
| AzCopy | Any | Network (internet or ExpressRoute) | Normal network transfers |
| Data Box Disk | Up to 35 TB | Physical (ship drives) | When network transfer would take weeks |
| Data Box | Up to 80 TB | Physical (ship appliance) | Large migrations with limited bandwidth |
| Data Box Heavy | Up to 1 PB | Physical (pallet) | Petabyte-scale migrations |
Rule of thumb: If network transfer would take more than 7–10 days, use Azure Data Box physical transfer.
Azure Hybrid Benefit
- Windows Server VMs: Use existing licenses to save ~40% on VM compute
- SQL Server on Azure VMs: Use existing licenses to save ~55%
- Azure SQL Database (vCore model): Apply SQL Server licenses for additional savings
Hands-On: Assess and Migrate VMs with Azure Migrate
Step 1: Create Azure Migrate Project
- Navigate to Azure Migrate > Create project
- Select subscription, resource group, region
- Under Servers, databases and web apps, click Discover, assess and migrate
Step 2: Deploy Discovery Appliance
- Click Discover > Discover using appliance
- Select virtualization type: VMware, Hyper-V, or Physical
- Download OVA (VMware) or Hyper-V VHD installer
- Deploy appliance in on-premises environment
- Register appliance with project key and configure vCenter/Hyper-V credentials
- Allow 24 hours for full discovery
Step 3: Create Assessment
- In Azure Migrate > Assessments > Create assessment
- Select discovered servers to include
- Configure:
- Target region, currency, pricing model
- Reserved instance: 1-year reserved (recommended for cost accuracy)
- Sizing: Performance-based (right-size based on actual utilization data)
- Review: Readiness status, estimated monthly cost, recommended VM sizes
Step 4: Replicate VM to Azure
- Under Migration tools > Replicate
- Source: On-premises VMware/Hyper-V
- Select VMs to replicate
- Configure target: Subscription, resource group, target VM size, managed disk
- Start replication — initial sync begins (full disk copy)
Step 5: Test Migration and Cutover
- After replication sync is healthy: Select VM > Test migration
- Select isolated VNet for testing — validates without impacting production
- Validate application connectivity and functionality in test environment
- Clean up test migration resources
- When ready: Select VM > Migrate
- Check Shutdown machines before migration to minimize data loss
- After cutover: Update DNS records, decommission source VMs
Step 6: Migrate Database with DMS (Online)
- Navigate to Azure Database Migration Service > Create
- Select Premium pricing tier (required for online migrations)
- Create migration project: Source = SQL Server, Target = Azure SQL Managed Instance
- Configure source and target connection details
- Start online migration — DMS continuously replicates changes
- Monitor sync status in Migration details
- At cutover window: Stop writes on source, complete migration in DMS portal
AZ-305 Exam Focus
AZ-305 tests your ability to select the right migration strategy for a given workload description and identify which tools to use for each phase. Scenarios describe a workload and ask which of the 8 Rs applies, or which tool (Azure Migrate vs. DMS vs. Data Box) is appropriate.
Exam Trap
Rehost Equals Full Cloud Benefit: Rehost (lift-and-shift) is the FASTEST strategy but provides the LEAST cloud-native benefit. The workload runs on Azure VMs but doesn't leverage PaaS services, managed databases, or auto-scaling. Recognize that rehost is the correct answer when speed and minimal disruption are the primary requirements — not when cloud optimization is the goal.
Exam Trap
DMS for VM Migration: Azure Database Migration Service is for DATABASE migrations (SQL Server, PostgreSQL, MySQL, MongoDB). Azure Migrate handles VM replication and migration. These are distinct tools for distinct migration types. DMS is not used for VM workloads.
Exam Trap
Data Box for All Large Transfers: Data Box is for scenarios where network transfer would take an impractically long time (weeks to months) due to limited bandwidth. If the organization has ExpressRoute or high-bandwidth internet, network transfer via AzCopy is faster and simpler than ordering and shipping physical hardware.
Exam Trap
Online DMS = Zero Downtime: Online DMS migration minimizes but does not eliminate downtime. There is still a brief cutover window (minutes) when writes are stopped on the source, DMS applies the final changes, and the connection string is updated. "Near-zero downtime" is correct; "zero downtime" is not.
Exam Tip
Managed Instance for SQL Server Lift-and-Shift: When a scenario describes migrating on-premises SQL Server with SQL Agent jobs, CLR, linked servers, or SSIS packages — the answer is Azure SQL Managed Instance with Replatform strategy. Azure SQL Database lacks these features; Managed Instance provides near-complete SQL Server compatibility.
Must Memorize
Strategy Selection Triggers: Rehost = move fast, minimal changes. Replatform = managed services (SQL MI, App Service), minimal code. Refactor = change code to use Azure SDKs (Entra ID, Application Insights, Redis). Rearchitect = microservices, serverless. Replace = SaaS (Microsoft 365, Dynamics). Retire = decommission. Retain = keep on-premises (mainframe, hardware requirements).
Question — click to flip
Q: What is the difference between Rehost and Replatform migration strategies?
Question — click to flip
Q: When should you use Azure Data Box instead of network transfer for data migration?
Question — click to flip
Q: What is the difference between online and offline database migration in Azure DMS?
Question — click to flip
Q: A company has a SQL Server with SQL Agent jobs and CLR procedures and wants to move to Azure PaaS with minimal code changes. Which strategy and service?
Question — click to flip
Q: What does the Evaluate phase of the migration journey assess?
Question — click to flip
Q: What is Azure Hybrid Benefit and when does it apply to migrations?