Architecture, Migration and Multicloud

This content was generated with the assistance of AI and should be verified against the official documentation before being relied on in production.

See the section bibliography for the reference material consulted while preparing these pages.

Commands on this page target the gcloud CLI 586.x line (command groups migration-center, migration vms, database-migration, transfer and container fleet) and the Google Cloud documentation, Architecture Center and release notes re-read on 2026-10-01. This is the part of Google Cloud where products are renamed and merged most often (Anthos is the best-known example), so check the product release notes and deprecations pages linked in References before committing a plan to a specific tool. The placeholders my-project-id, <project-number> and the billing account 000000-000000-000000 are not real; replace them with your own.

Earlier pages in this section build individual services. This page steps back to the questions that decide whether and how a workload such as Bookshelf should run on Google Cloud at all: how to judge a design (the Well-Architected Framework and the Architecture Center), how an organization plans its move (the Cloud Adoption Framework), how existing servers, databases and files get in (Migration Center, Migrate to Virtual Machines, Database Migration Service, Storage Transfer Service), and what to do with systems that cannot leave or must run on several clouds (fleets, attached clusters, Google Distributed Cloud). Picking a compute service for something already destined for Google Cloud is covered in Choosing a Compute Service; what a design costs is covered in Cost Management and Billing; the same topic on the other clouds is in Architecture, Migration, Hybrid and Disaster Recovery and Architecture, Migration and Hybrid Cloud. For the vendor-neutral side (when to start from scratch versus migrate, and the migration patterns themselves) read Starting a New Project: Which Path and Which Technologies and Migration Overview: How to Approach Any Migration.

export PROJECT_ID=$(gcloud config get-value project)
export REGION=us-central1
gcloud services enable migrationcenter.googleapis.com vmmigration.googleapis.com \
  datamigration.googleapis.com storagetransfer.googleapis.com gkehub.googleapis.com \
  gkemulticloud.googleapis.com connectgateway.googleapis.com

Reference: gcloud services enable

The Well-Architected Framework

The Google Cloud Well-Architected Framework is Google’s set of recommendations for designing and operating workloads. It is organised in six pillars:

Pillar Workload concern

Operational excellence

Deploying, operating, monitoring and managing workloads efficiently: automation, observability, incident management, continuous improvement. See Monitoring and Observability and Infrastructure as Code.

Security, privacy and compliance

Protecting data and systems, designing for privacy and meeting regulatory requirements: least privilege, defence in depth, encryption, org policies. See Identity and Access, Secret Manager and Cloud KMS and Governance, Security and Compliance.

Reliability

Resilient, highly available workloads: regional and multi-regional design, failure domains, graceful degradation, backups and recovery. See Google Cloud Global Infrastructure; disaster recovery is discussed below.

Cost optimization

Maximizing business value for the spend: rightsizing, committed-use discounts, labels, budgets. See Cost Management and Billing.

Performance optimization

Designing and tuning resources for the required performance: choosing machine families, caching, CDN, database engines. See Choosing a Compute Service.

Sustainability

Building environmentally sustainable workloads: region selection by carbon footprint, utilization, managed and serverless services, data lifecycle.

Older guides describe five pillars, a "system design" category or a differently ordered list; the framework has been reorganised more than once, so treat the pillar list on the official page as the source of truth. In addition to the pillars the framework publishes cross-pillar perspectives that add technology- or industry-specific advice (AI and ML workloads, financial services). Every pillar involves trade-offs: multi-region active/active buys reliability with cost and complexity, so the framework is a lens applied repeatedly, not a checklist to maximise or a one-time gate.

Review a workload

Google Cloud has no mandatory review service comparable to the AWS Well-Architected Tool. Reviews are run as a conversation against the pillar guides, optionally supported by tooling:

  • Active Assist (Recommender) produces cost, security, performance, reliability and sustainability recommendations from the real environment, shown in the console and available through the API and CLI.

  • Cloud Hub / Application Design Center and App Hub group the resources of an application so that health, cost and recommendations can be read per application instead of per project.

  • Gemini Cloud Assist can answer architecture and troubleshooting questions in the console (check its launch stage before relying on it; it was in Preview at the time of writing).

