Introduction to Cloud Migration on GCP
Migration is a journey, not a single event. For a Professional Cloud Architect, planning a migration requires a deep understanding of the source environment, the target GCP services, and the business constraints (downtime, budget, and risk).
A successful migration follows the Google Cloud Migration Framework:
- Assess: Discover and analyze the current environment.
- Plan: Create a landing zone and prioritize workloads.
- Deploy: Move the workloads.
- Optimize: Refine the architecture for cloud-native features.
A unified platform on Google Cloud that helps you discover, assess, and plan your migration from on-premises or other clouds to GCP. Reference: https://cloud.google.com/migration-center/docs/overview
Plain-Language Explanation: Migration Strategy
Moving to the cloud is often compared to moving your family to a new house in a different city.
Analogy 1 — Moving to a New House (Rehost, Replatform, Refactor)
- Rehost (Lift and Shift): You pack everything into boxes and move them to the new house exactly as they were. It's fast, but your old, inefficient furniture still takes up space.
- Replatform (Lift and Optimize): You move your stuff, but you buy a new, more efficient heating system for the new house. You keep the core structure but upgrade key components.
- Refactor (Modernize): You sell your old house and furniture and design a smart home from scratch. It's the most work, but you get the full benefit of modern living.
Analogy 2 — The Airport Logistics (Migration Waves)
A migration is like renovating a busy international airport. You can't just shut down the airport for a month. You move one terminal at a time (Migration Waves). You start with a small, low-traffic terminal (Pilot/Sandbox) to test the process, then move the major hubs once you are confident.
Analogy 3 — The Language Immersion (Modernization)
Moving a monolithic app to microservices is like learning a new language through immersion. You can translate word-for-word (Rehost), but you won't be fluent. To truly benefit from the culture (Cloud-Native), you need to change the way you think and speak (Architecture).
On the PCA exam, if the goal is "fastest migration" with "minimal code changes," the answer is usually Rehost using Migrate to Virtual Machines. Reference: https://cloud.google.com/architecture/migration-framework
Migration Assessment with Migration Center
Before moving a single byte, you must know what you have.
- Inventory Discovery: Automatically scan vSphere, Hyper-V, or physical servers.
- TCO Analysis: Compare the cost of your current environment with GCP.
- Asset Mapping: Understand the dependencies between applications and databases.
Migration Patterns: The 6 R's
- Rehost (Lift and Shift): Moving VMs as-is using Migrate to Virtual Machines.
- Replatform (Lift and Reshape): Moving to a managed service, e.g., moving a self-managed SQL to Cloud SQL.
- Refactor (Rewrite): Re-architecting into microservices or serverless (Cloud Run).
- Repurchase: Moving from a licensed software to a SaaS equivalent (e.g., GWS).
- Retain: Keeping some workloads on-prem due to latency or compliance.
- Retire: Shutting down legacy systems that are no longer needed.
Data Migration Tools
Moving data is often the biggest bottleneck.
- Storage Transfer Service: For moving large amounts of data from S3, Azure Blob, or on-prem to GCS.
- Database Migration Service (DMS): For serverless, easy migration of MySQL, PostgreSQL, and SQL Server to Cloud SQL or AlloyDB.
- Transfer Appliance: A physical device for petabyte-scale migrations where bandwidth is limited.
For "minimal downtime" database migrations, use CDC (Change Data Capture) provided by DMS to keep the source and target in sync until the final cutover. Reference: https://cloud.google.com/database-migration-service/docs/overview
The PCA 7 R's decision shortcut: object data on S3/Azure Blob/NFS → Storage Transfer Service (online) or Transfer Appliance (offline, petabyte-scale, limited bandwidth); whole VMs → Migrate to Virtual Machines (Rehost); self-managed MySQL/PostgreSQL/SQL Server → Database Migration Service to Cloud SQL/AlloyDB (Replatform); monolith VMs ready to containerize → Migrate to Containers targeting GKE or Cloud Run (Refactor).
"Storage Transfer Service" and "Migrate to Virtual Machines" sound interchangeable but are not. Storage Transfer Service only moves objects/files into Cloud Storage — it cannot boot a VM, preserve the OS, or migrate disks attached to a server. If the scenario keeps the full guest OS and applications (Rehost), the answer is Migrate to Virtual Machines into Compute Engine, not Storage Transfer Service.
Planning for Minimal Downtime
Downtime costs money. Strategies include:
- Blue-Green Deployment: Run the old and new systems in parallel and switch traffic.
- Phased Cutover: Move users in small batches.
- Database Syncing: Use replication to ensure no data is lost during the switch.
Workload Prioritization and Waves
Don't move everything at once.
- Wave 0 (The Landing Zone): Set up VPC, IAM, and Shared VPC.
- Wave 1 (Pilot): Simple, low-risk apps to test the pipeline.
- Wave 2 (Scaling): Business-critical but less complex apps.
- Wave 3 (The Hard Stuff): Complex monoliths and legacy databases.
License Mobility and Cost Management
- Bring Your Own License (BYOL): Using existing Windows or SQL Server licenses on GCP (often requires Sole-Tenant Nodes).
- License-Included: Paying for the license as part of the VM cost.
- Committed Use Discounts (CUDs): Reducing costs by committing to 1 or 3 years of usage.
Post-Migration Validation and Testing
- Performance Benchmarking: Is the app as fast as it was on-prem?
- Security Audit: Are firewall rules and IAM policies correct?
- DR Testing: Does the failover work in the new environment?
Migrating Legacy Databases
Legacy databases often have proprietary features.
- Oracle to Bare Metal Solution: For when you can't easily move to Cloud SQL.
- SQL Server to Cloud SQL: Using DMS for a managed experience.
- Spanner: For global, horizontally scalable relational needs.
Modernizing Monolithic Architectures
The end goal is often "Cloud-Native."
- Strangler Fig Pattern: Gradually replacing parts of a monolith with microservices.
- Containerization: Using GKE or Cloud Run to increase portability and scalability.
When a PCA scenario says "modernize this Linux/Windows VM workload into containers without rewriting the application," the expected answer is Migrate to Containers (formerly Migrate for Anthos) targeting GKE (or Cloud Run for stateless services) — not Migrate to Virtual Machines (that is Rehost, not modernization) and not a full Refactor rewrite. Reference: https://cloud.google.com/migrate/containers/docs/concepts/overview
FAQ — Migration Strategy and Planning
Q1. What is the difference between "Migrate to Virtual Machines" and "Storage Transfer Service"?
Migrate to Virtual Machines is for moving entire VM images (OS + Apps) into Compute Engine. Storage Transfer Service is for moving files and objects into Cloud Storage.
Q2. How do I choose between Rehosting and Refactoring?
Choose Rehosting for speed and low risk. Choose Refactoring for long-term scalability, cost-efficiency, and to leverage cloud-native features like auto-scaling.
Q3. What is a "Landing Zone"?
A Landing Zone is the foundational GCP environment (VPC, Folders, IAM, Logging) that is pre-configured to receive migrated workloads securely and according to best practices.
Q4. How do I move 100TB of data with a 100Mbps connection?
100TB would take months to transfer over 100Mbps. In this case, use a Transfer Appliance to ship the data physically to Google.
Q5. What is "Post-migration Optimization"?
This is the phase where you right-size VMs, implement auto-scaling, and switch to managed services to further reduce costs and operational overhead after the initial move.
Final Architect Tip
The biggest failure in migration isn't technical; it's lack of discovery. Spend more time in the Assess phase than you think you need. Use Migration Center to uncover hidden dependencies, or you'll find out about them the hard way during the cutover!