Back to Blog

Migrating to Google Cloud, A Practical Guide

In this article

• Quick Answer
• What are the four phases of a Google Cloud migration?
• How do the six R strategies help sort each workload?
• What does the assessment phase actually cover?
• Why does a landing zone come before any workload moves?
• Which Google Cloud tools move VMs, data, and databases?
• Should you use GKE or Cloud Run after migrating?
• How do you connect on premises to Google Cloud during a migration?
• How can teams migrate with minimal downtime?
• How do you migrate from AWS or Azure to Google Cloud?
• When should an application be modernized with the strangler fig approach?
• Is there funding to help migrate to Google Cloud?
• What do Indian teams need to know about data residency and the DPDP Act?
• What are the most common reasons cloud migrations fail?
• Frequently Asked Questions
• Where Unico Connect fits

Moving to Google Cloud is less about lifting servers and more about deciding what to move, in what order, and how to do it without breaking the business. Done well, it follows a clear framework and a small set of proven strategies. This guide walks through how a Google Cloud migration actually runs in 2026, the tools that do the work, how to keep downtime small, and what Indian teams need to know about data residency.

What are the four phases of a Google Cloud migration?

Google frames a migration in four phases. Assess is where you inventory applications and infrastructure, map dependencies, calculate the total cost of ownership, and benchmark current performance. Plan is where you build the foundation, the landing zone with identity, project structure, and networking, and decide the strategy for each workload. Migrate is where you execute the moves in waves. Optimize is continuous, tuning cost and performance and modernizing after workloads land. Skipping assessment is the most common way migrations go over budget, because the dependencies you did not map are the ones that break.

How do the six R strategies help sort each workload?

The six R strategies are the decision matrix inside the plan phase. Rehost, often called lift and shift, moves a workload with minimal change and is the fastest path. Replatform makes small optimizations on the way, such as moving to a managed database, without rearchitecting. Refactor rewrites the workload around cloud native services for long term scalability. Repurchase swaps a workload for a managed or software as a service equivalent. Retire decommissions applications nobody needs any more. Retain keeps a workload where it is for now. Assigning each workload one of these based on its business value, effort, and risk turns a daunting estate into an ordered plan.

What does the assessment phase actually cover?

Assessment builds the truth you plan against. You inventory every application and its infrastructure, map how they depend on one another, calculate what the current estate costs to run, and record performance benchmarks so you can prove the migration did not regress. Google Migration Center is the hub for this, scanning infrastructure, estimating cloud cost, and mapping application dependencies, with Gemini assistance for dependency analysis and wave planning. The output is a dependency map and a prioritized set of migration waves, not a vague intention to move.

Why does a landing zone come before any workload moves?

A landing zone is the secure, well organized foundation your workloads land in, and building it first prevents a sprawl you will later have to untangle. It sets up the resource hierarchy of organization, folders, and projects, identity and access with least privilege granted to groups rather than individuals, networking with shared virtual private clouds per environment, and organization policies that enforce rules such as restricting public addresses. A common pattern uses separate folders for bootstrap, shared infrastructure, development, and production. Getting this right before the first workload moves is what keeps a growing cloud estate governable.

Which Google Cloud tools move VMs, data, and databases?

Different tools for different workloads. Migrate to Virtual Machines lifts and shifts servers from on premises, VMware, or another cloud into Compute Engine with minimal downtime. Where the estate is VMware, Google Cloud VMware Engine runs the same VMware environment natively on Google infrastructure, so you can move a whole vSphere estate without changing the apps or tooling first and modernize afterwards. For containerization, Migrate to Containers turns virtual machine applications into containers that run on Google Kubernetes Engine or Cloud Run, generating the container and deployment files for you, and its fit assessment tool scores how ready each workload is before you commit. Database Migration Service moves MySQL, PostgreSQL, and SQL Server into Cloud SQL or AlloyDB with continuous replication for a minimal cut over, and for cross engine moves such as Oracle to PostgreSQL it includes a conversion workspace with Gemini for Google Cloud assistance that converts schema and code and suggests fixes. Storage Transfer Service moves large volumes of object and file data into Cloud Storage, with a Transfer Appliance for offline bulk transfer where the network is the bottleneck. Datastream provides change data capture for near real time replication, which is useful right before a cut over. Matching the tool to the workload is most of what makes a migration smooth.

Should you use GKE or Cloud Run after migrating?

Both run containers, and the choice comes down to what the workload needs. Cloud Run is serverless and scales to zero, which suits stateless services and spiky traffic where you do not want to manage infrastructure. Google Kubernetes Engine suits stateful workloads, sidecars, non standard protocols, GPUs, and anything that needs fine control over the runtime. A sensible house pattern is to start a migrated service on Cloud Run and promote it to GKE only when a concrete requirement forces the move, so you carry the operational weight of Kubernetes only where it earns its place.

