What Is Google Cloud Migration? A Secure Guide

The first incident after a Google Cloud migration is rarely a novel exploit. It is a Cloud Storage bucket that was an internal file share on-prem, recreated with allUsers granted read. It is a service account that ran a batch job in the data center, rehosted with the Owner role and a long-lived JSON key now sitting in a repo. It is a workload whose on-prem logging never made it to Cloud Logging, so the first sign of compromise is a billing alert for crypto mining. None of these need a clever attacker. They are configuration and visibility that did not survive the move to Google Cloud.

Google Cloud migration is the process of moving applications, data, and workloads from on-premises infrastructure, or from another cloud, into Google Cloud. Google documents the work as four phases and a set of per-workload migration types, and it ships a specific tool and security control for each. Done well, a migration is a planned change with a discovery inventory, a type assigned to each workload, and a security posture that is built into the destination. Done as a deadline-driven lift and shift, it copies every insecure default into a platform with a public management API and a wider blast radius. This guide covers what Google Cloud migration is, the six migration types and four phases Google uses, the security risks the move introduces, and a secure approach for the team that has to defend the result.

What is Google Cloud migration?

Google Cloud migration moves compute, storage, applications, and data off infrastructure you run yourself and onto infrastructure Google runs for you. The unit that moves is a workload: an application plus its data, dependencies, and the identities and access it needs to run. A migration is rarely a single workload. It is a portfolio, dozens to thousands of applications, each of which has to be discovered, assessed, assigned a migration type, moved, validated, and cut over.

Google Cloud has its own shape that the move has to account for. Compute Engine runs virtual machines, Google Kubernetes Engine (GKE) runs containers, Cloud Storage holds objects, and BigQuery, Cloud SQL, and AlloyDB hold data. Access to all of it is governed by Google Cloud Identity and Access Management (IAM), and the resource hierarchy (organization, folders, projects) is where access and policy are actually enforced. A migration that ignores that hierarchy ends up with flat, over-permissioned projects that are hard to secure later.

The reason migration is a security event, not just an infrastructure project, is that the move changes three things at once. It changes where the workload runs, so the controls that protected it (network segmentation, physical access, an on-prem firewall) no longer apply. It changes how the workload is administered, from console-and-cable to a Google Cloud API any holder of a credential can call. And it changes who is responsible for what, because Google now owns part of the stack and you own the rest. A migration plan without a security plan is incomplete.

A migration also rarely happens all at once. For weeks or months a workload runs in both places while data syncs and traffic shifts. That dual-running window is its own risk surface, and it is one the plan has to account for rather than discover.

The migration types and the four phases

Google does not use the AWS "7 Rs." Per Google's Migrate to Google Cloud guidance, the documented migration types are rehost, replatform, refactor (move and improve), re-architect, rebuild, and repurchase. They are not a ranking. Each workload gets the type that meets its goals, and the type you pick drives the security work the move requires.

Rehost (lift and shift) moves the application to Google Cloud with no changes, typically using Migrate to Virtual Machines to bring on-prem VMs into Compute Engine. It is the fastest path, and the one that carries every existing weakness across intact: the same OS version, the same open ports, the same local accounts, now in an environment with a far larger attack surface. Rehost without a hardening pass is how on-prem debt becomes cloud exposure.

Replatform (lift and optimize) moves the application with some optimization, for example moving a self-managed database onto Cloud SQL or AlloyDB during the move, or upgrading the OS. It is the chance to shed some of the debt rehost would carry and to hand patching of the data tier to a managed service.

Refactor (move and improve) changes the application to better fit the cloud without a full rewrite, for example containerizing a service onto GKE. It lets you start adopting cloud-native identity and managed encryption.

Re-architect redesigns the application around cloud-native services. It is the most expensive and complex type, and Google scopes it as a longer modernization effort, not a same-window move. Done deliberately, it lets you build security in (Workload Identity, encryption by default, fine-grained IAM) rather than bolt it on.