In the Google Cloud console

  1. Open the project picker and select the Bookshelf project.

  2. Open the navigation menu, then Recommendations (Active Assist) under the Home or IAM & Admin areas, depending on your layout; use the search bar and type Recommendation Hub if you cannot find it.

  3. Filter by category (Cost, Security, Performance, Reliability, Sustainability) and review each recommendation’s impact before applying it.

  4. Compare the findings with the matching pillar guide in the Architecture Center.

With the gcloud CLI

gcloud services enable recommender.googleapis.com

# Idle VM recommendations for the project (cost pillar)
gcloud recommender recommendations list \
  --project="$PROJECT_ID" --location=us-central1-a \
  --recommender=google.compute.instance.IdleResourceRecommender \
  --format="table(name.basename(),primaryImpact.category,stateInfo.state)"

# Which recommenders exist
gcloud recommender recommenders list --format="value(name)" | head

Reference: gcloud recommender recommendations list

The Architecture Center

The Architecture Center (docs.cloud.google.com/architecture) is the hub for reference architectures, design guides and decision aids. It is the right place to start when the question is "how do others build this on Google Cloud": it has reference architectures per workload (web apps on Cloud Run or GKE, data analytics, ML, hybrid and multicloud), landing-zone guidance, and the framework pillar guides. The Bookshelf layout used throughout this section is a small example of the same idea; see the final architecture in Google Cloud.

The Cloud Adoption Framework

The Google Cloud Adoption Framework is the organizational counterpart of the technical framework. It looks at readiness along four themes: Learn (skills and training), Lead (executive sponsorship and cross-functional teams), Scale (how much operations and delivery are automated and standardized) and Secure (the protection of the platform). Teams self-assess each theme and use the result to decide what to fix before, not after, the first production migration.

The technical outcome of adoption planning is usually a landing zone: the resource hierarchy, networking, identity and logging baseline that workloads are placed into. The pieces are covered earlier in this section:

Google publishes an enterprise foundations blueprint and Terraform modules that implement such a landing zone; pair them with Infrastructure as Code.

Migrating to Google Cloud

Google describes a migration as four phases: assess (discover and size what you have), plan (build the foundation and choose a strategy per workload), deploy (move the workloads) and optimize (tune after the move). The strategies per workload follow the familiar ladder from least to most change:

Strategy What changes Typical Google Cloud destination for Bookshelf

Rehost (lift and shift)

Nothing in the application; the server is replicated as a VM.

Compute Engine via Migrate to Virtual Machines.

Replatform (move and improve)

Small changes to use managed services: a managed database, a container instead of a VM.

Cloud SQL or AlloyDB via Database Migration Service; Cloud Run or GKE via Migrate to Containers.

Refactor / rebuild

The application is redesigned for cloud-native services.

Cloud Run, GKE, Pub/Sub, Spanner; see Choosing a Compute Service.

Retire or retain

The workload is switched off, or stays where it is.

Nothing, or hybrid connectivity (see Hybrid and multicloud).

The vendor-neutral reasoning about which strategy suits a system, including the strangler-fig and branch-by-abstraction patterns, is in Migration Overview: How to Approach Any Migration, Migration Path: From a Legacy Stack to a Modern One and Migration Path: From a Monolith to Microservices. If there is nothing to migrate and the project is greenfield, read Starting a New Project: Which Path and Which Technologies first and come back for the landing zone.

flowchart TD A[Inventory with Migration Center] --> B{Workload type} B -->|VM or server| C{Change the app?} B -->|Database| D[Database Migration Service] B -->|Files and objects| E[Storage Transfer Service or Transfer Appliance] C -->|No| F[Migrate to Virtual Machines] C -->|Containerize| G[Migrate to Containers] C -->|Rebuild| H[Cloud Run or GKE] F --> I[Compute Engine] G --> J[GKE or Cloud Run] D --> K[Cloud SQL or AlloyDB] E --> L[Cloud Storage] H --> M[Optimize and operate] I --> M J --> M K --> M L --> M

Migration tools at a glance

Tool Use it for Notes

Migration Center

Discovering servers, databases and their dependencies, assessing fit, estimating TCO, grouping assets into waves.

Free to use; the first step. Collects data with a discovery client or manual uploads.

Migrate to Virtual Machines

Replicating VMware, AWS EC2, Azure and other VMs to Compute Engine with minimal downtime (test clone, then cutover).

Formerly Migrate for Compute Engine. Charges apply per migrated source for a limited period; check the pricing page.

