Author: Ethan Garonzik, CEO & Founder of Vendori

If you’re considering moving off Salesforce CPQ, it’s tempting to start by documenting everything you have today so you can recreate it somewhere else.

That may be exactly the wrong place to start.

Most Salesforce CPQ environments have evolved over years. Pricing rules were added for old packages. Approval steps were created after one unusual deal. Custom logic solved a specific problem that may or may not still exist. Workarounds became part of the normal process because changing the underlying system was harder than living with them.

A migration gives you a rare opportunity to sort through all of that before it follows you into the next platform.

Salesforce CPQ is currently end of sale, not end of life. Existing customers can continue using it, renew licenses, add users, and receive support. Salesforce has moved its strategic investment toward Revenue Cloud Advanced (RCA), part of Agentforce Revenue Management, but it has also been explicit that existing CPQ customers are not being forced to migrate.

That gives RevOps teams something valuable: time to make a thoughtful decision.

Whether you’re considering RCA or another Salesforce CPQ alternative, the goal shouldn’t simply be to get off one platform and onto another. It should be to come out of the migration with a quote-to-cash process that is easier to operate, easier to change, and better suited to how the business sells today.

Salesforce CPQ migration checklist at a glance

A solid migration plan should answer six questions:

1. How does the business actually sell today?

2. Which parts of the current CPQ should be kept, redesigned, retired, or investigated?

3. What systems and data depend on CPQ?

4. Can the replacement handle the deals that create problems today?

5. Who will own the commercial logic after go-live?

6. How will you move without disrupting active deals, amendments, and renewals?

Salesforce’s own guidance for moving from CPQ to Revenue Management makes a similar point: this is not simply a data transfer. The architecture changes how products, pricing, processes, and data are modeled, which means migration requires business and technical decisions beyond moving records from one system to another.

Here’s how RevOps should approach it.

1. Start with how your business sells, not how Salesforce is configured

Your Salesforce CPQ instance probably doesn’t tell the whole story.

There are the official products, prices, bundles, discounts, and approval rules. Then there are the exceptions your sales team actually uses, the special pricing Finance agreed to three years ago, the amendment process RevOps has quietly patched together, and the spreadsheet Billing checks before invoicing certain customers.

Before you migrate anything, document that reality.

Look at the products and packages you sell today, your pricing models, common discount structures, approval paths, contract terms, renewals, amendments, co-terms, partner deals, and customer-specific exceptions. Pay particular attention to the areas that regularly require manual intervention.

Then compare the business requirement with the way Salesforce CPQ handles it today.

For every significant rule, workflow, customization, or configuration, assign one of four categories:

• KEEP: It solves a real business requirement and works well.

• REDESIGN: The requirement is valid, but the current solution is too complicated, fragile, or manual.

• RETIRE: The requirement no longer exists or isn’t worth maintaining.

• INVESTIGATE: Nobody is quite sure why it exists, what it affects, or what might break if you remove it.

That last category is important. Most experienced RevOps teams know what it feels like to find a rule that everyone is afraid to touch even though nobody remembers why it was created.

That isn’t automatically a migration requirement. It’s something to understand before you rebuild it.

“We’ve always done it this way” is not a migration strategy.

2. Map the quote-to-cash process before deciding what data moves

It’s easy for a CPQ migration to become overly focused on the quoting experience.

Can Sales configure the right products? Does pricing calculate correctly? Does the PDF look good?

Those things matter, but the quote is also where the commercial agreement starts becoming structured data. What happens there affects contracts, billing, Finance, Customer Success, renewals, and reporting.

Map the path from your CRM through CPQ and into the systems that come next. Look for places where information gets re-entered, translated, corrected, or reconciled manually.

If Billing routinely has to interpret what Sales sold, that’s part of the migration problem.

If Finance can’t trust product-level reporting, that’s part of the migration problem.

If Customer Success needs the contract, Salesforce, and a Slack thread to figure out what a customer owns, that’s part of the migration problem too.

Data migration should follow the same logic.

The question isn’t simply, “Can we migrate this?”

It’s “What will the future process actually need?”

Vendori’s general recommendation is to keep the migration focused on open, operational items rather than trying to recreate years of Salesforce CPQ history in the new platform.