How do you connect on premises to Google Cloud during a migration?

The connection you choose sets the ceiling on how fast and how safely data moves. Cloud Interconnect gives a private, high bandwidth link, with Dedicated Interconnect scaling up to 400 gigabits per second for a large estate and Partner Interconnect covering smaller needs. Cloud VPN runs over the public internet with encryption, and the high availability configuration carries a 99.99 percent service level for hybrid links that must stay up. For a bulk data set that would take too long over any link, the Transfer Appliance ships the data physically. Decide this early, because discovering mid migration that your connection cannot carry the load is an expensive surprise.

How can teams migrate with minimal downtime?

By keeping the source running until a short, well rehearsed cut over. Continuous replication tools such as Database Migration Service and Datastream let the new environment stay in sync with the old one while it keeps serving traffic, so the actual switch is brief. The discipline around it matters as much as the tooling. Test the migration in a staging project first, validate the plan against Google migration validation guidance, define measurable rollback thresholds so you know in advance what would trigger a reversal, write a cut over runbook, and rehearse the cut over so the real one holds no surprises.

How do you migrate from AWS or Azure to Google Cloud?

A migration from another cloud is mostly a mapping exercise plus the differences in how each cloud models identity and networking. The services line up cleanly for the common cases.

The traps are not in the mapping but in the model. Google Cloud uses a global virtual private cloud where AWS and Azure use regional networks, the identity and access model is organized differently, and egress charges apply as you move data out of the source cloud. Google publishes dedicated getting started guides for both AWS and Azure that are worth following, and the discipline of mapping every service and dependency before moving anything is what keeps the migration predictable.

When should an application be modernized with the strangler fig approach?

When a lift and shift is not enough but a full rewrite is too risky. The strangler fig pattern, described by Martin Fowler and echoed in Google and other cloud guidance, puts a facade in front of the legacy system and moves functionality to new cloud native services one slice at a time, retiring the old pieces as they are replaced. It pairs naturally with the refactor strategy, keeps the system live throughout, and lets each new service prove itself in production before the next slice moves. Our guide on rebuild vs refactor covers how to decide when modernization is worth it at all.

Is there funding to help migrate to Google Cloud?

Often, yes, through the Rapid Migration and Modernization Program. It runs the migration in phases from assessment through to modernization, and it can bring incentives such as Google Cloud service credits, partner funding, and credits for advanced workloads like SAP, Oracle, and VMware. The specifics are set case by case with Google and a partner rather than published as a fixed rate, so treat funding as a real possibility to raise early in the conversation rather than a number to bank on. For an estate of any size it is worth asking about before you scope the project, because it can change the economics of the whole move.

What do Indian teams need to know about data residency and the DPDP Act?

Three things. First, Google Cloud runs regions in Mumbai and Delhi, and resource location policies let you keep data inside India, with Mumbai typically the primary region and Delhi giving in country redundancy. Google also offers an India data boundary control through Assured Workloads that enforces data location and personnel access for regulated workloads. Second, the Digital Personal Data Protection Act 2023 takes a negative list approach to cross border transfers, permitting them to any country except those the government specifically restricts, which is broader than the adequacy model used elsewhere. The final DPDP Rules were notified in November 2025 with a phased timeline, and the major obligations including the cross border provisions land around the middle of 2027, so design for them now rather than treating them as distant. Third, stricter sectoral rules still override the Act, so the RBI payment data localization mandate that requires payment data to be stored only in India, along with rules from SEBI and IRDAI, continue to apply to financial and insurance workloads regardless of what the Act permits.

What are the most common reasons cloud migrations fail?

The failures cluster around a few avoidable mistakes. Lifting and shifting everything without rethinking anything, which carries the old waste and over provisioning straight onto the new bill. Migrating an application before the database or service it depends on, because the dependencies were never mapped. Assuming the identity and networking model from AWS or Azure carries over unchanged. Attempting a big bang cut over with no rollback plan. Carrying security debt across instead of fixing it in the move. And discovering egress and networking costs only after traffic scales. Every one of these is prevented in the planning phases, which is exactly why the assessment and landing zone work matters more than the moves themselves.

Frequently Asked Questions

Where Unico Connect fits

We run Google Cloud migrations as a service. As a certified Google Cloud and Workspace partner, our cloud and DevOps team assesses your estate, builds the landing zone, sorts workloads with the six R strategies, and migrates in waves with minimal downtime, modernizing with the strangler fig pattern where it earns its place. Once you have landed, our Google Cloud cost optimization guide covers keeping the bill under control.