Migrate to Containers

Converting suitable workloads (Linux VMs, some Windows) into containers for GKE or Cloud Run.

Assess fit first (the fit assessment tool); not every workload is a candidate.

Database Migration Service

Moving MySQL, PostgreSQL, SQL Server, Oracle and others to Cloud SQL or AlloyDB, one-time or continuous (CDC).

Homogeneous moves are the simplest; Oracle to PostgreSQL adds conversion workspaces.

Storage Transfer Service

Online copy from Amazon S3, Azure Blob Storage, HTTP lists, file systems and other buckets into Cloud Storage.

Managed, scheduled, parallel; see Cloud Storage.

Transfer Appliance

Offline shipment of very large datasets (hundreds of terabytes) when bandwidth is the limit.

Ordered in the console; compute the time to transfer over the network first.

Migration Center

Migration Center is the unified place to start. It collects an inventory of servers, databases and (from cloud sources) other assets, shows their dependencies, runs an assessment against Google Cloud targets (rehost to Compute Engine, replatform to managed databases or containers), produces a total cost of ownership report from the preference sets you choose (target region, committed-use discount level, sizing strategy), and lets you create groups of assets that move together. Data comes from the Migration Center discovery client (installed on or beside the environment to scan), from imports of CSV or exported inventories (including from VMware or AWS), or from the API. The service is free; the assets it recommends are billed when you create them.

In the Google Cloud console

  1. Select the project that will hold the inventory (a dedicated project, for example bookshelf-migration, keeps it separate from workloads).

  2. Open the navigation menu, then Migration Center (search for it if needed), and choose Enable API when prompted.

  3. Under Discovery, choose Add sources and pick one: Discovery client, Import file or a cloud/VMware source.

  4. After data arrives, open Assets to review servers and databases, then Groups to create a Bookshelf group (for example the on-premises catalog-db server and the catalog-app server).

  5. Under Preferences, create a preference set (region us-central1, sizing strategy, discount level).

  6. Under Reports, generate a report for the group and preference set; open it to see target machine types, monthly cost estimate and migration-friendliness per asset.

With the gcloud CLI

gcloud migration-center sources create onprem-inventory \
  --project="$PROJECT_ID" --location="$REGION" \
  --display-name="On-premises inventory" \
  --description="Servers discovered by the discovery client"

gcloud migration-center sources list --project="$PROJECT_ID" --location="$REGION"

gcloud migration-center groups create bookshelf-group \
  --project="$PROJECT_ID" --location="$REGION" \
  --display-name="Bookshelf wave 1"

gcloud migration-center assets list --project="$PROJECT_ID" --location="$REGION" \
  --format="table(name.basename(),machineDetails.coreCount,machineDetails.memoryMb)"

Reference: gcloud migration-center reference

Report generation and the discovery client download are easiest in the console; the CLI is for scripting source and group management.

Migrating servers with Migrate to Virtual Machines

Migrate to Virtual Machines (also called Migrate for Compute Engine in older material) replicates a running VM to Google Cloud without a long outage. It uses a source (a vCenter, an AWS account, an Azure subscription or a Google Cloud VMware Engine private cloud), and per VM a migration that moves through these states:

  1. Replicate: an initial full copy of the disks into Google Cloud, followed by periodic delta cycles that keep the copy current while the source keeps running.

  2. Test clone: a throwaway VM created from the replica to prove that the workload boots and works, without touching the source or the replication.

  3. Cutover: a final delta, the source is stopped (optionally), and the VM is created on Compute Engine; then the migration is finalized to release the replication resources.

The VM lands in a target project with a target network and subnet, so the landing zone from the previous section needs to exist first; on-premises sources also need hybrid connectivity such as HA VPN or Interconnect (see VPN and Hybrid Connectivity). After cutover the VM is an ordinary Compute Engine instance; read Compute Engine to harden and operate it.

Related tool: Migrate to Containers analyses a VM with a fit assessment and generates container images and Kubernetes manifests for GKE or Cloud Run. It suits stateless, well-behaved Linux workloads; applications with complex state or kernel dependencies are usually better rehosted or rewritten.

