Google Cloud Professional Cloud Architect: Migration Planning

Migration planning is explicitly part of Google’s current Professional Cloud Architect blueprint. The guide calls out workload assessment, integration with existing systems, migration methodologies, testing, network planning, dependency planning, software-license implications, and financial impact. That makes the Google Cloud Professional Cloud Architect less interested in a generic “move to cloud” story than in a controlled transition from one operating state to another.

Professional migration design starts with uncertainty. Existing systems may have undocumented dependencies, unsupported runtimes, hard-coded IP addresses, fixed maintenance windows, or licensing constraints that only become visible during discovery. A good architect therefore creates a sequence that produces evidence early, limits blast radius, and leaves a workable rollback path.

Inventory applications, data, and dependencies before choosing a strategy

Discovery should capture more than servers. Document business owners, users, upstream and downstream systems, data stores, network paths, identity dependencies, batch schedules, backup methods, performance baselines, and maintenance constraints. The result should explain how the service functions today, not merely where its VMs run.

Dependency mapping prevents a common migration failure: moving the visible application while leaving a latency-sensitive database, file share, identity service, or licensed middleware behind. Even when those dependencies can remain temporarily, the architecture should acknowledge the cross-environment path and its performance and availability consequences.

Discovery outputs should be useful enough to drive sequencing. Record peak usage windows, database sizes, recovery objectives, dependency direction, data sensitivity, and the people who can approve downtime. A spreadsheet of server names without those relationships does not support architecture decisions and often causes migration plans to underestimate application coupling.

Classify workloads by disposition

Not every workload should be treated the same. Some can be rehosted quickly, others should be replatformed onto managed services, some justify refactoring, and some should be retained, replaced, or retired. The right disposition depends on business value, technical condition, migration risk, and expected lifetime.

A system that will be decommissioned in a year may not justify a deep modernization project. A strategic application with chronic scaling problems may benefit from a redesign rather than a lift-and-shift. Professional architects separate the urgency of moving from the value of changing.

Disposition should also account for organizational timing. A system may be a good refactoring candidate but still need a short-term rehost because a data-center exit date is fixed. The architect can separate the immediate migration tactic from the longer modernization roadmap instead of pretending one move must solve every technical problem.

Build a landing zone before large migration waves

A landing zone establishes the governance and operational foundation that migrated workloads will inherit. Resource hierarchy, projects, IAM, networking, logging, security policy, billing, quotas, and deployment standards should be defined before dozens of applications arrive. Otherwise every migration team invents its own baseline.

Landing zones also make migration repeatable. Teams can focus on application-specific work because shared controls and connectivity already exist. This reduces late security rework and helps the organization distinguish platform problems from workload problems during cutover.

Landing-zone controls should be tested with a real pilot workload. Verify that teams can obtain projects, deploy through approved pipelines, reach required shared services, emit logs, request exceptions, and recover from mistakes. A landing zone that exists only as policy documentation is not yet an operational platform.

Plan hybrid networking and name resolution for the transition

Most migrations are hybrid for a period, which means routes, DNS, firewall rules, bandwidth, and address space are temporary production dependencies. The hybrid cloud deployment models provide useful context, while the migration plan must be more concrete: which traffic crosses the boundary, how it is secured, and what happens if that path fails?

Migration traffic can also compete with production traffic. Large data transfers, image replication, or backup seeding may consume bandwidth needed by users. Schedule bulk transfers, use appropriate transfer services, and measure network capacity before the cutover window rather than discovering constraints during the move.

Hybrid DNS deserves its own cutover checks. During migration, the same service name may need to resolve differently for different consumers or change from an on-premises address to a cloud endpoint. Plan TTLs, forwarding, split-horizon behavior, and rollback before production users depend on the new resolution path.

Move data with consistency and cutover in mind

Data migration is usually the hardest part because applications continue changing source data while copies are being moved. Choose between bulk transfer, replication, change data capture, export/import, or service-specific migration tools based on dataset size, change rate, downtime tolerance, and consistency requirements.

