GCP Cloud Adoption Framework: Overview & Maturity Model — The Four Themes (Learn, Lead, Scale, Secure), the Tactical–Strategic–Transformational Phases, Epics, and How to Assess Your Maturity

Where this fits

The Google Cloud Adoption Framework (Google’s CAF) is Google’s structured way of answering one question: how ready is your organization — not your servers, your organization — to adopt cloud, and what do you do about the gaps? This article is part 1 of the series — the overview that builds the coordinate system everything else in Google’s framework is plotted on. Google’s CAF is deliberately small and load-bearing: it rests on four themes (Learn, Lead, Scale, Secure), grades each theme across three maturity phases (Tactical, Strategic, Transformational), decomposes the work into epics, and asks you to run a maturity assessment to find your honest starting point. Get this overview right and every later activity — the cloud program, the landing zone, the operating model — has a place to live and a score to move; skip it and you will treat Google Cloud as a pile of unrelated projects with no shared definition of “ready” and no way to tell whether you are getting better.

The framework’s purpose and the readiness-program idea

What it is. Google’s Cloud Adoption Framework is an assessment-and-planning model, distilled from Google’s and Google Cloud Consulting’s field experience, that measures organizational cloud readiness across four themes and three maturity phases, and then translates the resulting picture into a sequenced program of work expressed as epics. It is explicitly not an architecture framework — that role belongs to the Google Cloud Architecture Framework (the GCP equivalent of a Well-Architected Framework, covering operational excellence, security, reliability, cost optimization, and performance). It is not a landing-zone blueprint — that is the Google Cloud landing zone and enterprise foundations blueprint. Google’s CAF sits one level above all of those: it is the operating-model and readiness lens that tells you whether the enterprise as a whole can absorb cloud at scale, where it is weak, and which program of epics will move the weak spots.

Why it matters. The most common way a cloud program stalls is the silent assumption that adoption is a technology exercise. It is not. An organization can stand up a beautiful Google Cloud organization resource, wire up Shared VPC, and migrate 600 VMs with Migrate to Virtual Machines, and still have a program that is going nowhere: finance cannot read a showback, the security team cannot evidence a control to an auditor, nobody owns the platform, and every new project is hand-built in the console. Google’s CAF exists to make those non-technical readiness gaps visible, scored, and ownable, so they are worked in parallel with the migration rather than discovered a year later. The framework’s whole value is that it gives a shared, defensible language — themes, phases, epics, a score — that an architect, a CFO, and a CISO can all stand around and agree on.

How to do it well. Treat Google’s CAF as a diagnostic-then-roadmap instrument, not a maturity-model trophy. The intended loop is: assess your current maturity across the four themes, identify the theme that is gating your goals, prioritize a small set of epics that move it, execute them, and re-assess. Anchor every epic to a business outcome and a named executive sponsor so the work is never abstract self-improvement but always traceable to “this epic unblocks that outcome that this leader owns.” Resist the urge to push all four themes to Transformational at once — the framework is designed for uneven maturity, and forcing uniformity wastes money on themes that do not gate anything yet.

Artifacts, decisions, and Google Cloud tooling.

The Google Cloud tooling that operationalizes the purpose includes the Google Cloud Adoption Framework assessment (the questionnaire and scoring that produce the baseline), Google Cloud Consulting / Professional Services Organization (PSO) CAF workshops to facilitate it, StratoZone and migration assessments via the Migration Center to put data under the migration business case, and the Google Cloud Architecture Framework plus the Active Assist Recommender family to assess individual workloads and configurations once they exist. The assessment produces the readiness baseline; the Migration Center turns “we think we have ~600 VMs” into a data-driven TCO and right-sizing report before any money is committed.

The four themes — Learn, Lead, Scale, Secure

What it is. The four themes are the dimensions of readiness Google’s CAF measures. Crucially, they are not technology buckets — they are organizational-capability buckets, and three of the four are about people, governance, and operating model rather than infrastructure:

