Capture the Google Cloud Migration Fund Before You Sign the Commit
A sequenced migration stack offsets roughly 18 to 30 percent of first year Google Cloud run rate, but RAMP service credits only deposit within 45 days of each quarter end, and only on incremental spend tied to a commitment signed before the work starts.
Prepared by Redress Compliance · June 2026 · Representative Google Cloud estate scenario (benchmark scenario, not a quote)
Executive Summary
The Google Cloud migration fund is not one program. It is a stack of four levers: RAMP service credits, professional services and partner funds, Marketplace commit drawdown, and a committed use discount layer. Sequenced in the right order, before signature, the stack offsets a large share of first year cost. Claimed late, it leaks.
The terms are public and specific. RAMP issues Google Cloud Service Credits on incremental eligible spend. For general workloads each workload is eligible for the lesser of 20 percent of Projected Annual Run Rate and $2M, with a $60,000 minimum run rate per workload, and credits deposit within 45 days of each calendar quarter end. Advanced workloads such as SAP, Oracle, VMware, and data analytics carry higher credit rates.
The discount layer compounds the fund. Spend based Flex committed use discounts buy down 28 percent at one year and up to 46 percent at three years on Compute, GKE, and Cloud Run, and Cloud SQL reaches 52 percent at three years. Marketplace software counts 100 percent toward the commitment, capped at 25 percent of the total.
The trap is the headline credit. The account team maximizes the credit number by pushing the largest commit, but the fund is a lagging reimbursement on spend you have to incur first, and an oversized commit is billed as shortfall at term end. The buyer side move is to commit the confident baseline and capture the credits on the ramp, not to chase the biggest fund.
This paper gives you the fund structure, the RAMP payout mechanics, the credit drawdown framework, the professional services rebate, the Anthos and GKE Enterprise credit, the database and BigQuery credit, the five price protection clauses, the exit and renewal rights, the discount benchmarks, the traps, and the BATNA with side letter language.
What does the Google Cloud migration fund actually contain?
The migration fund is the combined value of every incentive Google can apply to a move, modeled as cash equivalent before you negotiate. In a representative estate it lands near 28 percent of first year run rate. The components do not all behave the same way, so each needs a separate ask.
Take a representative enterprise, Northwind Freight, moving three workloads with a combined Projected Annual Run Rate of $4.0M: a Compute and GKE estate at $2.0M, a data analytics estate at $1.2M, and an Oracle database moving to AlloyDB at $0.8M. The fund stack on that estate is below.
| Incentive lever | Mechanic | Benchmark value (scenario) |
|---|---|---|
| RAMP service credits | 20 percent of run rate, lesser of cap $2M per workload, on incremental spend | $800,000 |
| Professional services rebate | Google PSO plus partner delivery funds for assessment and landing zone | $250,000 |
| Egress and switch credits | Free data transfer out of the incumbent plus first move credits | $90,000 |
| Total migration fund | Cash equivalent, first year | $1,140,000 |
That $1,140,000 against a $4.0M run rate is a 28.5 percent first year offset. Marketplace drawdown and the committed use discount layer sit on top of this and are modeled separately in sections six and seven, because they change net cost rather than pay a credit.
Benchmark scenario, not a quote. Numbers match the fund stack table above.
Why the stack must be sequenced before signature
Three of the four levers are gated by the order form. RAMP eligibility, the credit rate, and the professional services funding are scoped during the deal and named in the agreement. Claim them after signature and the leverage is gone.
Build the baseline and scope the fund
Size Projected Annual Run Rate per workload from real telemetry. Confirm RAMP eligibility, the credit rate, and PSO scope. Get partner funding named before any number is committed.
Lock credits and protections in the order form
Write the credit rate, the price hold, the commitment flex, the exit rights, and the renewal cap into the order form and a side letter. Do not accept a verbal credit promise.
Tag, claim, and protect the credits
Tag the eligible workloads, reconcile incremental spend each quarter, and claim within the 45 day window. Protect the credit baseline through any reorganization or retag.
Move one. How does the RAMP fund structure pay out?
RAMP, the Rapid Migration and Modernization Program, pays Google Cloud Service Credits against the incremental, eligible spend of tagged workloads. It is a reimbursement on growth, not a discount on list. That single fact governs how you size and stage the commitment.
The published RAMP program terms set the structure. General workloads earn the lesser of 20 percent of Projected Annual Run Rate and $2M per workload. Projected Annual Run Rate counts only eligible incremental spend, and must reach at least $60,000 per workload to qualify.
The three mechanics buyers miss
- Credits are a lagging deposit. They land within 45 days of each calendar quarter end, on spend already incurred. You fund the run rate first and recover later.
- Fully ramped is Google's definition. Projected Annual Run Rate is the estimate for a fully ramped workload. A slow ramp lets the account team reset the baseline and shrink the earned credit.
- Advanced workloads pay more. SAP, Oracle, VMware, and data analytics workloads carry higher credit rates to offset migration cost, but only if tagged to the advanced track at scoping.
In the scenario, the $4.0M run rate earns $800,000 at the 20 percent general rate. Tagging the $0.8M Oracle workload to the advanced database track lifts its share above the general rate, which is why the workload to track mapping is a negotiation, not a formality.
Move two. How do you frame the migration credit drawdown?
The drawdown framework is how you convert earned credits and committed spend into the lowest net cost. Two instruments do the work: the quarterly RAMP claim and the Marketplace commit drawdown. They are not the same and must be modeled separately.
Marketplace is the quieter lever. Since 100 percent of eligible Marketplace spend counts toward the Google Cloud commitment, third party software bought through Marketplace burns the commit you would otherwise have to fill with first party services. The cap is 25 percent of the total commitment.
Eligible third party software bought through Google Cloud Marketplace burns the committed spend obligation dollar for dollar.
The drawdown is capped at 25 percent of the total commitment, so Marketplace cannot fill an oversized commit on its own.
The drawdown discipline
- Route eligible software through Marketplace up to the 25 percent ceiling, so existing third party spend reduces the first party commit you must fill.
- Reconcile incremental spend every quarter against the tagged baseline, and file the RAMP claim inside the 45 day window. A missed window is a forfeited quarter.
- Hold a buffer below the commit floor. Spend based commitments bill the shortfall at term end, so the floor should sit under your confident baseline, not at the forecast.
Move three. How do you claim the professional services rebate?
The professional services rebate is the migration delivery cost Google and its partners absorb to remove friction from the move. It is real money, often the second largest line in the fund, and it is the least standardized, which means it is the most negotiable.
Two pools fund it. Google Professional Services Organization credits cover assessment, landing zone design, and architecture. Partner delivery funds, drawn from the partner's incentive pool, cover the hands on migration. The RAMP consulting track packages both.
How to size the ask
- Anchor to delivery hours, not a flat number. Price the assessment, the landing zone, and the workload migration as a statement of work, then ask Google and the partner to fund a named percentage.
- Split the pools. Keep PSO credits and partner funds as separate lines so neither party can claim the other already covered the work.
- Name the rebate in the agreement. A funded statement of work referenced in the order form survives a change of account team. A verbal commitment does not.
In the scenario, $250,000 of combined PSO and partner funding offsets a $700,000 migration program, roughly 36 percent of delivery cost. That share is defensible on a multi workload move with an Oracle exit, which Google funds aggressively.
Move four. What is the Anthos and GKE Enterprise migration credit worth?
The container modernization credit funds the move of virtual machine and on premises workloads into GKE Enterprise, the platform formerly branded Anthos. It sits in the RAMP advanced workload track and pays a higher rate than a straight compute lift.
The mechanism is Migrate to Containers plus the GKE Enterprise commitment. Google funds the modernization because a containerized estate is stickier and consumes more managed services. That is the leverage: the deeper the modernization, the larger the credit Google will fund.
Where the credit concentrates
- VMware to GKE Enterprise moves carry the advanced rate, because Google wants the VMware estate and will fund the exit.
- Stateful workload modernization attracts both the container credit and a database credit when the data tier moves to a managed service.
- Platform commitment on GKE Enterprise unlocks the higher credit band, so the container move and the commitment are negotiated together, not in sequence.
Move five. How do the database and BigQuery migration credits work?
The data tier carries the richest credits because the incumbent lock is strongest there. Google funds the move off Oracle and SQL Server, and the move into BigQuery, more aggressively than any other workload class.
For operational databases, Database Migration Service now uses Gemini to convert Oracle stored procedures and functions to PostgreSQL for Cloud SQL or AlloyDB. The conversion cost that used to block an Oracle exit is largely automated, and RAMP funds the residual.
The two data credit tracks
- Operational database track. Oracle and SQL Server to Cloud SQL or AlloyDB. The advanced workload rate plus DMS conversion plus partner remediation funding.
- Analytics track. Teradata, Hadoop, and warehouse moves to BigQuery, funded with platform credits, implementation services, and egress credits to cover the cost of leaving the incumbent.
The egress credit matters more than its size. It removes the single most common reason a data migration stalls, the cost of moving the data out, and it stacks with the free egress now available when leaving a competing cloud.
Move six. Which price protection clauses keep the fund from leaking?
A captured fund leaks back to Google through price increases, credit clawbacks, and shortfall billing unless the contract holds it. Five clauses do that work, and the discount layer they protect is shown below.
| Service | One year discount | Three year discount |
|---|---|---|
| Compute, GKE, Cloud Run (Flex CUD) | 28% | 46% |
| Cloud SQL and AlloyDB | 25% | 52% |
| BigQuery Enterprise slots | 20% | 40% |
These bands come from the public spend based committed use discount documentation. Since 15 July 2025, the multiprice model applies the discount directly to the SKU price rather than issuing a separate credit, which changes how shortfall appears on the invoice.
Benchmark bands from public spend based CUD documentation. Numbers match the discount table above.
The five clauses that protect the budget
| Clause | What it does | Buyer ask |
|---|---|---|
| Price hold | Freezes list price on committed services for the term | List price hold plus a cap on any pass through increase |
| Credit at risk protection | Keeps earned and projected credits through reorganization and retag | Credit continuity language naming the workloads, not the account |
| Commitment flex | Allows the commit floor to move down on a verified shortfall | An annual down flex right with no penalty inside a stated band |
| Termination for convenience | Lets you exit a workload commitment with notice | Exit with notice plus a free egress waiver on departure |
| Renewal cap | Caps the price increase at renewal and blocks automatic renewal at list | A fixed renewal uplift ceiling and no automatic renewal |
Move seven. What exit and renewal rights protect the budget?
The exit and renewal rights are the BATNA made contractual. Without a credible alternative and the right to use it, every other clause is a request Google can decline at renewal. The alternative is now cheaper to build than it has ever been.
Since the EU Data Act took effect, the major clouds waive data egress fees when a customer leaves for another provider. AWS, Microsoft, and Google all removed exit egress charges in 2024, which means your BATNA no longer carries a six figure exit toll. Use it.
How the structured stack changes first year cost
The chart below models the representative estate. The migration fund removes $1.14M, and the committed use discount layer removes a further share of the remaining run rate, cutting the effective first year cost to near half of gross.
Gross $4.0M, less the $1.14M fund, less a 30 percent CUD on the remaining $2.86M ($858k), nets near $2.0M. Benchmark scenario, not a quote.
Side letter language we use
- Exit: "Customer may terminate any workload commitment on 60 days notice, and Google will waive all data egress charges for data transferred out in connection with such termination."
- Renewal: "Any renewal price shall not exceed the then current committed rate by more than 5 percent, and no commitment shall renew automatically without Customer's written order."
- Credit continuity: "Earned and projected Service Credits shall follow the tagged workloads through any reorganization, account restructuring, or retag, without requalification."
What are the common mistakes and traps?
Most migration fund value is lost in a handful of repeatable errors. Each one is avoidable with a clause or a sequence change made before signature.
- Oversizing the commit for the headline credit. A bigger commit unlocks a bigger fund on paper, then bills the shortfall at term end. The credit is a reimbursement on spend you must incur first.
- Claiming credits after signature. RAMP eligibility and the credit rate are scoped in the deal. After signature there is no leverage left to move them.
- Missing the 45 day claim window. Credits deposit only within 45 days of quarter end. A late reconciliation forfeits the quarter's credit.
- Letting the workload tag break. A reorganization or retag during the term can sever the credit from the workload and forfeit the unearned balance.
- Negotiating without a live alternative. With free egress to leave, the BATNA is cheap to build. Walking in without one cedes every protection clause.
The single most expensive trap is treating the RAMP credit as a discount. It is a lagging reimbursement on incremental spend, gated by quarterly windows and workload tags. Size the commit to the confident baseline, and let the credit accrue on the ramp.
Five recommendations from Redress Compliance
The conclusions, in order of leverage, for any team negotiating a Google Cloud migration in 2026.
- Build the verified baseline first. Size Projected Annual Run Rate per workload from telemetry before any commitment number is discussed. The baseline anchors the deal.
- Commit the confident floor, not the forecast. Size the commit below your verified baseline and capture credits on the ramp. Never sign the account team forecast at three years.
- Tag the advanced workloads. Map Oracle, SQL Server, VMware, and data analytics to the advanced track at scoping to lift the credit rate above the general 20 percent.
- Write the five clauses into the order form. Price hold, credit continuity, commitment flex, exit with egress waiver, and renewal cap. A verbal promise is worth nothing at renewal.
- Build the BATNA with free egress. Price a credible alternative and put the exit right in the contract. The alternative sets every discount and protection you win.
Benchmark ranges: Redress Compliance advisory engagement file, 2024 to 2025. Figures are defensible ranges from buyer side engagements, not a Google quote.
Work with us before you sign the commit. Redress Compliance builds the verified baseline, sizes the fund, drafts the five clauses, and runs the BATNA so the migration fund lands in your contract, not in the account team's forecast.
- Fund capture: we model the RAMP, PSO, Marketplace, and CUD stack against your real run rate and name every number in the order form.
- Clause and BATNA build: we draft the price hold, credit continuity, flex, exit, and renewal language, and stand up the competitive alternative that prices it.
We are glad to tie a meaningful part of the fee to delivered value.
