Before You Migrate: A Practitioner's Guide to Moving from Salesforce CPQ to Revenue Cloud

Salesforce CPQ is end of sale. You can't buy new licenses, but you're still supported. Nobody is forcing you to move. But if you run CPQ, the question isn't whether you'll migrate to Revenue Cloud. It's when, and how.

That "how" is where most organizations stall. The migration feels monolithic: thousands of products, years of customizations, legacy subscriptions scattered across systems, a sales team that can't afford downtime.

It doesn't have to be monolithic. Every successful CPQ-to-Revenue Cloud migration comes down to two decisions: what comes with you, and who moves when. Get those right, and the rest is execution. Get them wrong, and you'll spend months reworking an unstable plan.

Decision 1: What Comes With You

Revenue Cloud is a different data model, different technology. There's no true lift and shift. You're rebuilding regardless. The question is how much you rebuild the same way versus how much you rethink. Salesforce's own migration guidance identifies four credible paths. None is wrong. One is the right answer for your organization.

1. Recreate

Rebuild what you have, behavior for behavior. This is the least change for the business and usually the shortest road to go live, though it isn't necessarily the least engineering work. 

Recreate is the right call when your CPQ org is fairly clean, your business model isn't changing, you have a hard date that can't move, and (this is the one most people miss) your business can't absorb both process change and platform change at the same time. 

The trade-off: you keep the debt. Everything that accumulated over years of CPQ customizations comes with you, just rebuilt on a new platform. 

2. Selectively Transform 

Keep the core while modernizing what matters most. In practice, that's usually the product catalog. 

The trade-off: every decision needs to be defended. For each piece of your CPQ implementation, you make a deliberate call: keep it or rebuild it. Slower than recreating, but it's where most organizations find the right balance between speed and value. 

3. Rationalize 

Redesign the commercial model from first principles. Bottom up. The most value and upside, and obviously the most change. You're rethinking how your business sells. Highest-risk, highest-reward. 

4. Start Somewhere New 

Build the future model on a new product or business line first, sidestepping the existing install base entirely. You build clean, prove the model, then tackle the install base later (or let it run on CPQ until natural contract events move it over). 

The Rule for Making Decisions: Keep, Rethink, or Retire 

Every pattern except recreate turns one big decision into lots of small ones, item by item. You need a rule for moving through those decisions efficiently. 

Three questions: keep, rethink, or retire. It sounds simple. It isn't. The hard part is knowing whether you're looking at a business requirement or just the way CPQ happened to implement something. 

Keep: Does the customer or contract require it? Is it part of your commercial policy or compliance? If yes, that's business truth. It has to come with you. Approval rules and discount thresholds are policy. They survive the move. 

Rethink: Some workarounds encode a real requirement; they just do it badly. A fake product that exists only to carry a fee or a discount. The fee is needed. The product is not. This is the hardest category because the people who know why something was done aren't always the people who know how, and you need both in the room. 

Retire: Duplicate fields, obsolete automation, workarounds that exist only because the old architecture required them. These don't come with you. 

The Edge Case Trap 

Here's where it gets tricky. In B2B, a lot of revenue runs on exceptions and edge cases. Your biggest customers have the most negotiated terms. When someone calls something an "edge case" and wants to retire it, you need to ask a second question: is it rare by count, or rare by revenue? 

A pricing rule that fires twice a year might govern your largest deal. You need evidence in the system: how many times has this rule fired, what products are still actually in use, what's the revenue exposure. Retire the artifacts. Keep the business truth. 

Decision 2: Who Moves When 

The second decision is the rollout strategy. Every rollout strategy is a choice of boundary: which transactions run on CPQ versus Revenue Cloud, and what happens when a customer needs both. Salesforce names four rollout strategies, each defined by where you draw the line. 

Big Bang 

The boundary is time. You're trying to get to one platform the fastest. 

The trade-off: all the risk lands in a single cutover. If something breaks, it breaks for everyone. 

Pilot 

