Google Cloud Migration: Portfolio Decisions, Workload Waves and Cutover

A Google Cloud migration should be judged by the quality of the resulting service, not by the number of assets transferred. The target workload must be secure, supportable, financially visible and capable of meeting its business commitments. The source environment must eventually be retired without losing data, evidence or operational control.

This outcome requires more than a migration tool. It requires a portfolio model that connects business intent, technical evidence, cloud foundation readiness, wave planning and production acceptance.

Google Cloud's current Migration Center guidance treats discovery and risk assessment as continuing activities rather than one preliminary phase. That is a sound principle. Migration plans improve as teams learn, and governance should allow evidence to change the sequence.

Define the transformation in business terms

The program should state why workloads are moving and what success will change. A data center exit may emphasize schedule and source retirement. A resilience program may emphasize recovery and regional design. A data modernization program may emphasize analytical capability and time to insight.

For each workload, document the business owner, technical owner, required date, current operating cost, service commitments, recovery objectives, data constraints and known contractual dependencies. Explain the reason behind the date and constraint. This information determines how much change is rational during migration.

The business case should include migration tooling, temporary parallel operation, data transfer, licenses, support, skills and application remediation. It should also describe expected benefits such as delivery speed, reliability or reduced operational burden. A price comparison between source virtual machines and Compute Engine is not a complete case.

Conduct discovery and risk assessment continuously

Migration Center can collect infrastructure inventory, utilization and dependency information. Technical discovery should be supplemented with application interviews, architecture review, source code, network evidence, incident history, deployment procedures and recovery tests.

Every inventory item should connect to a workload and an owner. Every dependency should include confidence and criticality. A connection observed in a short collection window may be seasonal or incomplete. A vendor integration may not appear until a monthly process runs. Uncertainty should be recorded rather than hidden.

Google recommends running migration risk assessment in parallel with discovery and wave planning. This prevents the plan from treating all unknowns as equal. A missing owner, unsupported operating system, large data volume and fixed regulatory boundary create different risks and require different mitigation.

Discovery continues as migration proceeds. Early waves produce better performance, dependency and effort data that should update later estimates.

Select a workload disposition with an explicit return

Google Cloud guidance includes rehost, replatform, refactor or rearchitect, replace and retire. Retain is also necessary when a workload should remain in place for a documented period.

The disposition should include the expected outcome, assumptions, effort range, dependency and review point. Avoid letting rehost become permanent by default. Avoid using refactor as an aspirational label with no funded scope.

Establish the cloud foundation before detailed wave planning

Google's Migration Center identifies foundation design as a prerequisite to wave planning. Identity, resource hierarchy, networking, security, logging, billing and infrastructure as code shape the target for every workload.

The Google Cloud landing zone architecture guide describes these decisions in detail. For migration readiness, the foundation must be tested through a representative workload. Project creation, pipeline identity, network paths, DNS, policy, secrets, logs, backup, monitoring and billing should all be exercised.

The foundation also needs an operating owner. During a cutover, application teams require a clear escalation path for network, identity and policy failures. A technically deployed foundation without support responsibility is not ready for migration.

Plan waves to manage dependency and learning

Migration Center defines a wave as a group of applications that share characteristics or interdependencies. Wave design should consider dependency, business calendar, technical pattern, data movement, team capacity and risk.

Google suggests that early movers have limited dependency and require minimal refactoring so the team can focus on learning the migration process and Google Cloud. This does not mean the first workload should be trivial. A useful first mover exercises enough of the target foundation and operating model to reveal weaknesses while remaining recoverable.

Entry criteria should be factual. The target design is approved, required controls are tested, data movement has been rehearsed, service telemetry is available and decision makers are named. Exit criteria should include business transactions, data integrity, performance, security evidence, recovery, deployment and cost allocation.

Wave size must respect the capacity of application owners, testers, security reviewers and support staff. Infrastructure automation may handle hundreds of resources, while the organization can validate only a few business services at a time.

Design target architecture and migration method together

A source virtual machine can map to Compute Engine, a managed instance group, GKE or Cloud Run. The right target depends on scaling, identity, network, recovery, operational responsibility and application change. Service names alone do not establish equivalence.

Document the target decision and its acceptance tests. A move to Cloud SQL changes patching and backup responsibility but may introduce compatibility, connection or maintenance considerations. A move to GKE changes deployment and capacity management. Cloud Run changes runtime constraints and scaling economics.

Build target infrastructure through Terraform or another controlled infrastructure as code system. Separate foundation, workload, data and application layers according to ownership and rate of change. The team should be able to reproduce the environment and deploy an application fix before the production migration.

Engineer data movement for integrity and fallback

Data movement may use export and import, backup and restore, Storage Transfer Service, Transfer Appliance, Database Migration Service, native replication or application level techniques. The correct option depends on volume, change rate, downtime, consistency and available connectivity.

Rehearsal should use representative data size and transaction behavior. Measure transfer time, replication lag, validation time and fallback duration. Data validation should use record counts, checksums, reconciliation totals and business tests appropriate to the system.

Fallback design must address new writes after traffic moves. Reversing DNS is not sufficient when data has changed in the target. The plan may require a write freeze, reverse replication, compensating transactions or a decision point after which forward recovery is safer than reversal.

Govern production cutover through decision evidence

The cutover runbook should identify authority as well as tasks. It should cover change freeze, final synchronization, target health, traffic movement, business validation, communication and recovery. Each decision threshold should be known before the event.

Production acceptance requires more than healthy compute. Test customer journeys, integrations, batch processes, authorization, performance, security detection, backup restoration, deployment and service level monitoring. Application owners should approve business behavior using recorded evidence.

Hypercare should define enhanced monitoring, support coverage and an exit condition. It should not become an indefinite state used to postpone operational ownership.

Retire the source and validate the economic result

After the agreed fallback and retention period, close the source deliberately. Archive required evidence and data, remove credentials and network paths, cancel licenses, update inventories and confirm that billing has stopped.

Initial Google Cloud sizing is based on imperfect estimates. Rightsize after stable target demand is available. Delay large committed use discount purchases until the architecture and baseline are sufficiently stable. The Google Cloud cost optimization operating model explains this transition, and CloudForge provides GCP cost optimization consulting.

Program governance should track more than asset counts. Useful measures include workloads with confirmed owners and dependencies, risks with funded mitigation, foundation controls proven, waves meeting entry and exit criteria, cutover defects, recovery evidence, source retirement and forecast variance.

CloudForge provides cloud migration consulting for discovery, foundation design, workload planning, data cutover, DevOps and FinOps. Our DevOps consulting helps establish the delivery and operating path required before production migration.

Sources

1. Google Cloud Migration Center planning overview
2. Assess and discover workloads for Google Cloud migration
3. Evaluate and mitigate migration risks
4. Google Cloud landing zone design