Back to Blog

Google Cloud Migration, a Practical Guide and Checklist for 2026

In this article

• Quick Answer
• Key Takeaways
• What are the four phases of the Google Cloud migration framework?
• How do the six R strategies help sort each workload?
• What does a Google Cloud migration assessment 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?
• What does a Google Cloud migration cost?
• Is there funding to help migrate to Google Cloud?
• What do Indian teams need to know about data residency and the DPDP Act?
• What belongs on a Google Cloud migration checklist?
• What are the most common reasons cloud migrations fail?
• Frequently Asked Questions
• How Unico Connect runs a Google Cloud migration

Copying servers to Google Cloud is the easy part. The hard part is deciding what moves first, what changes on the way, and what should not move at all. Google publishes a four phase framework for making those calls, and this guide follows it for 2026. Along the way it covers what each migration tool charges, how RaMP funding now works, how to keep a cut over short, and the data residency rules that apply in India. If you already know the theory, the checklist is near the end.

What are the four phases of the Google Cloud migration framework?

The Google Cloud Architecture Center names four phases, assess, plan, deploy and optimize. In assess, you inventory applications and infrastructure, map dependencies, work out the total cost of ownership and benchmark current performance. In plan, you build the landing zone, meaning identity, project structure and networking, and choose a strategy for each workload. Deploy is the moves themselves, done in waves. Optimize has no end date. It covers cost and performance tuning, and further modernization, once workloads land.

The Rapid Migration and Modernization Program from Google calls the same journey assess, plan, migrate and innovate, so expect both sets of words in proposals.

How do the six R strategies help sort each workload?

The R strategies are how the plan phase decides what happens to each workload, and two lists are in circulation. The Google Cloud Architecture Center names six migration types.

Rehost, or lift and shift, moves a workload with minimal change and is the fastest path. Replatform, or lift and optimize, makes small changes on the way, such as moving to a managed database. Refactor, or move and improve, modifies the workload to use cloud native features. Rearchitect goes further and changes how the code works so it runs better in the cloud. Rebuild, or remove and replace, redesigns the application from scratch as cloud native. Repurchase swaps it for a software as a service product.

The better known AWS list, now seven Rs, adds three decisions every plan needs. Retire covers applications nobody uses. Retain covers workloads that stay where they are for now. Relocate moves a whole virtualized platform, and the closest Google Cloud equivalent is Google Cloud VMware Engine. Give each workload one strategy based on its business value, effort and risk. For the first wave, we would pick something low risk to rehost or replatform, so the team learns the platform before the difficult workloads move.

What does a Google Cloud migration assessment cover?

Assessment gives you the facts the plan depends on. You inventory every application and the infrastructure under it, map how they depend on one another, work out what the current estate costs to run, and record performance benchmarks so you can later show the migration did not make anything slower.

Google Cloud Migration Center is the hub for this. Its discovery client finds servers and SQL Server, MySQL and PostgreSQL databases, or you can import an RVTools export or an AWS inventory directly. From that inventory it estimates Google Cloud cost and total cost of ownership, maps application and network dependencies, and groups applications into migration waves. Its app modernization assessment goes further and uses Gemini to read source code and recommend changes. That sends your code to the Gemini Enterprise Agent Platform, formerly Vertex AI. Google states the code is not used for training and is not stored by default, but clear it with whoever owns code confidentiality before you run it. By the end you should have a dependency map and an ordered list of migration waves.

Why does a landing zone come before any workload moves?

A landing zone is the foundation your workloads land in, and it is far easier to build first than to retrofit around live systems. It sets up the resource hierarchy of organization, folders and projects. It grants least privilege access to groups instead of individual users. It creates the networking, usually a shared virtual private cloud per environment, and the organization policies that enforce rules such as restricting public IP addresses. A common layout uses separate folders for bootstrap, shared infrastructure, development and production. Treat the landing zone as wave zero of the migration and move nothing onto it until it has been reviewed.

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

Each kind of workload has its own Google tool. For servers, Migrate to Virtual Machines lifts and shifts machines from on premises, VMware or another cloud into Compute Engine with minimal downtime. If the estate runs on VMware, Google Cloud VMware Engine runs the same VMware environment on Google infrastructure, so a whole vSphere estate can move without changing the apps or tooling and be modernized later. Migrate to Containers turns virtual machine applications into containers for Google Kubernetes Engine or Cloud Run, generates the container and deployment files, and has a fit assessment that scores each workload before you commit.

