The most expensive stretch of migrating to Google Cloud is usually the middle, when workloads already running on Google Cloud are still being billed on AWS, Azure or in your data center. Take a $60,000 monthly AWS bill moved in six monthly waves. Shut each source down one month after its wave cuts over, and the overlap costs $60,000. Leave every source running until the last wave, and the same migration costs $210,000 in overlap alone.
That $150,000 gap comes from one decision, made workload by workload, and a GCP migration is a long series of decisions like it. For every application, the team chooses how it moves (unchanged, onto a managed platform, or rewritten), in which wave, and when its source is switched off. Each choice sets two bills: the one-off cost of moving and the run-rate once the workload lands.
This guide covers when a move to Google Cloud pays off and which workloads should stay where they are, the six migration strategies Google defines and how to choose one per workload, the foundation to build before anything moves, the eight steps of the migration itself, and the mistakes that cause overruns. Here is the complete guide on how to plan GCP migration.
A migration pays off when a specific situation makes the current platform more expensive or more limiting than the cost of leaving it. The five triggers below are the ones that justify a migration:
All six of Google’s migration strategies describe ways to move a workload, yet most estates contain workloads that cost more to migrate than they will ever save. Leave these in place, or retire them:
Google’s migration framework runs in four phases (assess, plan, deploy, optimize) and defines six ways to move a workload, called the 6Rs of migration.
Rehosting moves a workload with minor or no modifications. Migrate to Virtual Machines does the work, replicating VMs from on-premises, AWS or Azure in the background while the source keeps running. It is the fastest route and fits moves driven by a deadline, such as an expiring contract.
Replatforming keeps the code and replaces the layer underneath it. The common case is a self-run MySQL or PostgreSQL server moving to Cloud SQL or AlloyDB through Database Migration Service, which charges nothing for those same-engine migrations. It suits ops-heavy stacks where the team spends its week patching databases. And stops being enough when the code itself limits how the application scales.
Refactoring changes the code so the workload uses cloud services, for example a scheduled batch job rewritten to run on Cloud Run. Google notes that it needs new skills and more time. It earns its cost on core products that change every week, and it fails when the business deadline is shorter than the refactor.
Re-architecting changes how the application is structured, typically splitting a monolith into services. It carries the most testing of any strategy that keeps the original codebase. It is justified when the current design blocks scale or release speed, and only if the team can operate a distributed system once it is built.
Rebuilding decommissions the application and writes a cloud-native replacement. It is rarely the right first move, because the old system has to keep running until the new one is proven, which makes it the longest overlap of any strategy.
Repurchasing replaces a self-hosted product with a SaaS equivalent. Google describes it as simpler but potentially costlier, with less control. The migration work becomes data export, identity integration and user change management.
Take a company of about 300 people running on AWS. It is moving 140 VMs, 50 TB of data in Amazon S3, one MySQL database and one Oracle database to Google Cloud over six months. Google prices in US dollars, so this section does too.
The foundation, often called the landing zone, is the structure every workload lands in: the resource hierarchy, identity, network, security policy and logging. Google warns that a poorly planned foundation can delay the migration and put it at risk. Treat it as a gate: no workload moves until the four areas below are built and tested.
Google Cloud organizes everything into an organization, folders and projects. Teams arriving from AWS tend to recreate one project per AWS account and stop there, which leaves billing reports, access, and policy with no structure above the project.
Design the folders around who owns what (business units, environments, or both) before the first project exists, because billing exports and cost reports follow the hierarchy from day one.
Federate your existing identity provider so people sign in with the accounts they already have. The access model is the biggest change for an AWS team. In Google Cloud, roles granted on an organization, folder or project are inherited by everything beneath it, and a resource’s effective access is the union of its own policy and every policy above it.
A role granted carelessly at the organization level reaches every project. Give each workload its own service account with the roles it needs, and never run workloads on the default service account. Our guide to sequencing Google Cloud security debt shows how those defaults turn into findings.
VPC networks in Google Cloud are global, and subnets are regional, so one network can span every region you use without peering between regions. Shared VPC keeps the network in a central host project while workload projects deploy into its subnets, which gives the platform team control of routing and firewall rules. Connect the source environment with Cloud VPN or Cloud Interconnect for the migration window, and plan DNS so each wave can switch independently.
Set the organization policies before anything is created. For European companies the first one is the resource location constraint with the in:eu-locations value group, which blocks resources outside EU regions across the whole organization. Add centralized audit logging, labels for cost allocation, and budgets per folder. Google’s Enterprise foundations blueprint and Cloud Foundation Fabric give you Terraform to start from instead of a blank repository.
Every GCP migration runs through the same eight steps, whatever mix of strategies it uses. Where a step differs for an on-premises source and for AWS or Azure, the step says so.
Build the inventory in Migration Center, which discovers servers and databases, maps application and network dependencies, and produces total cost of ownership reports. From on-premises, run its discovery in your environment or upload inventory data manually.
From AWS, use its AWS discovery and add the per-instance details Google lists in its EC2 migration guide, such as the AMI, instance store versus EBS usage, security groups and Auto Scaling group membership. Record a performance baseline for every workload in scope, because step 5 measures against it.
Score each workload against the four criteria in the strategy section and assign its strategy, or retain or retire it. Price the one-off bill using the six cost lines above. If you plan to use Google’s RaMP funding, run the RaMP assessment at this point. Google describes it as the step that formally qualifies a project for the program’s funding and incentives, and it produces the standardized technical report (the RaMP Exhibit) that Google requires before committing workload IDs in the Admin Console.
A wave is a group of workloads that move and cut over together because they depend on each other. Make the first wave low risk but representative: one stateless service, one database and one storage bucket teach the team more than five identical web servers. Before any wave starts, write down three dates and one rule: the cutover date, the rollback deadline, the decommission date, and the measurable condition that triggers a rollback.
Build and test the landing zone described in the foundation section. No workload moves until it passes.
Take the first wave through every remaining step, including cutover and decommissioning. Migrate to Virtual Machines can create test clones on Google Cloud while the source keeps running, so the team can validate a workload before committing to cutover. Compare the results against the Step 1 baseline and adjust the plan before the larger waves.
Start the database replication early with Database Migration Service, so the cutover window only has to absorb the last changes. Choose the file transfer method from the transfer-time arithmetic: Storage Transfer Service copies from Amazon S3, Azure Blob Storage or on-premises file systems over the network, and Transfer Appliance ships the data physically when the upload would take more than a week.
Lower DNS TTLs a few days before the cutover so the switch propagates quickly. On the day, freeze writes on the source, run the final sync, switch traffic, and keep the source intact and read-only until the rollback deadline passes. The trigger written in step 3 decides whether you roll back.
Shut each source down on its decommission date, wave by wave, which is the single biggest saving in the program. After 30 to 60 days of stable usage, rightsize the rehosted VMs and size committed use discounts on what the workloads actually consume.
Each of these turns up in migrations that ran over budget or over time. Each one has a price, and most of them are set before the first workload moves.
Revolgy is a Google Cloud Premier Partner with 25 years in the cloud and more than 40 certifications. We run migrations from AWS, Azure and on-premises data centers to Google Cloud. A typical engagement runs in three phases:
A single wave of rehosted VMs can move in a few weeks, while a program of several waves that includes database replatforming usually runs for several months. The number of waves and the database strategy set the timeline, because each wave needs its own cutover and rollback window, and cross-engine database moves need the longest testing.
Yes, Google charges nothing for the Migrate to Virtual Machines service on migrations into Google Cloud. You pay for the Compute Engine VMs it creates for test clones and cutover, and the source cloud keeps billing its own compute, disk and network while replication runs.
No, if the move qualifies for the AWS exit waiver, which covers data transfer out for customers moving all their data off AWS, or all their data off one service. The waiver is requested through AWS Support and paid as credits once approved, with 180 days to finish the move outside the EU and a separate EU Data Act process inside it. A partial move pays standard AWS data transfer rates.
Rehost moves a workload unchanged, replatform swaps the managed layer underneath it, and refactor changes the code to use cloud services. A VM moved through Migrate to Virtual Machines is a rehost, a self-run MySQL server moved onto Cloud SQL is a replatform, and a batch job rewritten for Cloud Run is a refactor. Refactoring costs the most to execute and usually leaves the lowest run-rate.