Same revenue, double the multiple
Put two Google Cloud partners on the same table in a diligence room. Both bill around $14M a year. Both have the Premier tier badge on the website. One of them gets an offer at 6x EBITDA. The other clears 14x. The financials look nearly identical on the surface, so what is the second one selling that the first one isn't?
The answer is in what happens after the migration ends. The 6x firm does lift-and-shift: it picks up a client's virtual machines, drops them onto Compute Engine, hands over a runbook, and moves to the next project. That work has a finish line, and the day it crosses it, the client is free. Their workloads now run on the same managed VMs any other GCP reseller can babysit, so the next renewal is a price negotiation the partner usually loses. Buyers have learned to read this pattern instantly. They model it as a staffing business with a thin recurring-revenue veneer, and staffing businesses don't get platform multiples.
The 14x firm refactored those same applications onto Google Kubernetes Engine. It broke the monolith into containerized services, wrote the Helm charts, stood up the ingress and the autoscaling policies, and now owns the deployment pipeline that ships the client's revenue-generating features. You cannot fire that partner without a re-platforming project nobody has the appetite to fund. CNCF's annual survey puts Kubernetes adoption near-ubiquitous in the enterprise — which means the GKE shop isn't betting on a niche, it's standing on the layer every serious workload now lands on. That is the whole bifurcation: one partner rents server space, the other owns the operating layer the business runs on.
The line in the data: 105% versus 130% NRR
Migration fees are a one-time sugar high. The number that decides the multiple is Net Revenue Retention, and across the GCP-partner diligence work I've sat through, the split is not subtle. Generalist MSPs running managed VMs land somewhere around 95-105% NRR — they renew most accounts but lose a steady trickle to price, and they rarely expand. GKE-native shops run 120-135%. The gap is not better salesmanship. It's the cluster.
Here is the mechanism, because the mechanism is what a buyer actually underwrites. A production Kubernetes environment is genuinely hard to operate: someone has to manage the Helm release process, keep the Istio service mesh from silently dropping traffic, handle persistent storage classes and stateful sets, set the pod-disruption budgets so a node drain doesn't take down checkout, and tune the cluster autoscaler so the client isn't either paged at midnight or torching budget on idle nodes. The client's internal IT team almost never has all of that in-house. So the relationship becomes structural rather than transactional — and crucially, it grows. Every new feature release, every new internal tool, every model the client wants to ship lands on the clusters the partner already runs. Expansion is the default motion, not the exception.
That is why a buyer pays for the sticky complexity instead of discounting it. The same dynamic drives the broader managed-services versus professional-services valuation gap — recurring operational dependency is worth a multiple turn or three over project work that has to be re-sold every quarter. In a diligence model, that 130% NRR isn't a vanity metric; it's the compounding engine the acquirer is buying. You don't fire the team keeping your microservices alive in production. You hand them more workloads.
What I actually check in the cluster
Certifications lie. A firm can field a wall of Google Cloud Partner Advantage badges and still operate like a help desk, so badge count is the first thing I throw out. When I'm pressure-testing whether a GCP shop earns the GKE premium or just claims it, I go looking for the operational fingerprints that can't be faked in a pitch deck.
I ask to see the Terraform state and the GitOps repo. A real cloud-native team manages clusters as code — the namespaces, RBAC policies, and network rules live in version control, not in someone's memory of which buttons they clicked in the console. That single fact is why their EBITDA is higher quality: one engineer running Terraform and a CI pipeline does the work of a room full of people doing it by hand, and that labor efficiency shows up directly in margin. It's also what lets a true specialist sail through a technical-debt assessment instead of stalling on a pile of manual, undocumented config nobody dares touch. Then I look at where the AI workloads run, because Kubernetes is fast becoming the substrate for serving models and inference pipelines — a team already orchestrating GKE for that is sitting on the layer the next 18 months of client demand will route through, while a Workspace-and-Compute-Engine generalist is starting from scratch. The Gartner trajectory — the overwhelming majority of new digital workloads going cloud-native — is exactly why that head start compounds.
So before you sign an LOI on a GCP partner, run the test on Monday: pull the repos, count the manual console steps in their deployment runbook, and ask the lead engineer to walk you through a real cluster upgrade. If the answer is "we open a ticket with Google," you're looking at a 6x staffing business. If the answer is a clean diff in a Helm chart and a pipeline that rolled it out, you found the 14x. The Partner Advantage 'Build' and 'Manage' incentives reward the second profile for a reason — and so will your eventual buyer.