The boundary is capability. You're running to prove the hardest cases before you commit to a broader rollout. 

The critical requirement that most pilots miss: an exit decision. What are you proving? What would stop you from scaling? Who moves next? Without those answers defined upfront, a pilot becomes a permanent parallel system. 

Bridge 

The boundary is contract life cycle. Your install base stays on CPQ until a defined migration event, usually renewal. New business goes to Revenue Cloud. The trade-off: multiple paths for running the business while the install base transitions, including two paths for ARR reporting. Clean conceptually, operationally complex. 

Cohort 

The boundary is a population: a customer segment, a region, a business unit. You contain change to a defined group. The catch: it looks clean until an enterprise customer buys from multiple business units or regions. Now that customer crosses your boundary. 

The real question isn't which of these to pick. It's which boundary keeps the two platforms from colliding against each other. 

What Must Be True When Both Systems Run 

If you go with any phased approach, there's a stretch where both systems run in parallel. That's where phased migrations succeed or stall. Six things need to be settled: 

1. Contract of record. Where is the contract origin? The cleanest default: a CPQ contract stays on CPQ until a defined migration event, usually renewal. 
2. Deals that cross the boundary. A customer on a multiyear CPQ contract buys a new product and wants to co-term. Under the default, cross-sell (the motion you want on the new platform) comes last. The alternative is making cross-sell the migration event, but then obligations live in different places. Nothing black or white. Work through the trade-offs. 
3. Open quotes. Set an explicit closeout policy. Some quotes get closed on CPQ, others get requoted in Revenue Cloud. Nothing should be lost or dropped. 
4. The first renewal. The first renewal on migrated data is the true test of the migration. It's where you prove outcome parity: can the new system operate on your migrated install base and produce the same commercial outcomes? 
5. Reporting. When you're running two systems, you're supporting two data models. ARR, opt-in bookings, pipeline: they sit on slightly different data models. Agree on a reporting view before go live. 
6. Cutover timing. Stay away from quarter end and renewal peaks. Freeze the product catalog during cutover. 

Data: The Thing Underneath Everything 

Right underneath all of this is data. How do you prove it all moved correctly? That's where most migrations underestimate the work. 

One Source of Truth Per Domain, Not Per System 

Salesforce, billing, ERP: they often hold the same customer and contract data. When they disagree (and they will), you need to know which one wins. Decide that by domain: customer, products, pricing, contract, invoicing, revenue. Not by system. And decide how the loser gets corrected when they disagree. 

Cleanse at the Source or in Staging 

Data quality isn't something the migration load fixes. The load is mechanically moving data. Remediation has to start before the load, as its own work stream. Fix it at the source where you can; with legacy systems that may be impractical, so fix it in a staging layer. What you absolutely cannot do is load dirty data into the new solution and plan to clean it up later. That never works. 

Test Outcomes, Not Process 

Your process may be changing. It's outcome parity you're testing for, especially where you deliberately change products or pricing models. Pick your most critical deal shapes and economics, and test against the new expected outcome. 

Validation Gates 

There's automated reconciliation: did the data mechanically migrate and match up? Then there's business validation: is the right commercial obligation represented, over and above whether the totals and dates match? You need both. 

Make Your Two Decisions First 

Before you commit to migration, prove it. Understand what's based on a business process and what was done because of a technical fit for CPQ. Sort it: keep, rethink, retire. Get clear on your source of truth for each data domain. Then make your two decisions: what comes with you, and who moves when. 

The migration isn't monolithic. It's a series of deliberate choices, each with trade-offs, each defensible, each reversible if you catch it early enough. The organizations that succeed aren't the ones with the cleanest CPQ orgs. They're the ones who make their decisions deliberately, plan their data work early, and treat the migration as what it is: not a platform swap, but a chance to run revenue differently. 

Once you've made those two decisions, the next questions are practical: how long will both systems run in parallel, what do you do with legacy subscriptions, and how is AI changing the migration process itself. We tackle those in part two of this guide.