Google PCA: Migration, Modernization and Hybrid Cloud Strategy — Study Guide

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

Part of the Google Professional Cloud Architect — Study Guide. Practice with verified answers in the Google exam hub, or take timed practice tests on ExamRoll.io.

Overview

A successful migration, modernization, and hybrid-cloud strategy aligns platform choices with business outcomes while managing risk to availability, data integrity, latency, security, and cost. The path balances rapid rehost to reduce data center risk with targeted refactoring to capture cloud benefits. The operating model must evolve alongside the technology to sustain improvements. This section provides a pragmatic blueprint for assessment and wave planning, decision frameworks, migration mechanics, hybrid integration, modernization patterns, policy and multi-cloud considerations, and post-migration optimization, with emphasis on failure modes and trade-offs.

Assessment, Readiness, and Wave Planning

Discovery and dependency analysis
- Inventory workloads, versions, OS kernels, storage, IAM, and data classifications. Map dependencies across web→API→DB flows, shared services (LDAP/AD, DNS, NTP), batch pipelines, and external APIs.
- Use application profiling and distributed tracing in pre-migration environments to surface hidden dependencies and long-tail latency. Turn on VPC Flow Logs and application-level instrumentation (Cloud Logging, Cloud Monitoring, Cloud Trace).
- Identify state boundaries and data gravity: size, access patterns (R/W mix), consistency expectations, and replication topology.
Readiness and skills
- Assess cloud fundamentals, IaC, CI/CD, SRE, security, networking, and database skills. Define a role-based training and certification roadmap and budget time for upskilling and shadow on-calls.
- Establish a landing zone (projects, folders, Shared VPC, org policies, audit sinks, CMEK strategy) before the first wave.
Migration-wave planning
- Group applications into waves by affinity and blast radius: shared data, synchronous dependencies, and change windows. Pull high-risk dependencies into the same wave or stub them with well-defined API contracts.
- Define per-wave SLOs, RTO/RPO, rollback criteria, and validation gates (schema checks, synthetic user journeys, performance thresholds).
- Prepare runbooks and change management: cutover steps, checkpoints, rollback, and evidence collection for sign-off.
Compatibility, licensing, and performance baselining
- Validate OS and middleware support in Compute Engine and managed services. Check commercial licensing terms, BYOL constraints, kernel module requirements, and hardware affinities.
- Capture CPU, memory, IOPS, throughput, and latency baselines with peak and 95th percentile values to size target resources and to validate benefits.
Data governance
- Classify PII/PCI data. Plan de-identification or tokenization at ingest using Cloud DLP. Define audit, retention, and export policies before the first production log is stored.

Common failure modes: unknown synchronous dependencies causing cascading timeouts post-cutover; overlapping IP ranges blocking connectivity; license compliance gaps; lack of rollback parity where data mutations cannot be undone.

Migration Patterns, Data Movement, and Cutover

Decision framework (6Rs)
- Rehost: move as-is to Compute Engine. Fastest time-to-cloud, minimal change. Risk: carries technical debt and inefficient sizing.
- Replatform: small changes to adopt managed services (e.g., Cloud SQL, Cloud Load Balancing). Faster ops benefits with low code change.
- Refactor: decompose or containerize for GKE/Cloud Run; adopt event-driven patterns. Highest long-term benefit with delivery risk.
- Retire: remove unused systems after usage and dependencies are proven absent.
- Retain: keep on-prem for regulatory or latency reasons; integrate via hybrid.
- Relocate: move vSphere workloads to Google Cloud VMware Engine; preserves tooling and minimizes change.
Compute and database migration tools
- Migrate to Virtual Machines accelerates rehost into Compute Engine while preserving disks and network config. Validate guest OS support and kernel drivers.
- Database Migration Service provides homogeneous online replication (e.g., MySQL, PostgreSQL) to Cloud SQL with low downtime. Ensure binlog/replication settings are correct and latency supports near-real-time catch-up.
- Choose databases to match workload:
  - Cloud SQL for managed relational needs; enable automatic storage increase and monitor CPU near 75% per core; track replication lag and shard or scale up if approaching thresholds.
  - Bigtable for low-latency, high-throughput time-series ingestion (e.g., sensor data).
  - Spanner for global scale and strong consistency; understand lock-in vs portability.
- Data movement
  - Storage Transfer Service for ongoing or scheduled transfers; parallelize and retry-aware.
  - Transfer Appliance for bulk one-time loads (tens to hundreds of TB) to reduce network time and risk.
  - gsutil and parallel composite uploads for small-to-medium datasets.
