Cloud Migration Services: AWS vs Azure vs Google Cloud
Discovery, server rehosting, database migration and bulk data transfer: what each migration service does and how AWS, Azure and Google Cloud compare.
Most cloud migrations don’t fail on the technology. They fail on the inventory nobody finished, the dependency nobody mapped (“that server also runs the payroll export at month-end?”), and the cutover weekend that turned into a cutover month. The providers offer free tooling for every stage, from discovery to the final switch. This post walks through the migration stages, what each service is for, and how AWS, Azure and Google Cloud compare.
What the migration category covers
A migration programme has a fairly standard shape, whichever cloud you’re moving to:
%%{init: {"themeVariables": {"fontSize": "14px"}, "flowchart": {"useMaxWidth": false, "nodeSpacing": 30, "rankSpacing": 40, "padding": 8, "wrappingWidth": 150}}}%%
flowchart TB
subgraph PREP["Prepare"]
direction LR
D[Discover and<br/>assess] --> P[Plan waves and<br/>landing zone]
end
subgraph MOVE["Move and improve"]
direction LR
R[Replicate and<br/>test] --> C[Cut over] --> O[Optimise and<br/>modernise]
end
PREP --> MOVE
The tooling maps onto those stages:
- Discovery and assessment. Inventory servers, map dependencies, size targets and build the business case.
- Server migration. Replicate VMs continuously, test in the cloud, then cut over with minimal downtime.
- Database migration. Move databases (same engine or a different one) with continuous replication.
- Data transfer. Move bulk files and object data, online or by shipping a device.
Before any of that, you need a landing zone (accounts or subscriptions, networking, identity, guardrails) to migrate into. See the identity and governance and networking posts.
The 6 Rs, briefly
Not every workload should be lifted and shifted. The common framework sorts each application into one of:
| Strategy | What it means | Typical tooling |
|---|---|---|
| Rehost | Move VMs as they are | Server migration services |
| Replatform | Small changes, e.g. move the database to a managed service | DMS, managed DBs |
| Refactor | Re-architect for cloud-native services | Containers, serverless |
| Repurchase | Replace with SaaS | — |
| Retire | Switch it off | — |
| Retain | Leave it where it is, for now | — |
In practice, most large migrations rehost the majority for speed, replatform databases where it’s easy, and refactor selectively later. Retiring is underrated. Discovery usually finds a surprising number of servers nobody uses.
Discovery and assessment
Discovery tools scan your environment (usually agentless for VMware and Hyper-V), collect performance data over a few weeks, map network dependencies between servers, and produce right-sized target recommendations with cost estimates. That data drives two decisions: what moves together (dependency groups become migration waves) and what it will cost (right-sized, not one-for-one).
Run discovery for at least two to four weeks to capture month-end and batch peaks. A one-week snapshot will undersize the servers that matter most.
AWS Transform and Migration Evaluator
AWS Transform uses AI agents to discover and assess VMware estates, plan migration waves and convert network configurations. AWS Migration Evaluator builds the business case and right-sized cost estimate from discovered usage.
Agentless discovery of VMware, Hyper-V and physical servers, dependency mapping, readiness and right-sized cost assessments for VMs, SQL Server and web apps, and business-case reports, all in one hub.
Migration Center
Discovers on-premises and other-cloud assets, estimates Google Cloud costs and total cost of ownership, and plans migration waves, linking into Migrate to Virtual Machines for execution.
Server migration (lift and shift)
Server migration services replicate disks continuously from source to cloud while the source keeps running. You can launch test copies as often as you like without affecting production, and the final cutover is a short window: stop the source, sync the last changes, start in the cloud, switch DNS.
AWS Application Migration Service Soon
Block-level continuous replication of physical, virtual or cloud servers into a staging area, then non-disruptive test launches and a short cutover to EC2. The recommended rehost tool on AWS.
Azure Migrate’s server migration replicates VMware, Hyper-V and physical servers (agentless for VMware and Hyper-V) to Azure VMs, with test migrations and orchestrated cutover.
Migrate to Virtual Machines Soon
Streams VMs from VMware, AWS EC2 and Azure into Compute Engine with test clones, waves and quick cutover. VMs can start running in the cloud before all data has moved.
The migrating VMs post and common migration issues go deeper on the Azure side.
Test the cutover, not just the replication. Do at least one full rehearsal per wave: DNS change, app smoke tests, rollback. The runbook you write during the rehearsal is what gets you through the real weekend.
Database migration
Databases are usually the hardest part. The data is large, it changes constantly, and downtime is expensive. Database migration services do an initial full load, then continuous change data capture to keep the target in sync until you’re ready to switch.
Homogeneous migrations (SQL Server to Azure SQL, MySQL to Cloud SQL) are mostly mechanical. Heterogeneous ones (Oracle to PostgreSQL) need schema and code conversion, where stored procedures and engine-specific features dominate the effort. The conversion tools, now increasingly AI-assisted, get you most of the way, but plan for manual work and thorough testing.
AWS Database Migration Service Soon
Homogeneous and heterogeneous migrations with continuous replication (CDC) to keep the source live until cutover. DMS Schema Conversion and the Schema Conversion Tool translate schemas and code between engines, for example Oracle to PostgreSQL.
Online and offline migrations of SQL Server to Azure SQL Database, SQL Managed Instance or SQL Server on VMs, integrated with the Azure SQL Migration extension. Azure Database for PostgreSQL and MySQL have their own migration services.
Database Migration Service Soon
Serverless continuous migrations from MySQL, PostgreSQL, SQL Server and Oracle into Cloud SQL and AlloyDB, with conversion workspaces (Gemini-assisted) for Oracle to PostgreSQL schemas and code.
See also the migrating data post and the database services post for choosing targets.
Bulk and offline data transfer
For file shares, archives and data lakes, online transfer services move data over the network with scheduling, incremental sync and integrity checks. When the dataset is huge and bandwidth is limited, shipping a device can still be faster. As a rough guide, 100 TB over a 1 Gbps link takes well over a week even at full utilisation.
AWS DataSync and Data Transfer Terminal
DataSync moves data online from NFS, SMB, HDFS and object stores into S3, EFS or FSx with scheduling and verification. AWS no longer offers Snow Family devices to new customers; for physical transfer it points to Data Transfer Terminal locations and partners.
Microsoft ships rugged appliances (Data Box and Data Box Disk) for offline transfer of terabytes to petabytes into Azure Storage. Azure Storage Mover and AzCopy cover online transfers.
Storage Transfer Service and Transfer Appliance
Storage Transfer Service moves data online from other clouds, HTTP sources and on-premises file systems into Cloud Storage. Transfer Appliance is Google’s shippable device for offline bulk transfer.
AWS no longer offers Snowball or other Snow Family devices to new customers. Use DataSync for online transfers, and Data Transfer Terminal or partners for physical moves.
Comparing the providers
- Azure Migrate is the most integrated hub, with one place for discovery, assessment, business case and migration of servers, databases and web apps. It’s a natural fit for VMware, Hyper-V and SQL Server estates.
- AWS has a deep toolset (Application Migration Service, DMS with schema conversion, AWS Transform for VMware) and extensive migration funding programmes through partners.
- Google Cloud offers Migration Center plus Migrate to Virtual Machines and DMS, with good support for migrating from other clouds as well as on-premises.
All three run funding and partner programmes for large migrations. Ask your account team before you start, because the credits can be significant.
Common pitfalls
- Skipping the landing zone. Migrating into a single flat subscription or account creates a mess you’ll re-migrate later.
- One-to-one sizing. Copying on-premises specs over-provisions most workloads. Use performance-based sizing, then right-size after a month in the cloud.
- Ignoring dependencies. Moving one half of a chatty application pair adds latency and egress across the hybrid link. Migrate dependency groups together.
- Licensing surprises. Windows, SQL Server and Oracle licensing differs in the cloud. Check bring-your-own-licence rules and Azure Hybrid Benefit before you size.
- No post-migration optimisation. Lift and shift is a starting point. Schedule right-sizing, commitments and modernisation as part of the programme, not “later”.
Conclusion
A successful migration is mostly planning: discover thoroughly, group by dependency, prepare a landing zone, rehearse every cutover, and optimise once you’ve landed. The native tools on each cloud handle the mechanics well and cost little or nothing. The difference comes from how disciplined the programme is. A practical first step: run the provider’s discovery tool for a month against one data centre, and you’ll have the inventory, dependency map and cost estimate to plan from. All the services side by side are in the Migration comparison.