11.4 Migration Planning & Execution: Migration Center, DMS, Datastream & Transfer Options

Google Professional Cloud Architect Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Exam Overview, Strategy & Case Study Methodology

1.1 Exam Overview, Structure & Scoring Logistics 1.2 The Professional Cloud Architect Role & Exam Mindset 1.3 Deconstructing GCP Case Studies & Scenario Questions

2 Chapter 2: Designing for Business Requirements

2.1 Mapping Business Objectives, ROI & Total Cost of Ownership 2.2 Cost Optimization Strategies, Pricing Models & Trade-Offs 2.3 Business Continuity, Governance & Compliance Planning

3 Chapter 3: Designing for Technical Requirements & Availability

3.1 Scalability, Elasticity & Capacity Planning 3.2 High Availability, Disaster Recovery Patterns & RTO/RPO 3.3 Performance Optimization & Global Latency Reduction

4 Chapter 4: Compute Selection & Workload Architecture

4.1 Compute Engine Architecture, Sizing & Managed Instance Groups 4.2 Google Kubernetes Engine (GKE) Standard vs Autopilot & Microservices 4.3 Serverless Architectures: Cloud Run, Cloud Functions & Eventarc

5 Chapter 5: Storage, Database & Data Warehouse Architecture

5.1 Cloud Storage Architecture, Storage Classes & Lifecycle Management 5.2 Relational Databases: Cloud SQL, AlloyDB & Cloud Spanner 5.3 NoSQL & Big Data Storage: Firestore, Bigtable & BigQuery

6 Chapter 6: Networking, Hybrid Connectivity & Traffic Routing

6.1 VPC Design, Subnets, Shared VPC & VPC Peering 6.2 Hybrid & Multicloud Connectivity: Cloud VPN & Cloud Interconnect 6.3 Cloud Load Balancing, Cloud CDN & Cloud DNS

7 Chapter 7: Identity, Access & Resource Governance

7.1 Cloud IAM Hierarchy, Custom Roles & Service Accounts 7.2 Workload Identity Federation, Service Account Impersonation & IAP 7.3 Organization Policies, Tags & Resource Governance

8 Chapter 8: Security Architecture, Data Protection & Compliance

8.1 Data Encryption at Rest/Transit, Cloud KMS, CMEK & Cloud HSM 8.2 Network Security: Cloud Armor, VPC Service Controls & Firewalls 8.3 Compliance Frameworks, Sensitive Data Protection & Security Command Center

9 Chapter 9: DevOps, Automation & Infrastructure as Code

9.1 Infrastructure as Code (IaC) with Terraform on Google Cloud 9.2 CI/CD Pipelines: Cloud Build, Artifact Registry & Cloud Deploy 9.3 Deployment Strategies (Blue/Green, Canary) & GitOps with Config Sync 9.4 Interacting with Google Cloud Programmatically: Cloud SDK, Cloud Shell & Emulators

10 Chapter 10: Site Reliability Engineering & Operations Excellence

10.1 SRE Fundamentals: SLIs, SLOs, SLAs & Error Budgets 10.2 Observability: Cloud Monitoring, Logging & Alert Policies 10.3 Diagnosing Performance: Cloud Trace, Profiler & Error Reporting

11 Chapter 11: Data Pipelines, Integration & Modernization

11.1 Event-Driven Architectures with Cloud Pub/Sub & Eventarc 11.2 Stream and Batch Processing: Dataflow & Dataproc 11.3 API Management & Service Integration: Apigee & Cloud API Gateway 11.4 Migration Planning & Execution: Migration Center, DMS, Datastream & Transfer Options

12 Chapter 12: Well-Architected Framework & Official Case Study Solutions

12.1 Google Cloud Well-Architected Framework & FinOps Governance 12.2 Comprehensive Case Studies: EHR Healthcare & Cymbal Retail 12.3 Comprehensive Case Studies: Altostrat Media & KnightMotives Automotive

13 Chapter 13: AI, Machine Learning & Generative AI Architecture

13.1 AI/ML Platform Architecture: Vertex AI, Gemini Enterprise Agent Platform & AI Hypercomputer 13.2 Prebuilt AI APIs, Model Garden, Gemini Cloud Assist & Securing AI

11.4 Migration Planning & Execution: Migration Center, DMS, Datastream & Transfer Options

Key Takeaways Explain This Topic AI

Google Cloud Migration Center discovers on-premises assets (via a discovery client or RVTools/CSV import), groups workloads, and generates cost and fit assessments that anchor the migration plan.

Migration methodology is phased: assess, plan, migrate, optimize — with workload testing, network planning, and application dependency mapping completed before any wave moves.

Database Migration Service (DMS) performs serverless, minimal-downtime migrations of MySQL, PostgreSQL, SQL Server, and Oracle into Cloud SQL or AlloyDB using continuous replication plus cutover.

Datastream provides log-based change data capture (CDC) from Oracle, MySQL, and PostgreSQL into BigQuery, Cloud Storage, or Cloud SQL for ongoing replication and analytics unification.

Software licenses materially shape target design: BYOL support, per-core licensing, and dedicated-host requirements (e.g., Windows Server or Oracle on Bare Metal / Sole-Tenant Nodes) must be evaluated in the plan.

Last updated: August 2026

Migration Planning & Execution: Migration Center, DMS, Datastream & Transfer Options

