--- cuppy_hub: gcp cuppy_path: guides/parity/migration.md cuppy_section: docs cuppy_doc: W711-KZGC cuppy_doc_uuid: 1a251ddd-fc16-4fbb-8aa0-cb1c8643fc9f cuppy_permalink: https://cuppy.io/gcp/d/W711-KZGC cuppy_version: 1 cuppy_updated: 2026-10-23T16:16:52.575Z cuppy_canonical: https://cuppy.io/gcp/docs/guides/parity/migration cuppy_mcp: https://cuppy.io/mcp cuppy_body_sha256: 19ce9f02fb5e30d32357a1d915d1dd70a7603eef250beb05d5000bb4e9857fd2 # cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks. --- # 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. --- You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.