In the Google Cloud console

  1. Open Migrate to Virtual Machines from the navigation menu (search VM Migration) and enable the API if asked.

  2. On the Sources tab choose Add source, pick the type (VMware, AWS or Azure) and follow the wizard, which lists the prerequisites (a connector appliance or an access role in the source cloud).

  3. On the Migrations tab choose Create migration, select the source VMs and set the target: project, region, zone, machine type, network and subnet, and service account.

  4. Start replication and wait for the first cycle to complete.

  5. Choose Test clone, connect to the clone, validate, then delete the clone.

  6. Choose Cutover in a maintenance window; after verifying the migrated VM choose Finalize.

With the gcloud CLI

gcloud migration vms sources list --project="$PROJECT_ID" --location="$REGION"

gcloud migration vms migrating-vms list \
  --project="$PROJECT_ID" --location="$REGION" --source=onprem-vcenter \
  --format="table(name.basename(),currentSyncInfo.state,state)"

gcloud migration vms migrating-vms describe catalog-app \
  --project="$PROJECT_ID" --location="$REGION" --source=onprem-vcenter

Reference: gcloud migration vms reference

The create, test-clone and cutover operations are available as further subcommands of the same group; the console wizard is the practical route for the first migrations because it validates the source connection. Run gcloud migration vms --help for the exact list in your gcloud version.

Migrating databases with Database Migration Service

Database Migration Service (DMS) moves databases to Cloud SQL and AlloyDB with minimal downtime. The core pieces are the same for every engine:

  • A connection profile describes a source (host, port, user) or destination.

  • A migration job ties a source profile to a destination instance and a type: one-time (a dump and load) or continuous (initial snapshot followed by change data capture until you promote).

  • Connectivity between DMS and the source: an IP allowlist, a reverse SSH tunnel, VPC peering or Private Service Connect, with HA VPN or Interconnect for on-premises sources (see VPC Networking on Google Cloud).

  • Promote stops replication and makes the destination the primary database; applications are then pointed at it.

Supported sources include MySQL, PostgreSQL, SQL Server and Oracle (heterogeneous Oracle to PostgreSQL migrations use a conversion workspace that converts schema and code), plus other clouds' managed databases. For the destinations and how to size them read Cloud SQL and AlloyDB for PostgreSQL; MongoDB data is migrated with the tools described in MongoDB on Google Cloud instead. The engine-specific tuning needed before cutover (replication prerequisites, extensions, sequences) is in the database sections of this site, for example SQL Reference.

The flow for Bookshelf, moving a self-managed PostgreSQL catalog database to bookshelf-catalog, is:

sequenceDiagram participant S as Source PostgreSQL participant D as Database Migration Service participant T as Cloud SQL bookshelf-catalog participant A as catalog-api D->>S: Connect with source connection profile D->>T: Create destination instance S->>T: Initial snapshot S-->>T: Continuous change stream Note over S,T: Validate row counts, run test queries A->>S: Writes stopped for cutover D->>T: Promote A->>T: Connection string switched

In the Google Cloud console

  1. Enable Database Migration API, then open Database Migration from the navigation menu.

  2. Under Connection profiles choose Create profile, role Source, engine PostgreSQL; enter the host, port, username and password of a replication-capable user, and the region of the migration. Store the password in Secret Manager (see Secret Manager and Cloud KMS) rather than in notes or tickets.

  3. Under Migration jobs choose Create migration job; name it catalog-to-cloudsql, choose the source engine and the destination region, and select migration type Continuous.

  4. Choose the source profile, then define the destination Cloud SQL instance (ID bookshelf-catalog, edition, version, machine type, storage) or select an existing one.

  5. Pick the connectivity method and follow the prerequisite instructions the wizard prints (for example the wal_level and max_replication_slots settings and an allowed IP on the source).

  6. Choose Test job; fix any failed check; then choose Create and start job.

  7. Monitor Replication delay until it is near zero, stop writes at the source, and choose Promote.

With the gcloud CLI

# Source connection profile (password is prompted for, never put on the command line)
gcloud database-migration connection-profiles create postgresql source-catalog \
  --region="$REGION" \
  --host=203.0.113.10 --port=5432 \
  --username=migration_user --prompt-for-password \
  --display-name="Self-managed catalog"

# Continuous migration job using an IP allowlist; the destination instance is created by DMS
gcloud database-migration migration-jobs create postgresql catalog-to-cloudsql \
  --region="$REGION" --type=CONTINUOUS \
  --source=source-catalog \
  --destination-id=bookshelf-catalog \
  --display-name="Catalog to Cloud SQL"