Architectural Objective: Blueprint section 1.4 ( Creating a migration plan ) expects documents and architectural diagrams covering integration with existing systems, assessment tooling, migration methodologies, workload testing, network and dependency planning, and software license implications. Blueprint 5.1 adds migration and management tooling guidance for implementation teams. A Professional Cloud Architect must build this plan the way Google Cloud's own framework structures it.

Phase 1: Assess with Google Cloud Migration Center

Migration Center is Google Cloud's centralized discovery and assessment service. It inventories the source estate and produces migration-fit and TCO estimates:

Discovery sources: deploy the Migration Center discovery client in the data center for automatic asset and performance-data collection, or import RVTools exports / CSV inventories for VMware estates.

Asset grouping and preferences: assets are grouped into application workloads, assigned target preferences (e.g., prefer containers vs. VMs), and modeled against Google Cloud pricing.

Output: machine-generated migration plans with estimated cloud cost per workload, right-sized machine types, and identification of dependencies that determine wave composition.

Workload Disposition

Each workload receives a disposition decision aligned to the blueprint's build, buy, modify, or deprecate framing: +-----------------------------------------------------------------------------------+

• | WORKLOAD DISPOSITION MATRIX |
• +-----------------------------------------------------------------------------------+
• | REHOST (lift & shift) | Move VM as-is to Compute Engine (fastest, least risk) |
• | REPLATFORM | Move with minor changes: VM -> GKE, or DB -> Cloud SQL|
• | REFACTOR / REBUILD | Redesign for Cloud Run, Dataflow, BigQuery, serverless|
• | REPLACE (buy) | Retire custom app for SaaS (e.g., move CRM to vendor) |
• | RETAIN | Keep on-premises for now (latency/regulatory reasons) |
• | RETIRE (deprecate) | Decommission duplicate or unused systems outright |
• +-----------------------------------------------------------------------------------+
• Phase 2: Plan — Dependencies, Network, Testing & Licenses

A credible migration plan (the documents and diagrams the blueprint names) must include:

Dependency mapping: application-to-database and service-to-service dependencies discovered in Migration Center determine migration waves — tightly coupled components move together.

Network planning: hybrid connectivity (Dedicated/Partner Cloud Interconnect or HA VPN), IP address strategy (avoid overlapping CIDRs between on-premises and VPC), and DNS cutover design are all settled before wave one.

Workload testing: each wave includes functional validation, performance benchmarking against the on-premises baseline, and a rollback plan.

Software license implications: analyze per-core and per-socket licensing, bring-your-own-license (BYOL) eligibility, and requirements like Microsoft license mobility (Sole-Tenant Nodes or Google Cloud VMware Engine for pinned licenses) or Oracle workloads that may belong on Bare Metal Solution . License terms can flip a workload's disposition from rehost to replatform or replace — this financial and legal analysis is an explicit blueprint bullet.

Phase 3: Migrate — Picking the Data-Movement Tool

Movement Problem Correct Tool Why

Live database migration with minimal downtime Database Migration Service (DMS) Serverless; continuous replication then cutover for MySQL, PostgreSQL, SQL Server, Oracle -> Cloud SQL / AlloyDB

Ongoing change data capture into analytics Datastream Log-based CDC from Oracle/MySQL/PostgreSQL into BigQuery, Cloud Storage, or Cloud SQL with low source overhead

Online bulk object/file transfer Storage Transfer Service , gcloud storage Scheduled, managed bucket-to-bucket or S3/POSIX-to-GCS transfers

Offline petabyte-scale data, weak links Transfer Appliance Physical appliance shipped to the data center for high-capacity offline seeding

SaaS/third-party scheduled ingest into BigQuery BigQuery Data Transfer Service Managed scheduled loads from Google and partner sources

VMware estate moved wholesale Google Cloud VMware Engine Dedicated VMware SDDC in Google Cloud — no re-architecture required

Cutover & Rollback Pattern +-----------------------------------------------------------------------------------+

• | STANDARD DATABASE MIGRATION CUTOVER |
• +-----------------------------------------------------------------------------------+
• | 1. DMS continuous replication (CDC) from source -> Cloud SQL/AlloyDB |
• | 2. Validate: checksums, row counts, application smoke tests on the replica |
• | 3. Freeze writes on source -> final sync -> cutover DNS/connection string |
• | 4. Monitor SLOs; rollback = reactivate source (still intact) if validation fails |
• +-----------------------------------------------------------------------------------+
• Phase 4: Optimize & Envision Future Improvements

Blueprint section 1.5 ( envisioning future solution improvements ) closes the loop after cutover:

Cloud and technology improvements: re-evaluate placement as new capabilities arrive — rehost-first workloads are refactor candidates once urgency passes (e.g., a lifted VM monolith later decomposed onto Cloud Run and Pub/Sub).

Evolution of business needs: new markets, M&A, or regulatory shifts re-open locality and compliance decisions (new regions, Assured Workloads, data residency).

Cloud-first design approach: steady-state solutions should prefer managed and serverless primitives over lifted infrastructure, continuously reducing operational toil — measured with the FinOps and SRE instrumentation from earlier chapters.

Important

Exam Watch: For minimal-downtime database migration choose DMS ; for ongoing analytics replication choose Datastream ; for petabyte offline transfer choose Transfer Appliance ; for online bulk moves choose Storage Transfer Service ; for VMware without re-architecture choose Google Cloud VMware Engine . Every answer must come from the assessed dependency map and wave plan produced by Migration Center — not ad-hoc lift-and-shift.