Rebuild (remove and replace) discards the existing application and writes a new cloud-native one. The legacy code and its accumulated vulnerabilities are left behind, but the new build has to be secured from scratch.

Repurchase (drop and shop) replaces the application with a different product, usually a SaaS equivalent. Vet the new product against your security and compliance requirements before buying, and federate it into Cloud Identity rather than creating a new credential silo.

Across the types, Google organizes the work into four phases: assess, plan, deploy, and optimize. Assess discovers and inventories the estate and builds the business case. Plan lays the foundation: the resource hierarchy, networking, and IAM. Deploy moves the workloads. Optimize tunes them once they run in production. The security work threads through all four, and the cheapest place to get it right is the assess and plan phases, before any workload has moved.

Migration types and their security implications

The type is a security decision before it is a cost decision. The table maps each Google Cloud migration type to what it does and the security work it demands.

The pattern: the less you change, the more inherited risk you carry, and the more the post-move hardening matters. Rehost moves the workload and its problems together. The more transformative types trade effort for the chance to fix things on the way, but each new build still has to be secured deliberately.

The security risks a Google Cloud migration introduces

A migration introduces risk in two phases: during the move, while two environments run at once and configuration is in flux, and after it, once the workload lives in a platform with different defaults and a different blast radius. The recurring failures cluster into a handful of patterns.

Misconfiguration in the new environment. The most common cause of cloud incidents is not a provider flaw, it is a customer configuration mistake: a Cloud Storage bucket made public with an allUsers IAM binding, a firewall rule open to 0.0.0.0/0, audit logs never enabled, default encryption left unmanaged. A migration creates a flood of new resources fast, and each one is a chance to get the configuration wrong. Cloud vulnerabilities introduced this way are the single largest category of post-migration exposure.

A larger attack surface. On-prem, a workload often sat behind a network perimeter that hid its weaknesses. In Google Cloud the management plane is an API reachable from anywhere, every external IP is internet-facing by default, and the attack surface is wider than the team is used to reasoning about. Controls that relied on "you have to be inside the network" stop working the moment the network boundary is gone.

IAM mistakes. Cloud access is identity, not network location. A migration is where over-broad roles (the primitive Owner and Editor roles, wildcard permissions), long-lived service account keys, and human accounts doing machine work get created in bulk under deadline pressure. An over-permissioned identity in Google Cloud is the equivalent of the over-provisioned account on-prem, except it is reachable through a public API. Granting Owner where a predefined role would do is the migration mistake that recurs most.

Data exposure in transit and at rest. Data moves in bulk during a migration, often over links that were not designed for it, and lands in storage whose key management defaults differ from the source. Google Cloud encrypts data at rest by default, but unmanaged keys, snapshots copied to a less protected project, and replication traffic that is not protected all expose data the on-prem system kept inside its walls.

Compliance and data-residency gaps. Moving regulated data into a new region or jurisdiction can break a compliance obligation the on-prem deployment satisfied by location alone. A migration is where data-residency, sovereignty, and personnel-access requirements have to be re-established in the new platform rather than assumed.

Temporary dual-environment gaps. While a workload runs in both places, you have two attack surfaces, two sets of credentials, and sync links between them that are themselves a target. Controls and monitoring are often applied to the destination but not the transitional plumbing, so the migration window is frequently the least-monitored period in a workload's life.

Lost visibility. Detection that worked on-prem does not automatically follow the workload. Endpoint agents are not reinstalled, Cloud Audit Logs and VPC Flow Logs are not enabled, and the SIEM is not pointed at the new sources. The workload moves and the security team goes partially blind, which is how a misconfiguration becomes a data breach that nobody saw coming.

The shared responsibility and shared fate model