There’s a practical reason for that. Salesforce CPQ and Vendori structure data differently, so transforming historical records can require significant ETL work. Rebuilding closed quotes, expired subscriptions, retired products, and years of old pricing may add a lot of scope without adding much operational value.

A transacted quote is typically already tied to an opportunity and reflected in bookings and reporting. In many cases, keeping the historical quote PDF accessible is far simpler than recreating that transaction in a new CPQ, especially when the original products or pricing no longer exist.

Open items need a different approach.

If a quote is already in front of the customer, it generally needs to be recreated in Vendori so it can be transacted there once the customer signs.

For quotes that haven’t reached the customer yet, teams have a choice. They can be manually re-entered in the new system or included in the ETL effort. Manual entry reduces migration work but may mean a rep has to build the same quote twice during the transition, so some teams choose to move that work to the ETL team instead.

The right balance depends on volume, timing, and how much disruption the Sales team can reasonably absorb.

The principle is simple:

Migrate what the business still needs to operate. Archive what it only needs to remember.

3. Bring the deal that breaks your CPQ

Once you begin looking at replacement platforms, don’t spend the entire demo on the deal every system can handle.

You already know a CPQ can add 100 licenses, apply a standard discount, and generate a quote.

Give the vendor the deal your RevOps team dreads instead.

Maybe it’s an enterprise customer with legacy pricing, a custom bundle, a multi-year ramp, a mid-contract expansion, a special approval path, and a co-termed renewal. Maybe your nightmare deal looks completely different.

The specifics matter less than using a scenario that exposes the complexity of your business.

Ask the vendor to take it through the lifecycle, not just initial quoting. What happens when the customer expands? How is an amendment handled? What does Billing receive? What does the renewal look like?

Then change something.

Suppose Finance lowers the discount threshold next quarter. Product launches a new package. The CRO wants to test a different pricing model.

How does that change get made?

That’s where you start to see the difference between platforms that can technically support your requirements and platforms your team can realistically operate.

Bring the deal that breaks your CPQ.

4. Decide who should own the logic after go-live

This is where many CPQ evaluations stop too early.

A system can meet every requirement on the feature checklist and still leave RevOps dependent on an administrator, developer, consultant, or professional services team every time the business changes.

Before you choose a replacement, decide what you actually want the operating model to be.

Should RevOps be able to change pricing? Create a bundle? Update an approval rule? Add a product? Adjust a quote template? Support a new pricing model?

There isn’t one right answer for every organization, and governance still matters. Finance should have control over pricing policy. Legal should have control over legal terms. Changes should be documented and auditable.

But governance is different from technical dependency.

If RevOps is accountable for deal velocity, data quality, pricing operations, renewals, and the broader revenue process, the team should have an appropriate level of control over the system that drives those outcomes.

This is a big part of Vendori’s approach. Vendori’s no-code model is designed to give revenue teams more direct control over products, pricing, approvals, and quoting logic instead of making routine commercial changes another technical project.

The migration team eventually leaves. RevOps still has to run the system.

That’s worth evaluating before you sign anything.

5. Plan the migration around the business that’s still happening

There is no magical week when Sales stops selling so you can replace CPQ.

You’ll have open opportunities, quotes awaiting approval, contracts being negotiated, customers expanding, amendments in progress, and renewals approaching.

Your migration plan needs to account for them.

Decide how you’ll handle transactions that are already in flight, which system becomes the source of truth at each stage of the cutover, and whether you need a temporary freeze window. Pay particular attention to deals that cross the migration date and recurring-revenue activity that depends on existing contract or asset data.

For quotes already sitting with a customer, the handoff deserves special attention. You need a clear plan for recreating the quote in the new CPQ and transacting it there if and when the customer signs.

Quotes that are still internal create a different tradeoff. Re-entering them manually may be simpler from a migration perspective but creates duplicate work for Sales. Moving them through ETL can reduce that disruption but adds transformation effort to the project.

There is no universal answer. The important thing is to make the decision intentionally rather than discovering the problem during cutover.

Salesforce recommends a phased readiness process for Revenue Management migrations and says there is no fixed timeframe; the pace should reflect the complexity and needs of the individual business.

Testing also needs to go well beyond creating a new quote. Run the lifecycle scenarios that matter to your business: amendments, expansions, downgrades, cancellations, co-terms, partial renewals, and pricing changes.

Then define what success looks like.