• Learn — the quality, depth, and scale of your skilling program. How effective are your efforts to upskill your teams, and — the part most enterprises miss — can you augment your existing IT staff with the right partners and managed services to cover the gaps while skills are still being built? Learn is not “did people take a course”; it is “does the organization have a sustainable engine for acquiring and renewing cloud competence.”
• Lead — how well cloud adoption is supported, sponsored, and championed by leadership, and how cross-functional, collaborative, and self-motivated the teams doing the work are. Lead is the difference between a cloud program that has an executive sponsor signing the cheque and one that is a grassroots science project nobody above the director level can name.
• Scale — the degree to which you use cloud-native services that automate and reduce operational overhead, and the ability to grow and shrink those services with demand. Scale is the theme where “we lifted VMs and now we patch them ourselves” sits at the bottom and “we run managed, autoscaling, largely serverless platforms” sits at the top.
• Secure — the maturity of your capability to protect your services from unauthorized and inappropriate access with a multi-layered, defense-in-depth, identity-centric approach that evolves with cloud maturity. Secure is not a checklist of products turned on; it is how systematically and how early security is built into the operating model.

Why it matters. The four themes stop leadership from collapsing “cloud readiness” into a single hand-wavy number. A real organization is almost never uniformly mature: it is common to be Strategic on Scale (good cloud-native engineering) but Tactical on Lead (no executive sponsor, no funded program) and Tactical on Secure (security bolted on after the fact). That asymmetry is the most actionable output of the whole framework — it tells you precisely where the next dollar buys the most readiness. The themes also give four different executives a seat: Learn belongs to the CIO/HR and the skilling lead, Lead to the executive sponsor, Scale to the platform/engineering lead, and Secure to the CISO. Each can be held accountable for moving their theme.

How to do it well. Score the four themes honestly and separately, then read the shape, not the average. A program that is Transformational on Scale but Tactical on Lead is a powerful engine with nobody steering — flag it, because un-sponsored engineering excellence gets defunded the moment budgets tighten. A program strong on Lead and Learn but weak on Secure is an enthusiastic, well-skilled organization about to have an incident. The healthiest early-stage shape is balanced movement — pull all four themes up together rather than maxing one while the others stay at the bottom, because the weakest theme caps what the program can actually deliver.

Artifacts, decisions, and tooling. The artifact is a four-theme scorecard — one phase rating per theme, each carrying an owner and the evidence behind the score. The key decision the themes drive is where to invest next: the theme that is both low-scoring and gating a priority outcome is where the program funds epics first. A radar/spider chart of the four themes is the single most useful one-slide artifact for a steering committee, because it makes the asymmetry impossible to ignore.

The three maturity phases — Tactical, Strategic, Transformational

What it is. The three maturity phases are the scale of measurement applied to each theme. Every theme is rated against the same three-rung ladder, which describes how deliberate and how far-reaching the organization’s cloud posture is:

• Tactical — there is no coherent plan spanning the breadth of the organization’s cloud use. The focus is on reducing the cost of discrete systems and getting quick, short-term wins with minimal disruption. Individual systems are provisioned and managed, often in silos, frequently as lift-and-shift, with low automation and ad-hoc governance. Tactical is not a failure state — it is where most organizations legitimately start, and it can deliver real early value — but it has no organizing strategy beyond “save money on this thing, quickly.”
• Strategic — there is a broader vision that governs individual systems, designed and developed with an eye to future needs and scale. The organization has begun to apply consistent governance, foundations, automation, and operating-model thinking across many workloads rather than one at a time. Decisions are made for the portfolio, not the single app. Strategic is where landing zones, IaC, central identity, and a CCoE typically become real.
• Transformational — cloud operations are functioning smoothly, and the focus shifts to using the data and insights generated by working in the cloud to transform the business itself. New data is integrated into new products, generating new revenue, competitive differentiation, and new ways of working. Transformational is not “we run the cloud well” — it is “the cloud is changing what the business is,” with data and AI feeding back into the product and the operating model.