gcloud database-migration migration-jobs verify catalog-to-cloudsql --region="$REGION"
gcloud database-migration migration-jobs start catalog-to-cloudsql --region="$REGION"
gcloud database-migration migration-jobs describe catalog-to-cloudsql --region="$REGION" \
  --format="value(state,phase)"

# After writes are stopped on the source and replication delay is zero
gcloud database-migration migration-jobs promote catalog-to-cloudsql --region="$REGION"

Reference: gcloud database-migration reference, DMS for PostgreSQL quickstart. The documentation example address 203.0.113.10 is a reserved documentation range, not a real host; flag names for destination and connectivity options differ per engine, so check gcloud database-migration migration-jobs create postgresql --help.

Moving data with Storage Transfer Service and Transfer Appliance

For files and objects, Storage Transfer Service is the managed, scheduled, parallel copy tool. Sources include Amazon S3, Azure Blob Storage, other Cloud Storage buckets, publicly reachable URL lists and on-premises file systems (through transfer agents). It verifies checksums, supports include and exclude prefixes, bandwidth limits and delete-after-transfer, and is the supported replacement for ad hoc copying scripts. Small and medium sets can also use gcloud storage cp or rsync (older guides still show gsutil, which is legacy and will stop shipping with the gcloud CLI after March 2027; see Cloud Storage).

Transfer Appliance is a rack or portable storage device that Google ships to you. It makes sense when the dataset is so large, or the network so slow, that online transfer would take weeks; compute the time first (dataset size divided by sustained bandwidth).

In the Google Cloud console

  1. Open Storage Transfer Service (search the navigation menu), enable the API, and choose Create transfer job.

  2. Choose the source type (for example Amazon S3), enter the bucket and provide credentials through the supported method (an access role or federation is preferable to a long-lived key); choose the destination bucket bookshelf-uploads-$PROJECT_ID.

  3. Choose a schedule (one time, or repeating) and the overwrite and delete options; choose Create.

  4. Open the job to follow bytes and objects transferred, and failures.

With the gcloud CLI

export BUCKET=bookshelf-uploads-$PROJECT_ID

# S3 to Cloud Storage; credentials come from an AWS credentials file, never inline
gcloud transfer jobs create s3://legacy-bookshelf-uploads gs://$BUCKET \
  --source-creds-file=aws-creds.json \
  --description="Copy legacy uploads" \
  --overwrite-when=different

gcloud transfer jobs list --format="table(name,status,description)"
gcloud transfer operations list --job-names=transferJobs/<job-id>

Reference: gcloud transfer jobs create

Keep the credentials file out of version control; for AWS sources the Storage Transfer Service documentation also describes federated identity, which avoids storing a key at all.

Hybrid and multicloud

Not everything moves. Reasons to keep some workloads outside Google Cloud include data residency, latency to factory or retail sites, licences tied to hardware, and deliberate use of more than one provider. Google Cloud’s offerings fall into three groups.

Capability What it is Use it for

GKE fleets and attached clusters

A fleet is a logical group of Kubernetes clusters registered with Google Cloud so that policies, configuration and identity are managed centrally. Attached clusters let you register clusters that run on other clouds (EKS, AKS) or on-premises conformant distributions.

One control plane for policy, observability and workload identity across clouds. Formerly marketed as part of Anthos.

Google Distributed Cloud (GDC)

Google-managed or Google-supported infrastructure and software running in your data center or at the edge: GDC connected (Google-provided hardware), GDC software-only (clusters on your VMware or bare-metal servers, formerly Anthos clusters on VMware and bare metal), and GDC air-gapped for disconnected environments.

Data sovereignty, low latency, regulated sites, disconnected operation.

Google Cloud VMware Engine

A dedicated VMware environment (vSphere, vSAN, NSX) running in Google Cloud data centers.

Moving VMware estates quickly without re-platforming, then modernizing gradually.

BigQuery Omni

BigQuery queries that run against data stored in Amazon S3 or Azure Blob Storage, without moving the data.

Analytics over multicloud data; see AI, Data and Analytics Overview.

Cross-Cloud Interconnect and HA VPN

Private high-bandwidth links to AWS, Azure or Oracle Cloud, or encrypted tunnels over the internet.

