

Salesforce CPQ went end of sale in March 2025, meaning it is no longer sold to new customers, though existing customers keep their licenses and support. Salesforce has not published an official end-of-life date, but its product investment and AI roadmap are now centered on Agentforce Revenue Management (formerly Revenue Cloud). A typical migration runs three to six months for simpler orgs and twelve to twenty-four months for complex, highly customized deployments. This guide walks through what end of sale actually means, how to decide when to move, and the practical steps that keep a migration from disrupting revenue operations.
Not immediately, and this distinction matters more than most headlines suggest. Salesforce placed CPQ into end-of-sale status in March 2025. That means new customers cannot purchase it, but if you are already running it, nothing changes automatically. You can continue using CPQ, renew licenses, add users, and receive support under your existing contract terms. There is no forced migration.
What has changed is where Salesforce is putting its development effort. New feature investment has shifted to Revenue Cloud Advanced, now known as Agentforce Revenue Management, and Salesforce’s long-term innovation focus is no longer on the legacy CPQ managed package. No official end-of-life date has been announced, and partner commentary and ecosystem analysts generally estimate a window sometime around 2029 to 2030 based on typical enterprise software lifecycles, though this is a projection rather than an official Salesforce statement.
In plain terms: You are not on a forced clock, but you are on a shrinking runway of new capability. Every quarter you stay on legacy CPQ is a quarter you are not benefiting from Salesforce’s current investment, and it is a quarter of additional customization that will eventually need to be migrated anyway.
There is a structural reason this is a “when,” not an “if,” for most organizations running CPQ today: agent compatibility.
Agentforce agents run on Salesforce’s core-native object model, meaning standard Quote, Order, and Contract objects, while legacy CPQ sits outside that model as a managed package. If your organization wants Agentforce agents to operate inside revenue workflows, generating quotes, flagging pricing exceptions, or drafting renewal proposals, staying on legacy CPQ indefinitely puts a hard ceiling on how deep that automation can go.
There is also a compounding cost problem. Every new customization added to legacy CPQ today becomes additional migration complexity later. Every workaround, every ad-hoc script, and every spreadsheet a sales team builds because CPQ cannot handle a pricing edge case becomes friction the migration project has to absorb eventually. Waiting does not avoid the work. It just adds interest to it.
Before committing to a specific migration plan, it is worth being clear that Revenue Management is not the only option, even if it is the path of least resistance for most Salesforce-native organizations.
1. Migrate to Agentforce Revenue Management: Stay inside the Salesforce ecosystem and move to the platform Salesforce is actively developing. This is the most common path for organizations already invested in Salesforce for sales, service, and now agentic AI.
2. Switch to a specialized third-party CPQ: Some organizations, particularly those with highly complex configuration rules or multi-CRM environments, evaluate dedicated CPQ platforms built outside Salesforce’s core architecture.
3. Replace CPQ only, keep core Salesforce CRM: For organizations where quoting complexity is limited, building a lighter, purpose-built quoting layer while keeping Salesforce CRM as the system of record is sometimes the more efficient move.
The right choice depends heavily on how deeply CPQ is integrated with your ERP, how much of the broader Salesforce and Agentforce ecosystem you plan to use, and how much of your current CPQ configuration is genuinely necessary versus historical accumulation.
Timelines vary significantly based on complexity, and vendor-published estimates are often optimistic. A more realistic range, based on 2026 implementation data across multiple sources:

A typical migration runs three to six months from discovery through go-live for straightforward deployments, but complex implementations with extensive custom logic, large product catalogs, and multiple integrations can take considerably longer. Treat any vendor quote that promises a complex, highly customized migration in under three months with real skepticism.
Before scoping anything, get a clear inventory of what is actually running in your org: product bundles, pricing rules, discount schedules, approval matrices, quote templates, and every custom Apex trigger or Visualforce component touching the CPQ objects. Most organizations are surprised by how much of their configuration is legacy workarounds that no longer serve a real business need. This is the point to decide what gets migrated as-is, what gets rebuilt cleaner, and what gets retired entirely.
Legacy CPQ uses its own object structure layered on top of Salesforce. Agentforce Revenue Management is built on standard Quote, Order, Contract, and Product2-based objects. This means data migration is not a simple export-import. It requires field-by-field mapping, and decisions about how historical quotes, contracts, and pricing history will be represented in the new model.
Rather than lifting and shifting every custom rule, this is the moment to rebuild pricing procedures using Revenue Management’s native pricing engine and approval framework. Organizations that treat this as a like-for-like technical port tend to carry forward the same complexity that made the old system hard to maintain. Organizations that treat it as a redesign opportunity generally end up with a leaner, more sustainable configuration.
Run a full parallel test: process a representative sample of real historical quotes and orders through the new system and compare outputs against what legacy CPQ produced. Discrepancies at this stage are far cheaper to catch than discrepancies discovered after go-live with a live customer quote.
Rather than a single big-bang cutover across the entire sales organization, many teams migrate by product line, business unit, or region, validating each cohort before expanding. This limits the blast radius if something goes wrong and gives the revenue operations team a chance to catch issues while they are still small.
The underlying data model changes enough that this is not a cosmetic UI update for end users. Sales reps need training on the new quoting flow, finance needs to understand how billing and revenue recognition now connect, and anyone managing approvals needs to know where those workflows live in the new system.
Budget real time and attention for the first one to two full quote-to-cash cycles after cutover. Pricing edge cases and approval routing issues tend to surface only when real deals with real complexity move through the system, not during testing with sanitized sample data.
Data is where most CPQ migration timelines slip, so it deserves its own checklist separate from the general process above:
• Product catalog data: Product bundles, options, features, and configuration rules, cleaned of discontinued or duplicate items before migration rather than after
• Pricing data: Price books, discount schedules, and any tiered or volume-based pricing logic, mapped explicitly to the new pricing procedure structure
• Historical quotes and contracts: Decide early whether historical records need to be fully migrated, archived as read-only, or accessible through a reporting layer, since this materially affects both timeline and cost
• Approval history: Especially important for regulated industries or organizations with audit requirements around discount approvals
• Integration touchpoints: Every system that currently reads from or writes to CPQ objects, including ERP systems, billing platforms, and any custom middleware, needs to be re-pointed and tested against the new object model
Treating data migration as a distinct workstream with its own owner, rather than a subtask of the broader implementation, is one of the more reliable ways to keep the overall project on schedule.
• Underestimating custom logic: Organizations that have run CPQ for years often have significant undocumented customization. A thorough discovery phase before scoping timeline and budget prevents the most common source of overruns.
• Treating it as an upgrade instead of a re-implementation: Revenue Management is architecturally different from legacy CPQ. Approaching this as a configuration change rather than a rebuild leads to underscoped projects that stall midway.
• Skipping the parallel testing phase to save time: This is the step most likely to get cut under deadline pressure, and it is the step most likely to prevent a costly production incident.
• No clear rollback plan: Especially for cohort-based cutovers, define in advance what triggers a rollback for a given business unit and how that would work operationally.
• Migrating too late: Waiting until commercial or support pressure forces the decision means migrating under time pressure, which inflates both cost and risk. Starting evaluation while you still have full optionality is consistently the better position to negotiate and plan from.
A reasonable framework for timing this decision:
• Start evaluation now if your CPQ configuration is already straining under pricing complexity, if you are planning to deploy Agentforce agents into revenue workflows, or if you are approaching a major renewal or replatforming decision anyway.
• Plan for 2026 to 2027 if your current setup is stable but you want to avoid a rushed, reactive migration later. Beginning evaluation gives you time to finish the move well ahead of any eventual end-of-life window and negotiate from a position of choice rather than urgency.
• Deprioritize for now, but revisit annually if your quoting needs are genuinely simple, your CPQ instance is lightly customized, and you have no near-term plans to expand into agentic revenue workflows. Even in this case, keep this decision on your annual technology roadmap rather than filing it away indefinitely.
Across 2026 migration projects, the deployments that stayed on time and on budget shared a few traits regardless of company size:
• They started with an honest audit rather than assuming their existing configuration would translate directly
• They treated the migration as a chance to simplify pricing and approval logic, not just replicate it
• They ran a genuine parallel-testing phase with real historical data before cutover
• They phased the rollout instead of attempting a single cutover across the entire sales organization
• They brought in a partner with hands-on Revenue Management and Agentforce implementation experience rather than treating it as a standard admin configuration task
That last point matters more than it might seem. Agentforce Revenue Management is still a maturing platform, and the gap between what is marketed and what is fully available out of the box is real in places. An experienced implementation partner knows where those gaps currently sit and how to design around them rather than discovering them mid-project.
SaasWorx works with Salesforce customers across the USA to plan and execute quote-to-cash migrations without disrupting active revenue operations. Our approach starts with a configuration audit and readiness assessment, moves through a phased implementation with parallel testing built in, and includes the change management work that determines whether sales and finance teams actually adopt the new system. Because our team also builds Agentforce agents on the Agentforce Revenue Management platform, we design the migration with agentic workflows in mind from the start, rather than treating AI enablement as a separate project later.
If you are weighing whether now is the right time to move, or want a second opinion on a migration scope you have already received, you can talk to our Salesforce and Agentforce team about your specific environment. For background on the platform itself, see our companion guide, What Is Salesforce Revenue Cloud, Now Agentforce Revenue Management.
Is Salesforce CPQ end of life?
Not yet. It is end of sale as of March 2025, meaning no new customers can purchase it, but existing customers keep their licenses and support. No official end-of-life date has been announced, though partner estimates generally point to a window around 2029 to 2030 based on typical enterprise software lifecycles.
Do I have to migrate to Agentforce Revenue Management?
No. You have three realistic paths: migrate to Revenue Management, move to an alternative CPQ platform, or keep Salesforce CRM and replace only the quoting layer. The right choice depends on your ERP integration complexity and how much of the Salesforce ecosystem you use.
How long does a CPQ to Agentforce Revenue Management migration take? Simple deployments typically take three to six months. Complex, heavily customized implementations with multiple integrations can take twelve to twenty-four months. Treat significantly shorter timelines for complex environments with caution.
Can I keep using Salesforce CPQ while I plan a migration?
Yes. There is no forced cutoff. Existing customers can continue renewing licenses, adding users, and receiving support while they plan and execute a migration on their own timeline.
What is the biggest risk in a CPQ migration?
Underestimating undocumented customization is the most common cause of budget and timeline overruns. A thorough discovery and audit phase before finalizing scope is the single highest-leverage step in avoiding this.
Salesforce CPQ’s end-of-sale status is not an emergency, but it is a clear signal about where the platform’s future lies. The organizations approaching this well in 2026 are treating it as a planned architectural decision made on their own timeline, not a reactive scramble triggered by a support deadline. Starting the evaluation now, even if the actual migration is a year or two out, is what keeps that timeline in your control.