Online vs offline migration
- Online: continuous replication with a short cutover. Pros: minimal downtime; Cons: requires stable latency and bandwidth; careful dual-write avoidance.
- Offline: snapshot and bulk import. Pros: simple and predictable; Cons: downtime equals copy duration.
Cutover planning, rollback, and downtime control
- Lower DNS TTLs days before cutover, freeze nonessential changes, and schedule a maintenance window.
- Execute validation gates: schema parity, checksums or row counts, application smoke tests, canary traffic, and performance probes.
- Rollback: ensure backward-compatible schema changes, feature flags, and preserved source-of-truth data. Avoid irreversible writes until stability is proven.
- Example VM disk expansion with minimal downtime:
  - Resize disk in Console or CLI: gcloud compute disks resize my-disk –size=500GB –zone=us-central1-a
  - On Linux ext4: sudo resize2fs /dev/sdb
- Rolling app updates with minimal impact on GKE:
  - kubectl set image deployment/echo-deployment echo-container=gcr.io/project/echo:v2

Common failure modes: packet loss over Cloud VPN disrupting database replication (use Dedicated Interconnect or Partner Interconnect), dual-write divergence during cutover, missing health checks halting rolling updates.

Hybrid Identity, Connectivity, and On-Premises Integration

Identity
- Retain Active Directory as the source of truth. Use Google Cloud Directory Sync for account and group synchronization, and configure SAML SSO for user access to Google Cloud.
- Grant least-privilege IAM via roles, use service accounts for workloads, and prefer Workload Identity Federation over long-lived keys.
Hybrid connectivity and routing
- Use Cloud VPN for initial low-throughput needs and testing; move to Dedicated Interconnect for sustained bandwidth, lower latency, and predictable replication performance. Deploy redundant VLAN attachments and HA VPN or dual interconnects for resilience.
- Ensure Google Cloud IP ranges do not overlap with on-premises CIDRs to preserve end-to-end reachability.
- Enforce tiered access with firewall rules and tags. Example to allow web→API only:
  - gcloud compute firewall-rules create allow-web-to-api –network=prod-vpc –direction=INGRESS –action=ALLOW –rules=tcp:8443 –source-tags=web –target-tags=api
- Use Private Service Connect and private Google access for service-to-service communication without public egress; segment with VPC Service Controls where appropriate.
- Hybrid DNS: use Cloud DNS with forwarding and inbound/outbound policies to resolve both on-prem and cloud names.
On-premises integration and latency
- Keep state close to compute or vice versa; if on-prem DB must remain authoritative, consider App Engine flexible or Compute Engine with Cloud VPN/Interconnect for private access.
- Introduce caches and queues to decouple synchronous paths and to absorb latency jitter; measure p95/p99 latency, not just averages.

Common failure modes: overlapping CIDRs blocking routes, insufficient BGP session redundancy, public DNS or egress leaks exposing private services, and unanticipated chatty protocols suffering over high-latency links.

Modernization, Operating Model, and Optimization

Legacy modernization patterns
- Strangler fig: place an API facade in front of the monolith and incrementally route domains to new services.
- Containerization: standardize base images (prefer slim images such as Alpine when compatible), order Dockerfile layers to cache dependency installation before copying source to reduce build time, and adopt a CI/CD pipeline with automated testing in staging.
- Managed data: move operational stores to managed databases; choose per domain: Cloud SQL for transactional, Bigtable for time-series, Spanner for globally consistent workloads.
Application compatibility, consistency, and performance validation
- Confirm OS and middleware support, thread and connection limits, and filesystem semantics. Validate licensing portability and usage metering.
- Define data consistency requirements (read-your-write, monotonic reads, eventual vs strong). Align them to target databases and access patterns.
- Validate performance with load tests and synthetic user journeys; ensure SLO budgets are achievable post-migration.
Observability and compliance
- Instrument applications with Cloud Logging, Monitoring, and Trace to localize latency across microservices.
- Export audit logs and IAM policy changes to BigQuery and share with auditors via views and IAM on datasets. Export long-term metrics to Cloud Storage to meet multi-year retention requirements.
Operating model and ownership
- Adopt SRE practices: SLOs, error budgets, incident response, and blameless postmortems. Define service ownership, runbooks, and on-call rotations.
- Use IaC (e.g., Terraform) to provision infrastructure consistently. Be aware that Deployment Manager is Google-specific and may limit multi-cloud resource automation and is unfamiliar to many engineers.
- Automate policy consistency with Organization Policy, IAM Conditions, Config Sync, and Policy Controller (OPA Gatekeeper) across projects and environments.
Multi-cloud strategy and lock-in trade-offs
- Increase portability with Kubernetes, 12-factor app practices, OpenAPI-defined contracts, and data egress abstractions. Balance portability with operational burden and performance; managed services reduce toil but may increase switching cost.
Cost and performance optimization; decommissioning
- Scale stateless Compute Engine with managed instance groups and autoscaling; choose serverless (Cloud Functions or Cloud Run) for bursty or MVP workloads that benefit from scale-to-zero.
- Rightsize VMs, enable autoscaling on GKE, apply committed use discounts, and decommission unused artifacts. Track benefits realization via KPIs (availability, latency, cost-to-serve).
- Decommission on-prem systems after a cooling period and dependency confirmation. Archive or delete data per retention policy and update the CMDB.