The network layer under any of the above; see VPN and Hybrid Connectivity.

Anthos, GKE Enterprise and the current names

Anthos was Google’s brand for hybrid and multicloud Kubernetes; it was renamed GKE Enterprise in 2023, and the Enterprise edition was subsequently folded into the standard GKE offering with fleet features available as separate, individually priced capabilities (this repackaging has changed more than once, so re-read the GKE pricing and release-notes pages before planning a budget). When an older article says "Anthos", read it as follows:

Older name Current concept

Anthos clusters on VMware / bare metal

Google Distributed Cloud software-only clusters

Anthos clusters on AWS / Azure

Attached clusters (EKS, AKS) registered to a fleet; the standalone multicloud products were retired in favour of attaching existing clusters

Anthos Config Management

Config Sync and Policy Controller within a fleet

Anthos Service Mesh

Cloud Service Mesh

Cloud Run for Anthos

Knative serving on a registered cluster; for serverless on Google Cloud itself use Cloud Run (Cloud Run)

Older guides that describe a cluster-based Cloud Run ("Cloud Run for Anthos") are outdated: today the practical choices are fully managed Cloud Run, or Knative on a cluster you run yourself.

Kubernetes-level mechanics (manifests, Gateway API, workload identity) are the same wherever the cluster runs; they are covered in GKE Clusters and Deploying Microservices on GKE, and the platform-neutral material is in Kubernetes and OpenShift.

Register a cluster in a fleet

In the Google Cloud console

  1. Enable GKE Hub, Connect gateway and, for attached clusters, GKE Multi-Cloud APIs.

  2. Open Kubernetes Engine, then Fleet (also reachable through the Clusters page, Fleet tab).

  3. Choose Register cluster. GKE clusters in the project register with one click; for another cloud, choose Attached cluster and follow the wizard (platform version, OIDC issuer URL, admin users).

  4. Open Features to enable fleet-wide capabilities such as Config Sync, Policy Controller or Cloud Service Mesh.

With the gcloud CLI

# Register the Bookshelf GKE Autopilot cluster in the fleet
gcloud container clusters update bookshelf-gke --region="$REGION" \
  --fleet-project="$PROJECT_ID"

gcloud container fleet memberships list --project="$PROJECT_ID"

# Attach an EKS cluster (placeholders; the cluster must expose a public OIDC issuer)
gcloud container attached clusters register eks-bookshelf \
  --project="$PROJECT_ID" --location="$REGION" \
  --fleet-project="$PROJECT_ID" \
  --platform-version=1.35.0-gke.1 \
  --distribution=eks \
  --context=eks-bookshelf-context \
  --issuer-url=https://oidc.eks.us-east-1.amazonaws.com/id/EXAMPLE0000 \
  --admin-users=admin@example.com

# Cluster access through the Connect gateway, without exposing the API server
gcloud container fleet memberships get-credentials eks-bookshelf --project="$PROJECT_ID"

Reference: gcloud container fleet memberships, gcloud container attached clusters register

The platform version, issuer and distribution values above are examples; take the supported values for the current release from gcloud container attached get-server-config --location="$REGION".

A pragmatic multicloud stance

Running the same workload actively on two clouds is expensive and rarely pays back: managed services (Cloud SQL, Pub/Sub, Spanner) differ in behaviour and APIs, and the lowest common denominator is a self-managed stack. More defensible multicloud patterns are:

  • Portability by standards: containers, Kubernetes, PostgreSQL, OpenTelemetry and Terraform, so a later move is possible without a rewrite (see Infrastructure as Code).

  • Best of breed per workload: analytics on BigQuery or Omni, transactional systems elsewhere.

  • Central governance across clouds: fleet policy, one identity provider federated with each cloud, one observability pipeline.

  • Exit plans, not mirrors: a documented and tested way out instead of permanent duplication.

Disaster recovery on Google Cloud

Disaster recovery is the part of reliability that decides how much data you can lose (RPO) and how long recovery takes (RTO). The usual strategies map onto Google Cloud as follows.

Strategy How it works Bookshelf building blocks

Backup and restore

Back up regularly to another region; restore after a disaster.

Cloud SQL automated backups and cross-region replicas, Cloud Storage dual-region or multi-region buckets, Backup and DR Service.

Pilot light