Why it matters. The phases are what turn the framework from a static audit into a trajectory. Without them, “we’re doing security” is unfalsifiable; with them, “we’re Tactical on Secure and we need to reach Strategic this year” is a fundable, measurable goal with a clear definition of done. The phases also calibrate ambition against reality. A board demanding Transformational outcomes (new AI-driven revenue) from an organization that is Tactical on every theme is asking for a penthouse with no building under it — the phase ladder makes that conversation explicit and forces the foundational themes up first. And because each theme is phased independently, the model captures the real, lumpy state of an enterprise far better than a single overall “maturity level” ever could.

How to do it well. Use the phases as targets per theme, not a single org-wide badge. State, for each theme, where you are and where you intend to be by a date — for example Secure: Tactical → Strategic by Q4 — and let that target select the epics. Resist phase-skipping: a theme that is Tactical rarely jumps straight to Transformational, because Transformational depends on the smooth operations that Strategic establishes. The right reading of the ladder is “Tactical earns trust and cash, Strategic builds the platform and governance that makes scale safe, Transformational monetizes the data and operating model the first two phases created.”

Artifacts, decisions, and tooling. The artifact is the phase target per theme captured on the scorecard — current phase, target phase, target date. The decision it drives is the size and shape of the program: moving one theme one phase is a quarter or two of focused epics; moving all four from Tactical to Strategic is a multi-quarter foundational program. On Google Cloud, the move from Tactical to Strategic is most visibly the adoption of the enterprise foundations blueprint and Terraform-based IaC; the move from Strategic to Transformational is most visibly BigQuery, Looker, and Vertex AI turning operational data into product.

Epics — how the framework carves the work into deliverable units

What it is. Once the themes and phases give you a scored picture, epics are how Google’s CAF turns that picture into work you can actually plan, staff, and deliver. An epic is a discrete, outcome-oriented body of work that advances one or more themes toward a higher phase — the framework’s unit of execution, sized so that it can be owned, scheduled, and finished. Epics are intentionally program-management-shaped: each has an outcome, an owner, dependencies, and a definition of done, which is exactly what lets a CAF assessment become a roadmap rather than a wall of recommendations. Epics decompose further into the technical work (often modelled as user stories or workstreams) that engineering teams pick up.

Why it matters. The gap where cloud programs die is between assessment and action. A scorecard that says “you are Tactical on Lead and Secure” is true and useless until it becomes “Epic: stand up a Cloud Center of Excellence and an executive steering committee” and “Epic: implement organization-wide guardrails with Organization Policy Service and Security Command Center.” Epics are the bridge. They also impose prioritization and sequencing: because each epic carries dependencies, the framework makes it obvious that, say, the “self-service environment vending” epic depends on the “landing zone foundation” epic, which depends on the “resource hierarchy and IAM” epic — so you cannot do them in the wrong order. And because each epic maps to themes and a target phase, you can always answer “why are we doing this work?” with “to move Secure from Tactical to Strategic, which gates the regulated-workload outcome the CISO owns.”

How to do it well. Write epics so each one (1) names the theme(s) and target phase it advances, (2) names a single accountable owner and the executive who sponsors it, (3) lists its dependencies on other epics, and (4) defines done as a re-assessable change in maturity, not an activity. Keep the active set small — a handful of epics per iteration that move the gating theme — rather than launching twenty in parallel and finishing none. Sequence by dependency and by leverage: foundational epics (resource hierarchy, identity, landing zone) unblock almost everything else and should come first even though they are unglamorous.