The single most consequential change a migration makes is to who is responsible for security. On-prem, you owned everything: the building, the hardware, the hypervisor, the OS, the application, the data. In Google Cloud, Google takes part of that stack and hands you the rest, and how much it takes depends on the service model. A rehosted Compute Engine instance leaves you responsible for the guest OS, patching, and everything above it. A managed service like Cloud Storage or a serverless function shifts more of the stack to Google. A migration usually mixes both, so the responsibility boundary is different for different workloads in the same project.

Google frames this with two terms. Shared responsibility draws the line between what Google secures (the hardware, the network, the facilities, the managed services) and what the customer secures (configuration, IAM, data, and the workloads they run). Google then extends it with what it calls "shared fate": Google does not just point at the line, it provides secure-by-default blueprints, posture management, and risk-protection offerings to help the customer hold up their side. The frame is useful, but it does not move the line. The misconfigured bucket and the over-permissioned service account are still on the customer's side of it.

The failure mode is assuming Google covers more than it does. "It is in Google Cloud, so it is secure" is the sentence that precedes the public-bucket incident. Google secures the floor. Everything you build on it is yours, and a migration is the moment to write down, per workload, exactly where the line falls.

A secure Google Cloud migration approach

Securing a migration is not a final gate before cutover. It runs through all four phases, from the assessment you build before you move anything to the validation you run before you trust the result. The steps below are the practitioner's spine, mapped to Google Cloud's own tooling.

Assess and inventory first. You cannot secure what you have not enumerated. Use Migration Center to discover the estate, then build a complete inventory of applications, data, dependencies, and identities before assigning types, and classify data by sensitivity so the high-value workloads get the most scrutiny. A formal cloud security assessment at this stage sets the baseline the rest of the migration is measured against.

Lay the foundation in the plan phase. Design the resource hierarchy (organization, folders, projects) so that policy and access can be enforced at the right level, and design the network (VPCs, Shared VPC, firewall rules) before workloads arrive. The defaults you set here are inherited by everything that moves later, which makes this the highest-leverage security work in the whole migration.

Least-privilege IAM from the start. Use predefined or custom roles scoped to the specific actions and resources each workload needs, never the primitive Owner or Editor roles. Prefer Workload Identity and short-lived credentials over long-lived service account keys, and use IAM Recommender to find and remove the grants nobody uses. Identity is the new perimeter; getting it right at migration time is far cheaper than walking back over-broad grants later.

Encrypt in transit and at rest, manage the keys. Google Cloud encrypts data at rest by default, so the failure here is not lacking encryption, it is not managing the keys. Use Cloud KMS and customer-managed encryption keys (CMEK) for sensitive data, protect the migration traffic itself, and confirm snapshots and backups inherit the key policy. Encryption choices are a deep topic in their own right; the migration decision is to make them deliberately rather than by default.

Set perimeters and compliance controls. Use VPC Service Controls to build a service perimeter around sensitive data so a leaked credential cannot exfiltrate it, and use Assured Workloads where a regulatory framework requires region, personnel, or key restrictions. These controls are far easier to apply as the data lands than to retrofit afterward.

Stand up Security Command Center from day one. Security Command Center is Google Cloud's posture and threat platform: it continuously scans for misconfiguration and drift, inventories assets, and detects threats. Deploy it as resources are created, not after, so the public bucket and the over-broad role are caught as they appear rather than in a quarterly audit.

Wire up logging and monitoring before cutover. Enable Cloud Audit Logs and VPC Flow Logs, reinstall endpoint agents on migrated hosts, and point the SIEM at the new sources before the workload goes live, not after the first incident. The migration is the moment to fix the visibility gap, because it is the moment the gap is created.

Validate before you trust the cutover. Before shifting production traffic and decommissioning the source, verify the security state: scan for exposed resources, confirm encryption and logging are on, test the IAM boundaries, and check that detection fires on the new workload. Cut over once the destination is verifiably as secure as the source, then decommission the old environment so it stops being an unmonitored second attack surface.

Frequently Asked Questions