Going live on time is a project milestone. It doesn’t tell you whether the new CPQ improved anything.

RevOps should be watching operational measures such as approval turnaround, quote errors, billing corrections, time to launch new pricing, admin tickets, consultant hours, and how quickly the team can adapt when the business changes.

6. Choose where you want to go, not just what you’re leaving

Salesforce CPQ customers currently have several options.

You can stay on CPQ for now. For organizations with a stable implementation and manageable maintenance burden, that may be a perfectly reasonable short-term choice. Salesforce says CPQ remains supported, although it is now in maintenance mode and new product innovation is focused elsewhere.

You can move to Revenue Cloud Advanced. Salesforce positions RCA as the successor to Salesforce CPQ, but the company also makes clear that the two products are built on different architectures. Salesforce has published migration tooling and guidance specifically for that transition, and it supports coexistence between CPQ and Revenue Management in qualifying environments.

Or you can evaluate another CPQ platform. If you’re at that stage, it helps to understand why other RevOps teams are looking at alternatives in the first place.

The important thing is not to let your current architecture make the next decision for you.

If you’re already doing the work to understand your pricing, products, approvals, data, integrations, and lifecycle processes, use the opportunity to define what you want the next few years of RevOps to look like.

Maybe that means staying deeply within Salesforce. Maybe it means prioritizing a CPQ that is easier for RevOps to own. Maybe implementation effort, CRM flexibility, or consultant dependency becomes more important than it was the last time you selected CPQ.

The migration itself is temporary.

The operating model you choose next isn’t.

Where Vendori fits

Vendori was built for SaaS, AI, and B2B technology companies that want sophisticated CPQ capabilities without turning routine changes into technical projects.

The goal isn’t simply to make quote creation faster. It’s to give RevOps more control over the commercial logic behind pricing, products, approvals, subscriptions, amendments, renewals, and the systems that depend on that information.

For teams evaluating life after Salesforce CPQ, that’s an important distinction.

Don’t just ask whether your replacement can recreate what you have today.

Ask whether you’ll still want to operate it three years from now.

Want to pressure-test Vendori?

Don’t bring us your easiest quote. Bring the pricing rule nobody wants to touch, the bundle that always creates an exception, or the renewal your team has to reconstruct every year.

>> Bring Vendori your hardest deal and see how we’d build it.

Salesforce CPQ Migration FAQs

Is Salesforce CPQ end of life?

No. Salesforce CPQ is end of sale, not end of life. Existing customers can continue using it, renew licenses, add users, and receive support. Salesforce has not announced an end-of-life date, although CPQ is now in maintenance mode and Salesforce’s new investment is focused on Revenue Cloud Advanced and the broader Agentforce Revenue Management suite.

Do we have to move from Salesforce CPQ to Revenue Cloud Advanced?

No. Salesforce says there is no forced migration. Revenue Cloud Advanced is Salesforce’s successor to CPQ, but existing customers can continue using CPQ while they determine the right long-term approach.

What should we migrate from Salesforce CPQ?

Focus first on open items and data the future process still needs to operate.

That may include active products and pricing, open quotes, active subscriptions or assets, contracts, amendments, renewals, and the data required by downstream systems.

Historical records should be treated differently. Closed quotes, expired subscriptions, retired products, and old pricing often don’t need to be recreated in the new CPQ simply because they exist.

For Vendori migrations, the general recommendation is to limit ETL scope where possible and preserve closed historical transactions in a simpler archive, such as retaining quote PDFs and the related Salesforce opportunity and booking history.

Open quotes require more planning. Quotes already with a customer generally need to be recreated in Vendori so they can be transacted there after signature. Earlier-stage quotes may be manually re-entered or migrated through ETL depending on volume and the amount of duplicate work the organization wants Sales to absorb.

How long does a Salesforce CPQ migration take?

There isn’t one universal timeline. Complexity depends on your product catalog, pricing logic, customizations, integrations, data, lifecycle workflows, and destination platform.

Salesforce says there is no set timeframe for its Revenue Management migration-readiness process and recommends moving at a pace that reflects the needs and complexity of the business.

Migration scope also matters. Trying to transform years of closed transactions and historical configurations can add significant work compared with focusing on the open operational items the business actually needs going forward.

The better place to start is understanding how much of your current Salesforce CPQ implementation is actually worth rebuilding.