TL;DR
- Salesforce CPQ End of Sale means no new licenses; existing customers keep access but face a widening innovation gap as Salesforce shifts investment to Revenue Cloud Advanced.
- The migration is a full reimplementation. Apex, Quote Calculator Plugins, Price Rules, and integrations all need to be reviewed, rebuilt, or retired.
- Run a 6-point pre-migration audit (customizations, pricing logic, catalog, dependencies, integrations, approval flows) before kickoff. How clear your metadata is going in determines how clean the rebuild is on the other side.
*****
On March 19, 2025, Salesforce announced that CPQ — the legacy SteelBrick-based managed package that's been the quote-to-cash backbone for thousands of organizations — was officially End of Sale.
That basically means new customers can no longer buy it. Existing customers can keep running it, but it won't see major innovation. The future is Revenue Cloud Advanced.
The temptation for most teams is to file this under "deal with later." That instinct is wrong — but probably not for the reason you'd think. The deadline that matters isn't the eventual end-of-support date. It's the moment your CPQ system becomes the constraint on everything else you're trying to do: Agentforce, modern pricing models, AI-driven sales motions, M&A consolidation. That moment arrives sooner than the support timeline implies.
This post is about what to do before you start the migration itself. Because the single biggest predictor of whether a CPQ-to-Revenue-Cloud project succeeds isn't the implementation partner, the budget, or the timeline. It's how well you understand what you have today. Most teams underestimate that by an order of magnitude.
The Salesforce CPQ End of Sale: What Actually Happened
In March 2025, Salesforce moved CPQ to maintenance mode. Existing customers retain access and basic support. New customers are directed to Revenue Cloud Advanced — Salesforce's next-generation quote-to-cash platform, built natively on Salesforce Core rather than as a managed package.
This is a meaningful architectural shift. Legacy CPQ is a packaged application that sits on top of Salesforce, with its own object model, its own performance ceiling, and a long inheritance of customizations layered on by every admin who's touched it since 2015. RCA is API-first, metadata-driven, attribute-based, and engineered to plug directly into the rest of the Salesforce stack — including Data Cloud and Agentforce.
The implication is straightforward: this is full reimplementation territory we’re in.
Salesforce CPQ Sunset vs. End of Life: A Distinction That Matters
The Salesforce CPQ sunset is happening in stages. End of Sale (March 2025) means no new licenses to net-new customers. End of Life — when support actually ends — sits somewhere in the 2029-2030 window, depending on contract specifics.
That gap creates a planning illusion. Teams look at the EOL date, see four-plus years of runway, and assume they have time. They don't. Here's why:
- Innovation gap. Every Salesforce release from here forward is being built for RCA, not CPQ. The functional distance between the two platforms is widening every quarter.
- Talent gap. The pool of CPQ-fluent admins and developers is shrinking. Skilled implementers are moving to RCA work because that's where the budgets are.
- Integration drag. Your ERP, billing, and eSignature partners are aligning their roadmaps with RCA. Each release cycle, your CPQ integrations get a little harder to maintain.
- Negotiating leverage. The closer you get to EOL, the less leverage you have in pricing and timeline conversations with Salesforce. Migrations done under deadline pressure cost more.
End of Sale is the warning shot. The cost of waiting compounds quietly.
What Salesforce CPQ End of Life Means for Your Migration Timeline
If you're a CPQ customer, the question isn't whether you'll migrate. It's when, and on whose terms.
The teams that come out of this well are the ones who treat the end-of-life timeline as a budget for doing this thoughtfully — not a deadline to procrastinate against.
Practically: most enterprise CPQ-to-RCA migrations take 9-18 months from kickoff to live. Add three to six months of pre-migration discovery and planning that should happen before the implementation contract gets signed. That puts the realistic ceiling for "starting now" at roughly two years before EOL, if you want margin for testing, change management, and the inevitable surprises.
If you're staring down a 2029-2030 EOL, the planning window is closing in 2027-2028. Which means the discovery and audit work should start this year, not next.
What to Do Before You Migrate to Revenue Cloud
Pre-migration is where most projects quietly fail. Teams jump straight into RCA design without first surfacing what they're actually moving away from. Here's a six-point pre-migration audit worth running before the implementation kickoff.
1. Inventory every customization
Quote Calculator Plugins (QCP), custom Apex triggers, JavaScript pricing logic, custom buttons, custom Lightning components. None of these port directly. Each one has to be evaluated, classified — rebuild, retire, or replace with native RCA functionality — and scoped. If you don't know how many you have, you can't estimate the migration honestly.
2. Map the pricing logic
Salesforce CPQ pricing is famously layered: list price, contracted price, price rules, discount schedules, custom calculations. RCA replaces this with Pricing Procedures and a different rules engine. Before migration, document every rule — what it does, what triggers it, what it depends on. RCA's engine is more powerful but won't accept your old logic verbatim.
3. Catalog the catalog
Most CPQ orgs have catalog sprawl: SKUs created for one-off deals, bundles that haven't been quoted in two years, products kept "just in case." RCA's attribute-based model lets you collapse a 12-SKU laptop catalog into one SKU with two attributes. But that consolidation only works if you've rationalized the catalog first. Look at the last 24 months of quoted products. If something hasn't sold, don't migrate it.
4. Trace dependencies
This is the step most teams skip and most regret. For every important field, flow, and rule, know what touches it upstream and what depends on it downstream. A change to one Price Rule can cascade through five Approval Processes, three Validation Rules, and two integrations. Without that map, your RCA rebuild will reproduce the dependencies you didn't know you had — or, even worse, miss them entirely and discover the gaps in production.
5. Map every integration
ERP, billing, eSignature, contract storage, partner portals, CPQ-adjacent middleware. Each integration touching CPQ needs to be re-pointed at RCA, often with a different data shape on the other end. List them, categorize them by criticality, and identify which need active rework versus simple reconfiguration.
6. Document approval, amendment, and renewal flows
These are where the deepest institutional knowledge lives. The "why does this approval fire when the discount exceeds 12%" logic nobody wrote down. Before migration, get it on paper. RCA's amendment, renewal, and contract lifecycle management are more capable than legacy CPQ — but rebuilding business intent without documentation is how you ship a system nobody trusts.
The metadata problem underneath all of this
Every step of the audit above is fundamentally a metadata problem. You're not really moving CPQ to RCA — you're moving the meaning of your quote-to-cash logic from one architecture to another. The clearer your metadata layer is going in, the cleaner the rebuild on the other side.
This is where a continuous metadata layer earns its keep. Sweep continuously indexes your Salesforce metadata, surfaces dependencies, documents automation, and flags the legacy logic that's quietly going to break the migration if you don't catch it first. Not because metadata tooling makes the project easier — but because it makes the discovery defensible. You can hand an implementation partner a real map instead of a guess.
A migration this big is never going to be painless.
But! The difference between "painful and on schedule" and "painful and 14 months late" almost always ultimately comes down to how honest you were about what you had before you started.
Now want some help in that migration? We know of a continuous metadata layer that could most definitely help.
