Migrating to Google Cloud
Google Cloud has its own map for moving into the "Google district" of Cloudville. It gives you a big-picture framework, a tidy four-phase path, and a matching toolbox for each phase. In this lesson we walk the whole route — from counting your furniture at Fort Rusty to tuning costs once everything has landed in the cloud.
Imagine three big moving companies live in the same city, and today you picked the Google one. They hand you a checklist ("first look at your stuff, then make a plan, then move it, then settle in") and a truck for every kind of box — one for furniture, one for photo albums, one for the fish tank. Google Cloud is that moving company, and this page is their checklist and their trucks.
The Google Cloud Adoption Framework
☺ Like you’re 10: Before you move, Google checks if your family is actually ready — do you know where things are, do you have money set aside, does everyone agree it’s time to go?
The Google Cloud Adoption Framework is Google’s way of asking "how ready are you for the cloud, really?" before anyone touches a single server. It’s a mirror, not a to-do list: it tells you where the gaps are so your migration doesn’t stall halfway. Think of it as Professor Owl’s "are we ready to move?" report card, which you fill in before you hire the trucks.
The four readiness themes
Instead of only listing steps, the framework scores your readiness across a handful of themes — commonly summarised as Learn (do your people have cloud skills?), Lead (is leadership behind this?), Scale (can you automate and grow?), and Secure (are your controls in place?). Two more threads, people and process, run through all of them — every theme is really a question about the humans and the habits behind the technology.
The three maturity levels
The framework rates each theme at one of three maturity levels — Tactical (short-term, ad-hoc), Strategic (a plan is forming), and Transformational (cloud is now how you work). Scoring each theme against these levels shows you, at a glance, which readiness gaps to close before the trucks arrive rather than mid-move.
The Adoption Framework measures organisational readiness (skills, leadership, security, scale). The four-phase path below is the actual moving journey. You use the first to prepare, and the second to execute.
The four-phase migration path
☺ Like you’re 10: Look at your stuff, make a plan, do the move, then unpack and make it nice. Four steps, in that order.
Google describes the migration itself as a four-phase journey — the same shape as our general migration journey, just with Google’s names. The diagram below is the map; the four subsections under it walk each phase in turn.
Assess — count before you pack
☺ Like you’re 10: First you walk around and write down everything you own, and what it all really costs to keep.
In the Assess phase you inventory your applications and infrastructure, map the dependencies between them, and calculate the total cost of ownership (TCO: the full price of running something, including licences, power, and staff, not just the sticker price). This is Nutty the Squirrel’s "count before you pack" phase — you can’t plan a move until you know exactly what you have and what it truly costs. The tool that does the heavy lifting here is Migration Center (see the toolbox below).
Plan — build the foundation you land on
☺ Like you’re 10: Set up the new house and decide, room by room, what happens to each piece of furniture.
In the Plan phase you build the foundation you’ll land on: identity, project structure, and networking, together known as the landing zone. You also decide the strategy for each workload using the 7 R’s (rehost, replatform, refactor, and so on), so every app has a named plan before anyone moves it.
Deploy — move the workloads in waves
☺ Like you’re 10: Now you actually carry the boxes — a few rooms at a time, never the whole house in one go.
In the Deploy phase you actually move the workloads, in small waves rather than all at once, so any problem only ever affects one batch. Google sometimes calls this phase "Migrate." If some of your systems already live in another cloud, this is also where a cloud-to-cloud move happens.
Optimize — tune, then keep tuning
☺ Like you’re 10: Once everything’s moved in, you rearrange, save on the bills, and keep making it nicer — forever.
Once things have landed, the Optimize phase tunes cost and performance and modernises workloads that are ready for it. Unlike the earlier phases, this one never really ends — you keep right-sizing and improving for as long as the workload lives in the cloud.
The Google Cloud toolbox, phase by phase
☺ Like you’re 10: Each step of the move has its own special truck. Here’s which truck to grab for which job.
Benny’s favourite part: every phase has matching Google tools. Here’s the toolchain mapped to the four phases. (These are examples of what Google Cloud offers — the other providers have their own equivalents, covered on the AWS and Azure pages, and the provider-neutral view lives in the general toolbox.)
| Phase | Job to do | Google Cloud tool | What it does (in plain words) |
|---|---|---|---|
| Assess | Discovery, assessment & TCO | Migration Center | The central hub. Scans your on-prem servers and databases, maps dependencies, groups assets, and generates a TCO report you can export to Sheets or Slides. |
| Deploy | Server migration | Migrate to Virtual Machines | Lifts whole VMs (from VMware, AWS, Azure, or on-prem) into Compute Engine with near-zero downtime. Formerly "Migrate for Compute Engine," and before that "Velostrata." |
| Deploy | Database migration | Database Migration Service (DMS) | Moves databases (like MySQL, PostgreSQL, SQL Server, or Oracle) into Cloud SQL or AlloyDB, using continuous replication so the old and new stay in sync until cutover. |
| Deploy | Data transfer — offline | Transfer Appliance | A physical storage box Google ships you. You fill it with data and mail it back — for when you have too much data to send over the wire in reasonable time. |
| Deploy | Data transfer — online | Storage Transfer Service | Moves large sets of files into Cloud Storage over the network, from other clouds or on-prem, on a schedule. |
| Optimize | Modernization | Migrate to Containers | Turns VM-based apps into containers running on GKE or Cloud Run — without rewriting the app. Formerly "Migrate for Anthos." |
| Plan | Landing zone | Landing zones + Resource Manager | Sets up your foundation: an organization with folders and projects, IAM identities, and Organization Policy guardrails to keep everything tidy and safe. |
Discovery & assessment — Migration Center
Migration Center is the central hub for the Assess phase. What it does: scans your on-prem servers and databases, maps dependencies, groups assets, and generates a TCO report you can export to Sheets or Slides. When to use it: right at the start, before you move anything — it’s how you turn a fuzzy data center into a counted, mapped inventory.
Server migration — Migrate to Virtual Machines
Migrate to Virtual Machines lifts whole VMs (from VMware, AWS, Azure, or on-prem) into Compute Engine with near-zero downtime. When to use it: for rehost ("lift-and-shift") moves where you want the server to arrive in the cloud unchanged. It was formerly "Migrate for Compute Engine," and before that "Velostrata." Because it can pull from AWS or Azure too, it doubles as a cloud-to-cloud tool.
Database migration — Database Migration Service (DMS)
Database Migration Service (DMS) moves databases (like MySQL, PostgreSQL, SQL Server, or Oracle) into Cloud SQL or AlloyDB, using continuous replication so the old and new stay in sync until cutover. When to use it: whenever a database has to move with minimal downtime — the replication keeps the live system running right up to a quiet-night switch.
Data transfer — Transfer Appliance & Storage Transfer Service
Two tools move bulk data, and the right one depends on how much you have and how fast your link is.
- Transfer Appliance — a physical storage box Google ships you. You fill it with data and mail it back. When to use it: when you have too much data to send over the wire in reasonable time (the offline route).
- Storage Transfer Service — moves large sets of files into Cloud Storage over the network, from other clouds or on-prem, on a schedule. When to use it: when your network link is fast enough and you want an automated, repeatable online transfer.
Modernization & containers — Migrate to Containers
Migrate to Containers turns VM-based apps into containers running on GKE or Cloud Run — without rewriting the app. When to use it: in the Optimize phase, once a workload has landed and you’re ready to modernise it. It was formerly "Migrate for Anthos."
Foundation & landing zone — Landing zones + Resource Manager
Landing zones + Resource Manager set up your foundation: an organization with folders and projects, IAM identities, and Organization Policy guardrails to keep everything tidy and safe. When to use it: in the Plan phase, before any workload moves. This one is important enough that the next section, Building the landing zone, walks through it in detail.
Google renames tools often. "Migrate to Virtual Machines" was "Migrate for Compute Engine" and originally "Velostrata"; "Migrate to Containers" was "Migrate for Anthos." If you read an old blog post, the tool may still exist — just under a newer name.
Building the landing zone
☺ Like you’re 10: Before the trucks arrive, you set up the new house — who has keys, which rooms are which, and the house rules. That’s the landing zone.
A landing zone is the pre-built, secure foundation your workloads land on, so you’re not making it up as boxes arrive. You set it up once, in the Plan phase, and then every later wave lands somewhere clean and controlled instead of on bare ground.
The Resource Manager tree — Organization, folders, projects
☺ Like you’re 10: Think of the house, then its floors, then the rooms — everything has a labelled place to live.
In Google Cloud, the landing zone is organised with Resource Manager, which arranges everything into a tree: an Organization at the top, folders for departments or environments, and projects as the individual "rooms" where resources actually live. This tree is what keeps a growing estate tidy instead of a sprawl of unrelated resources.
IAM and Organization Policy — keys and house rules
☺ Like you’re 10: Who gets which key, and the rules everyone must follow — like "no building in the backyard."
IAM (Identity and Access Management) decides who can open which door, and Organization Policy sets the house rules — for example, "no resource may be created outside Europe." Set both up in the Plan phase and every later wave inherits the same access controls and guardrails automatically.
A short worked example
☺ Like you’re 10: Let’s follow one pretend company through all four steps so it feels real.
Say "Rusty Retail" runs an online shop on 40 VMs and one big MySQL database at Fort Rusty.
- Assess: They point Migration Center at their data center. It discovers all 40 servers, maps which ones talk to the database, and produces a TCO report showing they’d save ~30% by moving.
- Plan: They build a landing zone with Resource Manager — one folder for "prod," one for "test," each with its own project and IAM roles. Using the 7 R’s, most VMs are tagged rehost, and the shop’s search service is tagged refactor for later.
- Deploy: Migrate to Virtual Machines replicates the 40 VMs into Compute Engine, wave by wave. Database Migration Service streams the MySQL database into Cloud SQL, keeping it in sync until a quiet-night cutover.
- Optimize: Weeks later, they use Migrate to Containers to turn the search service into containers on GKE, and right-size the VMs to cut the bill further.
Foxy: Owl, there are so many Google tools — how do I know which one to grab?
Professor Owl: Match the tool to the phase. Counting your stuff? Migration Center. Moving whole servers? Migrate to Virtual Machines.
Benny: And databases get their own truck — Database Migration Service — so Ellie never has to hand-carry the fish tank.
Gizmo: Pfft. Just skip Migration Center and start moving! Assessment is boring.
Timmy: Skip Assess and you’ll move a server that secretly depends on three others — then everything breaks at once. Count first, move second.
Professor Owl: Well said. The framework tells you if you’re ready; the four phases tell you what to do. Never skip a phase.
Take three imaginary workloads — a web server, a customer database, and a folder of 5 TB of old invoices with a slow internet link. For each one, name the Google Cloud tool and the phase it belongs to. (Hint: one of them is a job for the offline Transfer Appliance, not the network.)
1. What are the four phases of Google’s migration path, in order? 2. Which Google tool is the central hub for discovery, assessment, and TCO? 3. What was "Migrate to Virtual Machines" called before, and what does it move? 4. What is a landing zone, and which service organises it into folders and projects?
Check your answers
- Assess, Plan, Deploy, Optimize (Deploy is sometimes called "Migrate"; Optimize is continuous).
- Migration Center — it discovers your infrastructure, maps dependencies, groups assets, and generates the TCO report.
- It was "Migrate for Compute Engine" (and originally "Velostrata"). It migrates whole VMs into Compute Engine with near-zero downtime.
- A landing zone is the pre-built, secure foundation workloads land on. Resource Manager organises it into an Organization, folders, and projects, with IAM and Organization Policy for access and guardrails.