Practical Problem Scenario

Acme Weather Networks must migrate its real-time sensor platform and a legacy J2EE admin UI from an on-premises data center to Google Cloud. The system ingests 50,000 sensors sending 10 readings per second and stores five years of historical data (75 TB). It must maintain private access to on-prem ERP and Active Directory during transition, minimize downtime for an on-prem MySQL database, and eliminate intermittent replication failures observed over VPN.

Establish a secure landing zone
- Create org, folders, and prod/nonprod projects. Set up a Shared VPC with non-overlapping IP ranges to ensure on-prem reachability via hybrid connectivity. Apply org policies and centralized audit log exports to BigQuery with least-privilege access.
- Rationale: Prevent routing conflicts and enforce baseline governance before workloads arrive.
Implement hybrid identity
- Configure Google Cloud Directory Sync to mirror AD identities and groups and set up SAML SSO. Use service accounts and IAM custom roles for the platform and workloads.
- Rationale: Retains enterprise identity as the source of truth and enables least-privilege access control.
Provision connectivity and plan for performance
- Start with HA Cloud VPN for dev/test. For production database replication and steady sensor ingestion, provision Dedicated Interconnect with dual VLAN attachments and BGP sessions.
- Rationale: Interconnect provides lower latency and fewer packet drops than VPN, stabilizing MySQL replication and streaming ingestion.
Move historical data efficiently
- Order Transfer Appliances, load the 75 TB dataset on-prem, ship, and rehydrate into Cloud Storage. Use Storage Transfer Service for ongoing incremental updates if needed. Run Cloud DLP on support logs to de-identify PII before Bigtable or BigQuery storage.
- Rationale: Offline bulk transfer reduces cutover window risk and avoids saturating circuits.
Rehost the J2EE admin UI
- Use Migrate to Virtual Machines to lift-and-shift the J2EE VM to Compute Engine. Place instances in a managed instance group behind an HTTP(S) load balancer. Apply firewall rules by tags to enforce web→API→DB flows only. Example:
  - gcloud compute firewall-rules create allow-web-to-api –network=prod-vpc –direction=INGRESS –action=ALLOW –rules=tcp:8443 –source-tags=web –target-tags=api
- Rationale: Rapid risk reduction with familiar runtime while enforcing least-privilege network paths.
Migrate MySQL to Cloud SQL with minimal downtime
- Baseline performance and enable binary logging on the source. Use Database Migration Service to set up continuous replication into Cloud SQL. Enable automatic storage increase and create alerts for CPU near 75% and replication lag under 60 seconds.
- Rationale: Online migration achieves low downtime; managed SQL reduces toil and enforces operational SLOs.
Execute controlled cutover
- Lower DNS TTLs 48 hours prior, freeze schema changes, and schedule a maintenance window. Stop writes on-prem, ensure DMS lag is zero, run checksums and application smoke tests, and then point clients to Cloud SQL. Maintain a rollback plan where writes can be redirected back to on-prem if validation fails.
- Rationale: Deterministic steps limit RTO and maintain data consistency.
Build ingestion for real-time telemetry
- Ingest via Pub/Sub, process with Dataflow, and store time-series in Bigtable for low-latency writes and reads. Keep ERP integration private over Interconnect.
- Rationale: Bigtable matches the high-throughput time-series profile, and Pub/Sub decouples bursty producers from consumers.
Containerize services and introduce CI/CD
- Containerize stateless services for GKE. Optimize Dockerfiles by using slim base images and ordering layers so dependency installation precedes copying source. Implement a CI/CD pipeline with automated tests in staging and canary rollouts. Update with minimal downtime:
  - kubectl set image deployment/ingester ingester=gcr.io/acme/ingester:v2
- Rationale: Improves deployment speed, reliability, and scalability without a big-bang rewrite.
Enhance observability and audit
- Instrument Cloud Logging, Monitoring, and Trace to pinpoint latency across microservices. Export audit logs to BigQuery and share auditor-scoped views. Export long-term metrics to Cloud Storage to meet five-year retention.
- Rationale: Full-fidelity telemetry supports SLOs and compliance.
Optimize and decommission
- Enable autoscaling on MIGs and GKE, rightsize instances, apply committed use discounts, and schedule non-24x7 workloads on serverless (e.g., Cloud Functions for auxiliary tasks) to scale to zero. After stability and a cooling period, decommission on-prem systems, update the CMDB, and publish benefits realized.
- Rationale: Capture cost and operational efficiencies while eliminating dual-run expenses.
Operationalize and train
- Finalize runbooks, RACI, on-call rotations, and SLO/error budgets. Deliver targeted training and certification plans to close skill gaps. Prefer Terraform for IaC; note that Deployment Manager is Google-specific and may not address non-Google resources.
- Rationale: A mature operating model sustains reliability and velocity beyond the migration event.