Artifacts, decisions, and tooling. The artifact is the epic backlog, each epic a card carrying theme tags, target phase, owner, sponsor, dependencies, and a re-assessable definition of done — typically tracked in Jira, Google Cloud’s own delivery tooling, or whatever the program office already uses. The decision epics drive is the sequenced roadmap: which epics this quarter, which next, gated by dependency and by which gating theme each one moves. The most consequential sequencing decision is putting the foundational epics (hierarchy, identity, landing zone, guardrails) ahead of the exciting ones (analytics, AI, self-service), because every later epic stands on them.

How to assess your cloud maturity

What it is. The maturity assessment is the entry point to the whole framework — the activity that converts opinions into a scored baseline. Mechanically, you answer a structured set of questions across the four themes, each answer maps to a Tactical / Strategic / Transformational signal, and the results aggregate into a phase rating per theme (and a composite view across all four). Google runs this as the Google Cloud Adoption Framework assessment, typically facilitated by Google Cloud Consulting (PSO) or an accredited partner as a workshop, and complements it with technical-evidence tooling so the scores are grounded in data rather than self-flattery.

Why it matters. An honest baseline is the single most valuable thing the framework produces, for two reasons. First, you cannot prioritize without it — “invest where you are both weak and gated” is meaningless until you know where you are weak. Second, you cannot prove progress without it: maturity is only credible if you re-assess on a cadence and show the score moving, which is what keeps an executive steering committee funding the program. The assessment is also a political instrument in the best sense — because it is structured and evidence-backed, it lets an architect tell a CISO “we are Tactical on Secure” with data behind it, defusing the defensiveness that an unstructured opinion would trigger.

How to do it well. Run the assessment as a facilitated, cross-functional workshop, not a survey emailed to one team — you need finance, security, platform, and a business sponsor in the room, because each owns a different theme and will score it differently from the others (the disagreement is the signal). Demand evidence for every score: an “Active” security control is one you can point Security Command Center at, not one someone believes is on; a “Strategic” Scale rating means you can show the autoscaling managed services in production, not on a roadmap. Score conservatively — when a theme is between two phases, rate it the lower one, because over-rating hides the gaps the program exists to close. Finally, set a re-assessment cadence (quarterly or per major milestone) up front, so the baseline becomes a trend line.

Artifacts, decisions, and tooling. The artifacts are the scored baseline assessment, the four-theme radar chart, and the re-assessment schedule. The decision the assessment drives is the entire program: it selects the gating theme, the target phases, and therefore the epic backlog and roadmap. The tooling that grounds it — Security Command Center for Secure, Active Assist Recommenders and the Migration Center for Scale, StratoZone for the estate baseline, and the Google Cloud Architecture Framework review for individual workloads — is what separates a defensible assessment from a wish list.

Real-world enterprise scenario

Meridian Freight Group is a fictional but realistic pan-European logistics company: ~9,000 employees, two owned datacenters (one on a lease expiring in 14 months), a fleet-telematics estate generating ~4 TB/day, and a board mandate to “become a data-driven logistics business” while exiting at least one datacenter. The cloud team — six engineers and an enterprise architect named Priya — has already migrated three apps to Google Cloud as a science project, but the program has no sponsor, no budget line, and no shared definition of progress. Priya runs a Google Cloud Adoption Framework assessment, facilitated by Google Cloud Consulting, as her first move.

The maturity assessment. Over a two-day facilitated workshop with finance, the CISO’s deputy, platform engineering, and the COO as candidate sponsor, Meridian scores itself honestly and conservatively. The four-theme radar comes back lumpy, which is exactly the point.

Decisions per theme. For Lead, the COO agrees to sponsor the program and chair a quarterly steering committee, and a Cloud Center of Excellence is chartered with a funded headcount — Lead’s path from Tactical to Strategic. For Learn, Meridian commits 5 engineers to Google Cloud Skills Boost certification tracks and signs a partner for managed-service augmentation so the lift is covered while skills build. For Scale, the decision is to stop hand-migrating and adopt the enterprise foundations blueprint with Shared VPC and Terraform, then move new workloads to GKE Autopilot and Cloud Run rather than VMs. For Secure, the CISO’s deputy owns an epic to deploy Organization Policy Service guardrails, turn on Security Command Center Premium, and enforce VPC Service Controls around the telematics data.

