Migrating to Google Cloud Platform (GCP) works best as four phases: assess what you run today, plan each workload's path, deploy in controlled waves, then optimize once the traffic is live. This guide walks through each phase, the tools Google provides for it, the strategies to choose from, and the points where migrations usually go wrong. It is written for IT leaders, CTOs and compliance owners at small and mid-sized organizations who need a working plan, not a sales pitch.
TL;DR
- Google Cloud frames migration as four phases: Assess, Plan, Deploy and Optimize. Skip none of them, least of all the first.
- Pick a strategy per workload (rehost, replatform, refactor, retire and so on), not one for the whole estate.
- Use managed tools: Migration Center for discovery and cost estimates, Migrate to Virtual Machines for servers, Database Migration Service for databases, Storage Transfer Service for files and objects.
- Regulated data (HIPAA, PCI-DSS, SOC 2) stays your responsibility after the move. A signed agreement with Google does not make your configuration compliant.
- Treat migration as a team project: blend internal knowledge of your workloads with outside migration experience.
Table of Contents
- What a GCP migration actually involves
- Phase 1: Assess what you have
- Phase 2: Choose a strategy for each workload
- Phase 3: Build the landing zone before you move anything
- Phase 4: Move the workloads
- Automate the deployment path
- Healthcare and regulated data: what changes
- A GCP migration checklist
- Phase 5: Optimize after the move
- Our perspective: why migrations stall
- Getting help with your migration
- FAQ
- Sources
What a GCP migration actually involves
Google describes cloud migration as moving applications, databases and storage, along with the networking and security around them, into a cloud environment. The word "along with" matters. Most failed migrations are not failed server copies. They are forgotten dependencies: a licence server, a firewall rule, a nightly batch job nobody documented.
Before anything moves, agree on three things in writing:
- Why you are moving. Exiting a data centre lease, retiring ageing hardware, scaling a product, or meeting a compliance requirement lead to different plans.
- What "done" means. A cut-over date, a decommission date for the old environment, and the performance and cost targets you will measure against.
- Who owns each workload. Every application needs a named business owner who can sign off on testing.
Phase 1: Assess what you have
Discovery is where the budget is won or lost. Build an inventory of servers, databases, storage, network paths and the applications that sit on top. For each, record owner, criticality, dependencies, data sensitivity and current utilization.
Google's Migration Center automates much of this: it discovers assets, profiles them and generates total cost of ownership (TCO) reports. Two details are worth knowing:
- Its default estimate assumes a five-year timeline, with cumulative completion of 15% in year one, 30% in year two, 50% in year three, 75% in year four and 100% in year five. Google advises adjusting those percentages to match your own capacity, and a smaller organization that plans to move in six months should certainly do so.
- You can apply one-year or three-year committed use discounts to refine the projection.
On a tight budget, Google notes you can run a rapid cost estimate in Migration Center without fully activating the platform. That is a sensible first step before you commit to a project.
What to capture for every workload
| Item | Why it matters |
|---|---|
| Dependencies (upstream and downstream) | Decides which systems must move together |
| Data classification | Flags PHI, cardholder data and anything under contract restrictions |
| Peak and average utilization | Right-sizes virtual machines instead of copying oversized servers |
| Licensing | Some software is bound to hardware or to specific cloud terms |
| Acceptable downtime | Chooses between a cold cut-over and continuous replication |
| Integration points | Identity, email, payment gateways, third-party APIs |
Phase 2: Choose a strategy for each workload
The question "which GCP migration strategy is best?" has no single answer, because the answer differs per application. Google's migration guidance follows the Gartner-style "6 Rs" model, in which each application takes one of a few primary journeys. In practice:
- Rehost (lift and shift). Move the server as is. Fastest, lowest risk, and the least cloud benefit. Good for legacy systems you want out of the data centre first.
- Replatform. Move with small changes, such as swapping a self-managed database for Cloud SQL. Often the best value for a mid-sized business.
- Refactor. Redesign for containers or serverless. Highest effort and highest payoff, justified for products you will keep investing in.
- Repurchase. Replace with software as a service. Sensible for email, CRM or HR systems.
- Retire. Switch it off. Discovery often finds 10 to 20 percent of systems nobody uses, though that range depends on your estate, so measure it rather than assume it.
- Retain. Leave it where it is for now, usually for latency, licensing or regulatory reasons.
A useful rule: rehost to hit a deadline, replatform to cut operating cost, refactor only where the business case is written down.
Phase 3: Build the landing zone before you move anything
The step most checklists bury is the foundation. Create it first:
- Resource hierarchy. An organization, folders for environments and business units, and projects per workload or team.
- Identity and access. Single sign-on, least-privilege roles, multi-factor authentication for every human and tight control on service accounts.
- Networking. Shared VPC design, private connectivity (VPN or Interconnect) to the existing site, DNS plan and firewall policy.
- Logging and monitoring. Central audit logs and alerting live before the first workload lands, not after.
- Guardrails. Organization policies that block public storage buckets, restrict regions and enforce encryption settings.
- Cost controls. Budgets, alerts and labels so every dollar maps to an owner.
This is also where shared responsibility stops being a slide and becomes a set of decisions you own.
Phase 4: Move the workloads
Servers and virtual machines
Migrate to Virtual Machines is Google's tool for moving enterprise workloads onto Google Cloud with minimal risk and downtime. The usual pattern is to replicate, run test clones, fix what breaks, then schedule a short cut-over window.
Databases
For databases, Database Migration Service offers serverless, near-zero-downtime migration to Cloud SQL. For MySQL to Cloud SQL for MySQL, continuous replication carries no extra service charge beyond the resources you consume. Google cites a case in which a 1 TB migration finished with at most 10 minutes of downtime per application. Treat that as an illustration of what is possible, not a promise: your downtime depends on change rate, network capacity and application behaviour.
Before cut-over, test the application against the replica, confirm replication lag is near zero, and rehearse the rollback.
Files and object data
For bulk data, Storage Transfer Service moves data between on-premises storage, other clouds and Cloud Storage. It lets you set a bandwidth limit for on-premises agents, which keeps a migration from starving your office or production traffic. Run the first pass weeks ahead, then sync deltas right before cut-over.
Size the job honestly. Work out the data volume divided by realistic sustained bandwidth (not the circuit's headline speed). If the answer is weeks, plan for it, or look at offline options.
Applications
Application migration is where the earlier dependency map pays off. Move in waves: a low-risk pilot, then groups of related applications. Each wave has an entry checklist (backups verified, owners available, rollback written) and an exit checklist (monitoring green, users confirmed, old system frozen but not yet deleted).
Automate the deployment path
Google's architecture guidance recommends moving toward fully automated, end-to-end deployment pipelines. It admits that this is not trivial, but the payoff is an auditable process with less human error, and the chance to scan for vulnerabilities at every stage of the build, for instance with Artifact Registry.
If your team is stretched, a clear release routine helps even before full automation. This software release checklist with gates, rollback and human checks is a good model for what each deployment stage should prove before the next begins.
Healthcare and regulated data: what changes
If you handle protected health information, the rules tighten. Google Cloud will sign a Business Associate Agreement covering its platform, and Assured Workloads offers Healthcare and Life Sciences control packages that restrict data residency to US locations and support customer-managed encryption keys and Access Transparency logs.
The catch sits on your side. Under the shared responsibility model, you remain responsible for ensuring your own applications and configurations meet HIPAA Security and Privacy Rule requirements. And if you use a service that is not covered by the BAA or the HITRUST CSF, you take on the associated risk and liability. So build an allow-list of in-scope services in the landing zone, and have your compliance officer review it before the first patient record moves. Our own HIPAA-compliant cloud playbook goes deeper, and HITRUST versus HIPAA helps you decide which framework to pursue.
The same logic applies to PCI-DSS, SOC 2 and ISO 27001: map each control to a configuration, an owner and evidence, before go-live rather than before the audit.
A GCP migration checklist
Before you start
- Business case, success measures and executive sponsor agreed
- Full inventory and dependency map complete
- Data classified, regulated systems flagged
- Strategy chosen per workload, with a retire list
- TCO estimate built and timeline adjusted from the defaults
Foundation
- Organization, folders, projects and naming conventions in place
- Identity, MFA and least-privilege roles configured
- Private connectivity and DNS tested
- Central logging, alerting and budgets live
- Guardrail policies and approved-services list enforced
Migration waves
- Pilot workload moved and reviewed
- Backups verified and rollback rehearsed for each wave
- Test clones validated by business owners
- Cut-over window communicated to users
- Old systems frozen, then decommissioned after an agreed period
After go-live
- Right-size instances using real utilization
- Review committed use discounts
- Run a disaster recovery test
- Update runbooks, and hand over to operations
- Report results against the original success measures
For a vendor-neutral version, see our eight-step cloud migration checklist and our deeper GCP migration plan for enterprises.
Phase 5: Optimize after the move
The fourth Google phase is where savings appear, and where many teams stop early. In the first 30 to 90 days:
- Compare actual utilization with what you provisioned, and shrink anything oversized.
- Apply committed use discounts only to steady, predictable workloads.
- Turn off non-production environments outside working hours.
- Review IAM roles that were broad during the migration and tighten them.
- Test restores, not just backups.
Cost spikes after a migration are normal when old and new environments run in parallel. Put an end date on the parallel run.
Our perspective: why migrations stall
We see the same pattern across small businesses, startups and healthcare organizations. The technology rarely blocks a migration. Fragmentation does. One vendor handles the network, another the security tooling, a third the cloud account, and no one owns the outcome when something breaks at 2 a.m.
That is why we built Nexus around consolidation: cloud migration and management across AWS, Azure and Google Cloud, 24/7 threat detection, compliance assessments and backup and disaster recovery under one agreement, with one point of accountability and flat monthly pricing. Google's own guidance on large programs points the same way, recommending a blended team that pairs internal knowledge of your workloads with outside migration expertise to reduce risk and control cost.
Our advice is simple. Do discovery properly, move security and compliance decisions to the start of the plan, and never let a cut-over happen without a rehearsed rollback. A slower first wave is cheaper than a fast failed one.
— Nick - Sr. Executive
Getting help with your migration
If you would rather not build the migration team from scratch, our Cloud Solutions and Compliance & Risk services cover assessment, landing zone design, migration, security monitoring and compliance evidence in a single engagement. Pricing is not published on our site, so contact us through the main site for a scoped conversation about your environment.
If you are still weighing platforms, our guides to AWS migration, Azure migration strategy and multi-cloud strategy cover the alternatives.
FAQ
How long does a GCP migration take?
It depends on scope, not on the tool. Google's Migration Center defaults to a five-year model for large estates, but a small business with a handful of servers can often move in weeks to a few months. Your discovery results and your downtime tolerance set the real schedule.
What are the 7 Rs of cloud migration?
The common list covers rehost, replatform, refactor, repurchase, retire and retain, with relocate added in some versions to make seven. Google's large-scale migration guidance uses a Gartner-style 6 Rs model. Assign one to each application rather than to the estate as a whole.
Can I migrate to GCP without downtime?
Not always, but you can get close for databases. Database Migration Service supports near-zero-downtime migration through continuous replication, so the outage is limited to the final cut-over. Applications with local state or tight hardware ties usually need a planned window.
Is GCP suitable for HIPAA workloads?
Yes, with conditions. Google signs a BAA, but you remain responsible for how your applications and data are configured. Use only services covered by the BAA, and have your compliance officer or a qualified HIPAA adviser review the design.
How do I estimate GCP migration costs?
Start with a Migration Center estimate based on discovered assets, then adjust the timeline and apply committed use discounts where usage is stable. Add one-off costs the tool will not know about: staff time, parallel running, testing and training.
Sources
- Get started with Migration Center, Google Cloud Documentation
- Set up migration timeline and apply discounts, Google Cloud
- What is cloud migration? Google Cloud
- Building a large-scale migration program with Google Cloud (whitepaper)
- Building a large scale migration program, Google Cloud
- Migrate to Virtual Machines, Google Cloud
- Database migration solutions, Google Cloud
- Storage Transfer Service, Google Cloud
- Migrate to Google Cloud: Deploy your workloads
- HIPAA Compliance on Google Cloud
- US Data Boundary for Healthcare and Life Sciences with Support, Assured Workloads