A minimal copy of the data layer always runs in a second region; compute is created on demand.

A cross-region Cloud SQL replica, container images in a multi-region Artifact Registry, Terraform ready to deploy Cloud Run.

Warm standby

A scaled-down but functional stack runs in a second region.

Cloud Run in two regions behind one global external Application Load Balancer; replica promoted on failover.

Active-active

Two or more regions serve traffic at all times.

Global load balancing with multi-region Spanner or Firestore; costs and complexity are highest.

Many Google Cloud services are regional or multi-regional by design (see Google Cloud Global Infrastructure for the scopes), so a regional zonal failure is usually survivable without extra work; a region-wide failure needs the strategies above. Backup and DR Service is the managed vault-style service for VMs, databases and file systems. Test the plan: a recovery procedure that was never run is a hypothesis.

With the gcloud CLI

# Cross-region read replica of the Bookshelf catalog database (pilot light)
gcloud sql instances create bookshelf-catalog-replica \
  --master-instance-name=bookshelf-catalog \
  --region=us-east1

# Failover test: promote the replica (this breaks replication)
gcloud sql instances promote-replica bookshelf-catalog-replica

Reference: Cross-region replicas for Cloud SQL

Promotion is a one-way operation; run the drill against a clone or a non-production copy, as described in Cloud SQL.

Coming from Azure or AWS

Google Cloud publishes service-mapping guides for professionals of other clouds ("Google Cloud for Azure professionals" and "Google Cloud for AWS professionals"); they are the official starting point and are linked in the references. The mapping used throughout this section, with the page that covers each, is:

Concept Azure AWS Google Cloud page

Serverless containers

Container Apps

ECS on Fargate, App Runner

Cloud Run

Managed Kubernetes

AKS

EKS

GKE Clusters

Object storage

Blob Storage

S3

Cloud Storage

Secrets and keys

Key Vault

Secrets Manager, KMS

Secret Manager and Cloud KMS

Account structure

Management groups, subscriptions

Organizations, accounts

Resource Hierarchy and Projects

Site-to-site VPN

VPN Gateway

Site-to-Site VPN

VPN and Hybrid Connectivity

Migration tooling

Azure Migrate, Database Migration Service

Application Migration Service, DMS

This page

Architecture guidance

Azure Well-Architected Framework

AWS Well-Architected Framework

This page

Two differences matter most when the habits come from elsewhere: a Google Cloud project is the unit of isolation, billing attachment and API enablement (there is no account-per-environment convention as on AWS), and a VPC network is global with regional subnets. Both are explained in Cloud Concepts and Resource Hierarchy and Projects. The Azure and AWS migration pages are Architecture, Migration and Hybrid Cloud and Architecture, Migration, Hybrid and Disaster Recovery.

Security and networking considerations

  • Run migrations from a dedicated project and service account with only the roles needed, for example roles/vmmigration.admin for Migrate to Virtual Machines or roles/datamigration.admin for DMS, granted to a group rather than to individuals and removed after cutover (see Identity and Access).

  • Use private connectivity (HA VPN, Interconnect, Private Service Connect or VPC peering) for database replication instead of exposing source databases to the internet through a wide IP allowlist.

  • Do not store source-cloud access keys on disk. Prefer federation or short-lived credentials; if a Storage Transfer job needs a file with credentials, treat it as a secret and delete it afterwards.

  • Create the landing-zone organization policies before migrating, so migrated resources inherit constraints such as allowed regions or no public IPs (see Governance, Security and Compliance).

  • Enable Cloud Audit Logs and send logs to a central sink so that the migration itself is traceable (Monitoring and Observability).

Limits and quotas

Migration products have their own quotas that matter at scale:

  • Migrate to Virtual Machines limits the number of concurrent replicating VMs and disk sizes per source and project.

  • DMS limits the number of connection profiles and migration jobs per region and project, and requires the source to meet replication prerequisites (binary logging for MySQL, logical replication for PostgreSQL).

  • Storage Transfer Service limits job and agent counts and per-object size; check the quotas page for the current figures.

  • Fleet membership limits apply per fleet, and some features are limited per cluster.

Check IAM & Admin, then Quotas & system limits in the console, or gcloud alpha services quota list --service=datamigration.googleapis.com --consumer=projects/$PROJECT_ID to review the actual values; request increases before the migration wave, not during.