The epics they produce. The assessment becomes a sequenced backlog, foundational epics first:

The measurable outcome. Eleven months later Meridian re-assesses. Lead and Secure reach Strategic (funded CCoE, quarterly steering, org-wide guardrails enforced and evidenced in Security Command Center). Scale reaches Strategic with the landing zone live, 240 of the targeted ~600 VMs migrated, and the datacenter-exit on track for the lease deadline. Learn reaches Strategic with 5 certified engineers and a renewing program. Scale on the analytics workload is pushing into Transformational: the telematics platform on BigQuery + Vertex AI now predicts delivery-window risk, a capability Meridian has begun selling to customers as a premium SLA — the first cloud-generated revenue, not just cost saving. The radar chart that started spiky and low is now balanced and one phase higher across the board, and the board has a defensible, scored trajectory to fund the next year against.

Deliverables & checklist

By the end of the Overview & Maturity Model phase you should have produced:

• A scored maturity assessment rating each of the four themes (Learn, Lead, Scale, Secure) against the Tactical / Strategic / Transformational ladder.
• A four-theme radar chart that exposes the asymmetry across themes on one slide.
• Evidence behind every score — Security Command Center for Secure, Active Assist Recommenders and the Migration Center for Scale, a StratoZone/estate baseline, and certification records for Learn.
• A target phase per theme with a date (e.g., Secure: Tactical → Strategic by Q4).
• A prioritized, sequenced epic backlog, each epic carrying theme tags, target phase, a single owner, an executive sponsor, dependencies, and a re-assessable definition of done.
• A stakeholder & sponsor map tying each theme and epic to a named executive.
• A cloud adoption roadmap sequencing the epics against outcomes and milestones, with foundational epics first.
• A re-assessment cadence (quarterly or per milestone) agreed and on the calendar.

Common pitfalls

1. Collapsing the four themes into one number. Reporting a single “maturity level” hides the asymmetry that is the framework’s most actionable output. Avoid it by always scoring and reporting the four themes separately and leading with the radar chart, not an average.
2. Treating CAF as a technology audit. Three of the four themes — Learn, Lead, Secure — are about people, sponsorship, and governance. A program that only scores Scale is measuring the easy theme. Avoid it by putting finance, security, and a business sponsor in the assessment room, not just engineers.
3. Over-rating the assessment to look good. A “Strategic” score with no evidence is worse than an honest “Tactical,” because it hides the gap the program exists to close. Avoid it by demanding configuration-level evidence (Security Command Center, Recommenders) and scoring the lower phase whenever a theme is borderline.
4. Phase-skipping. Chasing Transformational (new AI revenue) before reaching Strategic (governed, smoothly operated platform) builds a penthouse with no building under it. Avoid it by sequencing foundational epics — hierarchy, identity, landing zone, guardrails — ahead of analytics and AI epics.
5. Assessing once and never again. A baseline with no re-assessment is an opinion, not a trajectory, and steering committees defund programs that cannot show movement. Avoid it by fixing a re-assessment cadence up front and versioning the scorecard over time.
6. Epics that define “done” as activity, not maturity. “Ran a security workshop” is an activity; “moved Secure from Tactical to Strategic, re-assessed” is an outcome. Avoid it by writing every epic’s definition of done as a re-assessable change in phase tied to an owner and sponsor.

What’s next

With the themes, phases, epics, and a scored baseline established, part 2 of the Google Cloud Adoption Framework series goes deep on the Lead theme and the Cloud Center of Excellence — turning executive sponsorship and a cross-functional operating model into the engine that drives every epic on your roadmap.