The cutover plan should define when the source becomes read-only, how final changes are synchronized, how integrity is verified, and who authorizes the switch. Data reconciliation matters as much as transport speed; moving bytes successfully does not prove that the target system is correct.

Data validation should include counts, checksums where appropriate, key business totals, schema comparison, and representative application reads. For large datasets, sample-based validation may be necessary, but the sample should target high-risk records rather than only convenient partitions. Migration success is a data-quality claim as well as a transfer claim.

Use migration waves to reduce uncertainty

Start with representative but non-critical workloads that exercise the landing zone, hybrid network, deployment process, monitoring, backup, and support model. The goal of a pilot is not only to prove that one application can move. It is to discover which assumptions fail before higher-risk workloads depend on them.

Later waves can group applications by dependency, business calendar, technical pattern, or shared team. Avoid waves so large that troubleshooting becomes ambiguous. A controlled sequence lets the organization improve tooling and runbooks between migrations.

Wave design should reserve time for learning. If every application is scheduled back-to-back with no room to incorporate lessons, the program repeats the same mistakes. Capture issues from each wave, update automation and runbooks, then apply those improvements before the next set enters cutover.

Validate performance, security, and recovery before cutover

Functional testing alone is not enough. Compare latency, throughput, batch duration, failover behavior, logging, access controls, backup, and operational alerts with the pre-migration baseline. If the target design intentionally changes behavior, document the new acceptance criteria.

Security validation should confirm that inherited policies and identity controls work as expected in the cloud. Recovery validation should prove that the team can restore or fail over the migrated system under the new architecture. Migration completion should not create a less recoverable service.

Performance comparisons should be normalized for workload. A cloud test executed at low concurrency tells little about how the service will behave during a business peak. Reuse production-like traffic models and known heavy transactions so teams can distinguish architecture regressions from ordinary variance.

Design rollback as a real technical path

Rollback is not “move it back if something goes wrong.” Define the time window in which rollback is possible, what data must be synchronized back to the source, which DNS or routing changes must be reversed, and which configuration changes are one-way. Some cutovers become difficult to undo after users write new data.

A credible rollback plan also includes decision criteria. Teams need to know which failures justify reverting and which can be repaired in place. Without thresholds, incident pressure can produce indecision while the migration window closes.

Rollback also needs data ownership clarity. If both old and new systems accept writes during a test period, decide how conflicts will be handled and which copy is authoritative. Dual-write designs can reduce cutover risk in some cases, but they also create reconciliation complexity that should not be introduced casually.

Include licenses, people, cost, and decommissioning

Migration economics include software licensing, dual-running environments, network transfer, training, support contracts, and engineering time. The system life cycle is a useful reminder that the project is incomplete until the old environment is retired and operational ownership is established.

Decommissioning should remove obsolete servers, routes, accounts, firewall rules, monitoring, backups, and recurring costs. It should also preserve records required for audit or retention. A migration that leaves the entire legacy estate running indefinitely has moved workloads but has not captured the expected operational value.

Post-migration cleanup should include financial verification. Confirm that reserved licenses, support contracts, colo charges, and backup subscriptions tied to the old platform are actually terminated when no longer required. Otherwise the cloud migration can look expensive simply because the organization is paying for two estates.

A migration plan should end with measurable exit criteria. Confirm that production traffic is on the target, monitoring and backup are owned by the receiving team, rollback windows are formally closed, and the legacy environment has no hidden consumers. Review cost after decommissioning rather than during the dual-running phase, because temporary overlap can distort the business case. For exam scenarios, this full lifecycle matters: discovery, disposition, landing zone, network and data movement, pilot waves, cutover, validation, rollback, and retirement are one architecture problem, not separate project checklists.

Before declaring success, document the new steady-state architecture and remove migration-only exceptions. Temporary firewall openings, elevated roles, transfer buckets, and emergency scripts should expire. This closes the transition cleanly and prevents short-lived migration controls from becoming permanent technical debt.