Pricing model

Prices change; use the links in References and the pricing calculator rather than figures on this page.

  • Migration Center is free to use. The cost lies in what it recommends you create.

  • Migrate to Virtual Machines is free for a period per migrated VM (to complete the migration), after which charges apply; the replication storage and test clones are billed as ordinary Compute Engine and Persistent Disk resources.

  • Database Migration Service is free for homogeneous migrations (for example PostgreSQL to Cloud SQL or AlloyDB for PostgreSQL) and priced for heterogeneous ones; the destination instance is billed normally from the moment it is created.

  • Storage Transfer Service is free for transfers between Cloud Storage buckets and charged per GB for transfers from other clouds, plus network egress charges at the source provider.

  • Transfer Appliance is charged per device rental and shipping.

  • Fleet and attached clusters: priced per vCPU of managed cluster, depending on the capabilities enabled.

  • Google Distributed Cloud and VMware Engine are priced per node or per hour of the hardware commitment.

Cost drivers worth watching during a migration are double running costs (source and target both running), egress from the source cloud, replicated and cloned disks that are never deleted, and idle destination databases. Budgets are in Cost Management and Billing.

Troubleshooting

Symptom Likely cause and fix

Migration Center shows no assets after installing the discovery client

The client cannot reach Google APIs (proxy or firewall) or the source was not selected; check the client log and the source registration.

Migrate to Virtual Machines replication stays at 0 percent

The connector appliance or source credentials are broken, or the firewall blocks the replication data path; check the source connection status in the console.

Test clone boots but the application fails

Hostname, license or driver assumptions; check the guest agent installation and network settings on the clone.

DMS job test fails with a replication error

The source misses logical replication settings (wal_level, replication slots, pg_hba.conf entry) or the migration user lacks privileges; follow the prerequisites printed by the wizard.

DMS replication delay keeps increasing

Large transactions or an undersized destination instance; scale up the destination and avoid bulk jobs on the source until the delay drops.

Storage Transfer Service job fails with access denied

The source credentials lack list or read permissions, or the destination bucket does not grant the transfer service agent the Storage Object Admin role.

Attached cluster registration fails

Unreachable OIDC issuer, unsupported platform version or missing admin user; verify with gcloud container attached get-server-config.

Clean up

Remove what you created for the exercises, in dependency order, and skip commands for resources you did not create.

# Database Migration Service: stop and delete the job, then the profile
gcloud database-migration migration-jobs delete catalog-to-cloudsql --region="$REGION" --quiet
gcloud database-migration connection-profiles delete source-catalog --region="$REGION" --quiet

# Cross-region replica used for the disaster-recovery drill
gcloud sql instances delete bookshelf-catalog-replica --quiet

# Fleet memberships
gcloud container attached clusters delete eks-bookshelf --location="$REGION" --quiet
gcloud container fleet memberships delete bookshelf-gke --quiet

# Storage Transfer Service jobs cannot be deleted from the CLI while running; disable then delete in the console,
# or update the status to deleted
gcloud transfer jobs update <job-id> --status=deleted

# Migration Center
gcloud migration-center groups delete bookshelf-group --location="$REGION" --quiet
gcloud migration-center sources delete onprem-inventory --location="$REGION" --quiet

Reference: gcloud database-migration migration-jobs delete

Delete migrated VMs and their replication data through Finalize in Migrate to Virtual Machines, and delete the sources there after the last migration. For a throwaway project, deleting the project removes everything at once: gcloud projects delete my-project-id. Remember that Cloud SQL keeps retained backups and Cloud Storage soft-deleted bytes are billed until the retention period ends.

Recent changes

  • Anthos was rebranded GKE Enterprise in 2023 and its tiering was later reorganised; fleet features are now individually priced capabilities. Verify on the GKE release notes.

  • Container Registry (gcr.io) shut down on 2025-03-18; migration tooling and older guides that push to it must use Artifact Registry (see Container Registry and Builds).

  • Classic VPN dynamic routing was deprecated on 2025-08-01; use HA VPN for new migration connectivity.

  • Deployment Manager reaches end of support in 2026 and shuts down on 2027-06-30; landing zones should be written in Terraform or Infrastructure Manager.

  • gsutil stops shipping with the gcloud CLI after March 2027; use gcloud storage and Storage Transfer Service.

Related pages

References