For databases, Database Migration Service moves MySQL into Cloud SQL for MySQL, PostgreSQL into Cloud SQL or AlloyDB, and SQL Server into Cloud SQL for SQL Server, with continuous replication so the cut over is short. It also handles cross engine moves from Oracle or SQL Server to PostgreSQL on Cloud SQL or AlloyDB. There, a conversion workspace uses Gemini to convert schema and code and suggest fixes. Budget real testing time for a cross engine move anyway, because converted code does not always behave like the original.

For files and objects, Storage Transfer Service copies data from Amazon S3, Azure Blob Storage or your own file systems into Cloud Storage, and Transfer Appliance moves it offline when the network is too slow.

Should you use GKE or Cloud Run after migrating?

Both run containers, and Cloud Run now covers more than it used to. It is serverless and scales to zero, which suits stateless services and spiky traffic, and it runs sidecars, up to ten containers per instance, and NVIDIA GPUs. As of September 2026, Google offers Cloud Run GPUs in Delhi (asia-south2), and in Mumbai (asia-south1) by invitation only. Google Kubernetes Engine still suits stateful workloads, non standard protocols and anything that needs fine control over nodes, networking or the runtime. It also carries a cluster management fee. GKE charges $0.10 per cluster hour in every mode, and the free tier covers one Autopilot or zonal Standard cluster per billing account.

For a migrated stateless service, we would start on Cloud Run and move to GKE only when a concrete requirement forces it, such as a protocol Cloud Run cannot serve or a need to control the nodes. That keeps the operational weight of Kubernetes on the few services that need it. A white label travel insurance microsite we built runs this way on Cloud Run, so its hosting cost follows usage.

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

The connection sets the ceiling on how fast data can move, so size it before the plan is final. Cloud VPN runs encrypted over the public internet. HA VPN carries a 99.99 percent availability SLA for most topologies, but each tunnel handles roughly 1 to 3 gigabits per second, which suits steady hybrid traffic better than bulk copies. Dedicated Interconnect gives a private link built from 10, 100 or 400 gigabit per second circuits, up to eight per connection, with a 99.99 percent SLA in the critical production configuration. Partner Interconnect reaches Google through a service provider for smaller capacity needs. In India, Google lists Dedicated Interconnect colocation facilities in Mumbai, Delhi, Noida, Chennai and Hyderabad.

Then do the arithmetic. The Google guide to large data transfers estimates that 100 TB takes over 10 days to send on a 1 gigabit per second link and over 100 days on 100 megabits per second. If the upload would take more than a week, Google points to Transfer Appliance, which it ships in India.

How can teams migrate with minimal downtime?

Keep the source running until a short, rehearsed cut over. Google describes four data migration approaches, and each trades downtime against refactoring effort.

• Scheduled maintenance, also called a big bang migration, copies the data and switches during a planned window. It is the simplest, and it has the longest outage.
• Continuous replication keeps the new environment in sync while the old one keeps serving traffic, so the window shrinks to the final catch up. Database Migration Service provides it for the databases it supports.
• Y writing and reading has the application write to and read from both environments during the transition, which takes significant refactoring.
• A data access microservice puts one service in front of the data so the storage underneath can move without callers noticing. Google calls it the preferred option in a microservices architecture.

For a database that Database Migration Service supports, we would start with continuous replication. Whichever approach you pick, test the migration in a staging project first and write a cut over runbook. Give every step a maximum execution time and roll back when it runs over, instead of improvising. Lower the DNS time to live well before the switch, then rehearse the cut over before you run it for real.

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

Moving from AWS or Azure is mostly a mapping exercise. EC2 and Azure Virtual Machines go to Compute Engine, EKS and AKS to Google Kubernetes Engine, S3 and Blob Storage to Cloud Storage, RDS and Azure SQL to Cloud SQL or AlloyDB, and Redshift and Synapse to BigQuery. The design work is in networking and identity. A Google Cloud VPC is global with regional subnets, while AWS and Azure networks are regional, so the address plan and firewall rules have to be redesigned. Identity is organized around an organization, folders and projects, which is a different shape from AWS accounts or Azure subscriptions. For an AWS estate, the full service mapping, cost drivers and India specifics are in our guide to AWS to Google Cloud migration in India. For an Azure estate, Azure to Google Cloud migration covers the same ground.

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

The strangler fig pattern, described by Martin Fowler and documented as a cloud design pattern by AWS and Microsoft, puts a facade in front of the legacy system and moves functionality to new cloud native services one slice at a time. Old pieces are switched off as their replacements go live. It fits the case where a lift and shift will not fix the application but a full rewrite is too risky to attempt in one go. The system stays live throughout, and each new service proves itself in production before the next slice moves. If you are not yet sure modernization is worth doing at all, read our comparison of rebuild vs refactor first.

What does a Google Cloud migration cost?

