Migration-tooling parity — Migration Center, Migrate to VMs, DMS and Storage Transfer against the AWS and Azure equivalents
Counterpart names for the migration tooling itself, then what the differences mean for a project: the Google Cloud tools accept the other clouds as first-class sources, the heterogeneous database paths are documented, and the cost that no tool on any cloud covers is the one that dominates.
markdownguidev1W711-KZGCstage: designtrust: officialfamily: migrationservice: migration-centerinterface: anymigration tooling paritymigration centerazure migrateAWS application discovery servicemigrate to virtual machinesAWS application migration serviceazure migrate server migrationdatabase migration serviceAWS DMSazure database migration servicestorage transfer serviceDataSyncazure storage mover
Migration-tooling parity
1. The names
| Job | Google Cloud | AWS | Azure |
|---|---|---|---|
| discovery and assessment | Migration Center | Application Discovery Service, Migration Hub | Azure Migrate |
| VM migration | Migrate to Virtual Machines | Application Migration Service (MGN) | Azure Migrate: server migration tool |
| app-to-container | Migrate for Anthos | App2Container | Azure Migrate: app containerization tool |
| database migration | Database Migration Service | AWS DMS | Azure Database Migration Service |
| bulk data transfer (online) | Storage Transfer Service | DataSync | Azure Storage Mover, AzCopy |
| bulk data transfer (offline) | Transfer Appliance | Snow family | Data Box, Import/Export |
| VMware estates | Google Cloud VMware Engine | VMware Cloud on AWS | Azure VMware Solution |
| the programme wrapper | RAMP | AWS Migration Acceleration Program | Azure Accelerate |
| backup and DR | Backup and DR Service | AWS Backup | Azure Backup |
The three clouds have converged on the same tool categories, which is good news: an assessment done for one target is mostly reusable for another, because the inputs are the same (inventory, utilisation, dependencies). That is the practical basis for comparing targets rather than committing to one.
2. The assessment tools all accept "another cloud" — so use the destination's tool
Migration Center covers "your current on-premises or other cloud environments". Azure Migrate and AWS's discovery tooling make the equivalent claim.
**So run the assessment with the tool of the cloud you are assessing into.** It is the one that prices its own services, applies its own technical-fit analysis, and recommends its own products. Running two assessments — one per candidate target — is a legitimate and inexpensive way to compare two destinations with the same inventory, and it is what the owner's use case asks for.
What no assessment tool does is tell you what changes. That is the other nine parity guides, and it is where the schedule lives rather than the cost.
3. VM migration: the sources are the point
Migrate to Virtual Machines takes vSphere, AWS, Azure and Google Cloud VMware Engine as sources. AWS's and Azure's equivalents likewise accept the other clouds.
| Google Cloud | AWS | Azure | |
|---|---|---|---|
| cross-cloud source support | yes — AWS and Azure named | yes | yes |
| the control/receive split | host project and target project | account and Region | subscription and resource group |
| target | Compute Engine VMs, Persistent Disk volumes | EC2 and EBS | Azure VMs and managed disks |
The estimate line that is the same in all directions: a lift-and-shift is the cheapest migration and the most expensive destination. The estate arrives with its source sizing and source operating model, and the re-platforming — onto Cloud Run, GKE, a managed database — is a named follow-on project, not an implied one. Put it in the plan as its own line in every direction.
4. Database migration: Google Cloud's heterogeneous paths are documented, and that is a strategy
| Path | Google Cloud |
|---|---|
| same-engine | MySQL, PostgreSQL and SQL Server to Cloud SQL; PostgreSQL to AlloyDB |
| cross-engine | Oracle → Cloud SQL for PostgreSQL; Oracle → AlloyDB; SQL Server → Cloud SQL for PostgreSQL; SQL Server → AlloyDB |
AWS DMS and Azure Database Migration Service both do heterogeneous migrations too (AWS pairs DMS with the Schema Conversion Tool). So the capability is not unique — but the documented destination set is worth reading carefully, because it tells you which modernisations the vendor has committed to supporting.
The strategic row: "migrate" and "leave the commercial licence behind" can be one project. The licence
saving frequently funds the migration. And the honest counterweight, which belongs in the same paragraph: the
data movement is the solved part, and the schema, stored procedures and application data-access code are not
(reference/migration/database-migration-service.md §4).
5. Object and file transfer
Storage Transfer Service takes Amazon S3 and S3-compatible storage, Azure Blob Storage, HTTP lists, Cloud Storage, and on-premises POSIX and HDFS — with event-driven transfers from Cloud Storage, S3 and Azure Blob / ADLS Gen2.
Event-driven from the other two clouds is the feature that shortens a cut-over: bulk-copy on a schedule, then let new writes arrive by event until the switch. DataSync and Azure Storage Mover occupy the same role in the other directions.
Two things to size, and they are the same on every cloud: the agent fleet and its bandwidth limit for file
systems, and the destination storage class, whose minimum duration starts on arrival — ARCHIVE commits
365 days on Google Cloud (reference/storage/cloud-storage.md §1).
6. Pricing dimension (never a price)
| Google Cloud | AWS | Azure | |
|---|---|---|---|
| assessment | the assessment tooling is generally free; you pay for what it discovers | same shape | same shape |
| VM migration | the service, plus the target resources once running | same shape | same shape |
| database migration | the service, plus the target instance | same shape | same shape |
| data transfer | the service, plus source-side egress | same shape | same shape |
And the line that no tool on any cloud covers, in any direction: the source cloud's egress. It is billed
by the cloud you are leaving, it does not appear in the destination's calculator, and on a large estate it can
exceed a year of the destination's storage bill. Raise it in the first conversation, size it from the actual
byte count, and sequence the waves so each dataset moves once
(guides/parity-and-migration-method.md).
7. What this guide cannot tell you
Whether the application works afterwards. Every tool here moves infrastructure or data; none of them validates
behaviour. The observability baseline in guides/migration/assess-before-you-move.md step 6 is what makes
"afterwards" a measurable question rather than an argument.