Executing Migrations

Simple explanation

Strategy tells you WHAT to move and WHY. Execution tells you HOW.

Three migration categories: Servers (VMs → Azure VMs or PaaS), Databases (SQL → Azure SQL, PostgreSQL → Azure PostgreSQL), and Data (files, blobs, archives → Azure Storage).

Each has dedicated tools and migration paths — the architect chooses based on downtime tolerance, data volume, and target service.

Server migration paths

Server Migration Options
Factor	Azure Migrate (Agentless)	Azure Migrate (Agent-based)	Azure Site Recovery
Source	VMware vSphere	VMware, Hyper-V, physical	VMware, Hyper-V, physical, AWS
Agent required	No (vCenter access only)	Yes (mobility service on each VM)	Yes (mobility service)
Replication	Snapshot-based	Continuous (block-level)	Continuous (block-level)
Downtime	Minutes (final sync)	Minutes (final sync)	Minutes (failover)
Concurrent VMs	300 per vCenter	No limit	No limit
Best for	VMware environments, simple rehost	Large-scale, mixed environments	DR + migration (dual purpose)

Migrating to PaaS

Source	Target PaaS	Migration Path
IIS web apps	App Service	Azure App Service Migration Assistant → assess → migrate
.NET apps on VMs	Container Apps/AKS	Containerise with Azure Migrate app containerisation
Java apps	App Service / Spring Apps	Azure Migrate web app assessment
SQL on VMs	Azure SQL MI/DB	Azure Database Migration Service

Database migration

Database Migration Options
Factor	DMS Online	DMS Offline	Backup/Restore	Data-tier Application (BACPAC)
Downtime	Minutes (cutover)	Hours (full copy)	Hours (restore time)	Hours (import time)
Source	Running database	Running database	Backup file	BACPAC file
Continuous sync	Yes — until cutover	No — one-time copy	No	No
Supported targets	SQL DB, SQL MI, PostgreSQL, MySQL	SQL DB, SQL MI	SQL MI, SQL on VM	SQL DB (smaller databases)
Max database size	No practical limit	No practical limit	Depends on backup/restore speed	~150 GB practical limit
Best for	Production — minimal downtime	Dev/test, small DBs	SQL MI migration with full compatibility	Small SQL DB migrations

🏗️ Priya’s database migration plan:

200+ SQL databases → SQL Managed Instance using DMS online migration
Process: Assess with Azure Migrate → create target MI → start DMS continuous replication → validate → cutover during maintenance window
RPO during migration: ~5 seconds (DMS continuous sync)
Cutover downtime: ~5 minutes per database

Exam tip: Online vs offline migration — know the tradeoffs

Online (DMS): Continuous replication until cutover — minutes of downtime. Higher complexity, requires source database to be running throughout.

Offline: Full copy — hours of downtime but simpler. Acceptable when the business can schedule a maintenance window.

Exam signal: “minimal downtime” → online migration (DMS). “Maintenance window acceptable” → offline or backup/restore.

Unstructured data migration

Tool	Use Case	Volume	Speed
AzCopy	Command-line bulk copy to/from Azure Storage	GB to TB	Network-limited
Azure Data Box	Physical device shipped to you, load data, ship back	Up to 80 TB per device (order multiple)	Days (shipping)
Storage Migration Service	Windows file server migration to Azure Files	Any	Network-limited
Azure File Sync	Hybrid: keep files on-prem with cloud tiering	Any	Ongoing sync
Data Factory	Orchestrated copy pipelines	Any	Configurable parallelism

🏦 Elena’s data migration:

300 TB of financial archives → Azure Data Box (network transfer would take months)
Active file shares → Storage Migration Service to Azure Files (preserves permissions)
Application blobs → AzCopy with concurrent transfers (automated via scripts)

Knowledge check

Question

What tool provides near-zero downtime database migration to Azure SQL?

Click or press Enter to reveal answer

Answer

Azure Database Migration Service (DMS) in online mode. It continuously replicates changes from the source database until cutover, resulting in just minutes of downtime. Supports SQL DB, SQL MI, PostgreSQL, and MySQL as targets.

Click to flip back

Question

When should you recommend Azure Data Box over AzCopy?

Click or press Enter to reveal answer

Answer

When data volume is large (tens of TB to PB) and network bandwidth would make transfer take weeks or months. Data Box is a physical device — load data locally, ship to Microsoft, they upload to your Storage account. Rule of thumb: if network transfer takes more than a week, consider Data Box.

Click to flip back

Question

What's the difference between Azure Migrate and App Service Migration Assistant?

Click or press Enter to reveal answer

Answer

Azure Migrate: discovers and assesses entire datacentres — VMs, databases, web apps — for migration planning. Generates readiness reports and cost estimates. App Service Migration Assistant: specifically migrates individual .NET/Java web apps to App Service — checks compatibility and performs the actual migration. Use Azure Migrate for overall assessment, then specialised tools (DMS, Migration Assistant) for execution.

Click to flip back

Knowledge Check

🏗️ GlobalTech needs to migrate 200 SQL Server databases to Azure SQL Managed Instance with minimal downtime. The databases are actively used during business hours. Which approach should Priya recommend?

Knowledge Check

🚀 NovaSaaS needs to migrate 50 TB of file data from an on-premises NAS to Azure Blob Storage. The migration must complete within 2 weeks. Their internet connection is 1 Gbps. They want to minimise downtime for the final cutover. Which approach should Marcus recommend?

🎬 Video coming soon

Next up: Connecting everything together — Network Connectivity: Internet & Hybrid.