A Google Cloud migration carries four kinds of cost, the migration tools, leaving the old platform, engineering time with a period of parallel running, and the bill for running on Google Cloud afterwards. The tools are usually the smallest of the four. Google charges nothing for several of them, as the table below shows. Its figures come from the official pricing pages, such as Migrate to Virtual Machines pricing, as of September 2026.

What the Google Cloud migration tools charge, September 2026

What the Google Cloud migration tools charge, September 2026

Tool	What it moves	Charge for the tool itself
Migrate to Virtual Machines	Servers from VMware, AWS and Azure into Compute Engine	No charge for migrations into Google Cloud. Compute Engine, storage and networking used for testing are billed, and on a move from AWS or Azure the source cloud bills the instances, disks and traffic the tool uses there
Database Migration Service, same engine	MySQL into Cloud SQL, PostgreSQL into Cloud SQL or AlloyDB	No additional charge
Database Migration Service, cross engine	Oracle or SQL Server into Cloud SQL or AlloyDB for PostgreSQL	Billed per GiB processed. Change data capture on tiered rates, backfill at a flat rate after a free monthly allowance
Storage Transfer Service, agentless	Amazon S3, Azure Blob Storage and other cloud sources into Cloud Storage	No charge for the service. Cloud Storage operations apply, and the source cloud bills its data transfer out
Storage Transfer Service, agent based	On premises file systems into Cloud Storage	$0.0125 per GiB, plus network and storage operation charges

The cloud you are leaving will waive data transfer out charges if you ask its support team before you move, but the terms differ. AWS covers a move of all your data off AWS, or off one AWS service, and gives you 90 days to finish, but do not start any part of the move before AWS approves your credit request. Microsoft credits internet egress only, for up to 60 days, and only when you leave Azure entirely, so open an Azure Support request before you move and cancel all your Azure subscriptions before you claim the credit. Leaving your own data centre costs something different, extra bandwidth or a Transfer Appliance.

Engineering time is usually the biggest line. It covers the assessment, the landing zone, each migration wave, any rewrites, and the period when both environments run side by side while traffic shifts. The Google migration best practices advise agreeing the conditions for retiring the source environment before you start, so that period has an end.

The fourth cost is the running bill. Accounts with an Indian billing address are billed in INR by Google Cloud India Private Limited, with 18 percent GST on the invoice, and a registered business that adds its GSTIN can claim input tax credit. How to estimate that bill and pay it from India is in our guide to Google Cloud pricing and billing in India.

Nobody can quote the total before an assessment. Treat a proposal that promises a fixed saving without looking at your estate as a sales pitch.

Is there funding to help migrate to Google Cloud?

Yes, if the estate is big enough. Google Cloud funds qualifying migrations through its Rapid Migration and Modernization Program, RaMP. It published new incentives in January 2026, and its RaMP user guide now sets out the rules in detail.

A RaMP assessment of the current estate qualifies the project, and each workload needs a projected annual run rate of at least $60,000, meaning the eligible new Google Cloud spend it is expected to run at each year once fully migrated. The assessment is a data driven review that also produces a total cost of ownership and ROI analysis. You then sign a RaMP Agreement and tag each workload, because Google calculates and pays incentives only on tagged workloads.

A general workload is eligible for service funds of up to 20 percent of its projected annual run rate, capped at $2 million, which Google pays toward approved partner work as statement of work and spend milestones are met, or toward Google Cloud Consulting services. It is also eligible for Google Cloud credits of 25 percent of its incremental eligible spend each quarter, up to a total of 30 percent of the projected annual run rate or $3 million, whichever is lower, across the three years of the agreement. Credits are paid only while the tagged workloads keep growing, they land in the primary invoiced billing account within 45 days of each quarter end, and unused incentives expire 12 months after they are issued. Specialised workload types such as VMware, Oracle and SAP carry higher percentage rates, and SAP moves get a dedicated partner fund in place of credits. Spend on Marketplace products, support, subscriptions, GPUs, archival storage and Google Distributed Cloud does not count. Google sets the terms and decides who qualifies, so raise RaMP before the migration is scoped.

The $60,000 per workload threshold is the filter that matters. A mid sized or larger estate can clear it. A smaller move should be planned and budgeted as if no funding will come. When you buy Google Cloud through Unico, Unico is the party to the RaMP agreement with Google, so ask us whether your migration qualifies. If you pay Google directly, check early how the credits will reach you. Credits go into an invoiced billing account, and Google sets its own requirements for invoiced billing, so if you still pay by card or UPI, confirm with Google how your credits will be applied before you count on them. Startups building something new should look instead at the startup credit programme in our guide to the Google Cloud free tier and credits in India.

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