What is Google Cloud migration?

Google Cloud migration is the process of moving applications, data, and workloads from on-premises infrastructure, or from another cloud, into Google Cloud. The unit that moves is a workload: an application plus its data, dependencies, and the identities it needs. A migration is usually a portfolio of many workloads, each discovered, assessed, assigned a migration type, moved, validated, and cut over.

What are the migration types and phases Google Cloud uses?

Google documents six migration types: rehost (lift and shift), replatform (lift and optimize), refactor (move and improve), re-architect, rebuild (remove and replace), and repurchase. It organizes the work into four phases: assess, plan, deploy, and optimize. This differs from the AWS "7 Rs"; Google does not use the retain, retire, and relocate categories.

How is Google Cloud migration different from AWS or Azure migration?

The strategy is the same shape across providers, but the tools and controls are specific to Google Cloud: Migration Center for discovery, Migrate to Virtual Machines for VMs, Database Migration Service for databases, and Cloud SQL, GKE, and BigQuery as targets. Security runs through Google Cloud IAM, Security Command Center, VPC Service Controls, and Cloud KMS. Google also uses the migration-type names rehost, replatform, refactor, re-architect, rebuild, and repurchase rather than the AWS 7 Rs.

Why does a Google Cloud migration create security risk?

A migration changes where a workload runs, how it is administered, and who is responsible for its security, all at once. That removes the network perimeter that was compensating for weak controls, exposes the management plane as a public API, and creates a flood of new resources that can be misconfigured. Lift and shift carries existing weaknesses into a larger attack surface, and detection often does not follow the workload, leaving a visibility gap.

What is the most common Google Cloud migration security mistake?

Misconfiguration in the new environment: Cloud Storage buckets made public with an allUsers binding, firewall rules open to the internet, audit logs never enabled. The runner-up is over-broad IAM, especially granting the primitive Owner or Editor roles instead of scoped predefined roles, and leaving long-lived service account keys in place. Both are customer-side mistakes, not Google flaws.

What does the shared responsibility model mean for Google Cloud migration?

Google secures the underlying infrastructure, network, facilities, and managed services; the customer secures configuration, IAM, data, and the workloads they run. The exact line moves with the service: a rehosted virtual machine leaves you responsible for the guest OS and everything above it, while a managed or serverless service shifts more to Google. Google extends this with a "shared fate" model that adds secure-by-default blueprints and posture tooling, but the line itself does not move.

How do you secure a migration to Google Cloud?

Discover and classify everything in the assess phase, then lay a secure foundation in the plan phase: resource hierarchy, networking, and least-privilege IAM using predefined roles and Workload Identity rather than primitive roles and long-lived keys. Manage encryption keys with Cloud KMS, set VPC Service Controls perimeters, stand up Security Command Center and Cloud Audit Logs from day one, and validate the security state before cutover.

The bottom line

Google Cloud migration moves applications, data, and workloads off infrastructure you run and onto infrastructure Google runs, and the way you move each workload (rehost, replatform, refactor, re-architect, rebuild, repurchase) decides how much security work the move demands. The less the workload changes, the more inherited risk it carries, which is why rehost needs a hardening pass and every rebuild has to be secured from scratch. Google organizes the work into four phases, assess, plan, deploy, and optimize, and the cheapest place to get security right is assess and plan, before any workload has moved.

The risk is concentrated in two places: the configuration of the new environment, where public buckets, open firewall rules, over-broad IAM, and unmanaged keys are the recurring failures, and the visibility gap, where detection does not follow the workload. The shared responsibility model, and Google's shared fate extension of it, is the frame that explains both: Google secures the floor, and everything you build on it is yours. A secure migration treats security as a thread through every phase, discovery, foundation, least-privilege IAM, key management, service perimeters, posture management, logging, and a validated cutover, rather than a gate at the end. The migration is the cheapest moment to get the configuration right, and the most expensive one to get it wrong.