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

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:

1. Dependency mapping: application-to-database and service-to-service dependencies discovered in Migration Center determine migration waves — tightly coupled components move together.
2. 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.
3. Workload testing: each wave includes functional validation, performance benchmarking against the on-premises baseline, and a rollback plan.
4. 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

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.