Start with where the data sits. Google Cloud runs two regions in India, Mumbai as asia-south1 and Delhi as asia-south2, and a resource locations organization policy keeps data inside them. Mumbai is usually the primary region, with Delhi for in country redundancy. For regulated workloads, the Assured Workloads India Data Boundary control package limits data location to Indian regions and sits in the free tier of Assured Workloads. Treat it as a residency control only. Other packages, such as EU Data Boundary and Support, Canada Data Boundary and Support, and US Data Boundary and Support, also restrict where support staff are located, and India has no such package.

The DPDP Act does not require personal data to stay in India. Section 16 of the Digital Personal Data Protection Act 2023 allows cross border transfers to any country except those the government restricts, a negative list where Europe uses an adequacy model. The DPDP Rules were notified on 13 November 2025 and phase in over 18 months, so Rule 15 on cross border transfers applies from May 2027 along with most other obligations. From the same date, Rule 13 lets the government name personal data that a Significant Data Fiduciary must keep in India, so find out whether your company has been notified as one. Check the current position when you design.

The rules that bind today are the sector ones. Section 16(2) keeps stricter sectoral laws in force. The Reserve Bank of India circular of 6 April 2018 requires payment system data to be stored only in India, and SEBI and IRDAI requirements still apply to financial and insurance workloads. If a workload touches payments, pin it to Indian regions before any data moves.

What belongs on a Google Cloud migration checklist?

The checklist follows the order of the Google Cloud Architecture Center migration guides and adds the India items that generic checklists leave out. Everything under Assess and Plan should be done before the first workload moves.

Assess

• Inventory every workload. List each application, its dependencies, supporting services and any hardware appliances. Migration Center can build this from its discovery client, an RVTools export or a direct AWS import.
• Categorize by complexity and risk. Rank workloads so the first wave is low risk and teaches the team the platform.
• Prove the risky parts. Run a proof of concept for each workload category before committing to a plan.
• Calculate total cost of ownership. Compare the current estate with the projected Google Cloud cost, including operations, and record performance benchmarks to test against later.
• Check RaMP eligibility early. A RaMP assessment is what qualifies a project for funding, and each workload needs a projected annual run rate of at least $60,000 of eligible Google Cloud spend.

Plan and build the foundation

• Build the landing zone. Organization, folders and projects, IAM roles granted to groups, a shared VPC per environment, and organization policies.
• Pin data to India. Restrict resource locations to asia-south1 and asia-south2, and apply the Assured Workloads India Data Boundary package where a regulator expects it.
• Set up billing before the first invoice. Add your GSTIN and set budgets and alerts. RBI rules require extra authentication for any automatic card or UPI charge above 15,000 INR, so a growing bill needs a manual payment by card, NetBanking or UPI, or invoiced billing.
• Size the connection. An HA VPN tunnel carries roughly 1 to 3 gigabits per second. If uploading your data would take more than a week, plan for Cloud Interconnect or a Transfer Appliance.
• Write a rollback plan for every step. Give each step a maximum allowed execution time, after which the team rolls back.

Deploy

• Pick a data migration approach per database. Scheduled maintenance, continuous replication, Y writing and reading, or a data access microservice, each trading cut over time against refactoring effort.
• Move in dependency order. Nothing moves before the database or service it depends on, and replication keeps running until each cut over is proven.
• Tag RaMP workloads. Incentives are calculated and paid only on tagged workloads.
• Rehearse the cut over. Run it in a staging project first, then run the real one from a written runbook.

Optimize and retire

• Define when the source can be switched off. Google lists conditions such as every workload, backup and disaster recovery mechanism migrated, the data verified as consistent and accurate, and nothing left in the source that other systems depend on.
• Rightsize and commit. Once usage is steady, resize machines to fit it and cover the steady base with committed use discounts. Our Google Cloud cost optimization guide covers the levers.

What are the most common reasons cloud migrations fail?

Migrations that go wrong tend to go wrong in the same few ways, and each of these can be caught in the assess and plan phases.

• Lifting and shifting everything unchanged, which carries the old over provisioning straight onto the new bill.
• Moving an application before the database or service it depends on, because nobody mapped the dependencies.
• Assuming the AWS or Azure identity and network design carries over as it is.
• A big bang cut over with no rollback plan.
• Carrying security debt across instead of fixing it during the move.
• Finding egress and networking costs only after traffic grows.

Frequently Asked Questions

How Unico Connect runs a Google Cloud migration

Unico Connect is a certified Google Cloud partner and reseller in India, based in Mumbai. Our cloud and DevOps team runs Google Cloud migrations the way this guide lays them out, and once you land we can bill your usage in INR with GST and handle cost optimization and managed operations. Among the systems we built on Google Cloud, Highlands Brain, an AI powered learning platform for a charter school network in California, serves more than 15,000 students.