Salesforce CPQ to Revenue Cloud Migration: A Practical Playbook

Salesforce CPQ entered End of Sale in March 2025. Existing customers can still renew licences and use the product, but Salesforce has stopped selling it to new customers and has redirected development investment entirely toward Revenue Cloud, now marketed as Agentforce Revenue Management. For SaaS teams still running on CPQ, the question is no longer if they migrate but when and how.

This guide is written for everyone who needs to plan that move seriously. We cover what actually changes at the architecture level, how to assess readiness, how to structure a phased rollout, and, equally important, when it still makes sense to wait.

Why Teams Move Beyond CPQ-Only Architecture

Salesforce CPQ was designed to solve one problem well: getting accurate, approved quotes out of sales reps’ hands and into customers’ inboxes faster. For many B2B SaaS companies scaling through an outbound sales motion, it did exactly that.

The gap shows up later in the lifecycle. Once a deal is signed, CPQ’s role effectively ends. Renewals, amendments, usage billing, and invoice reconciliation have to be handled elsewhere, often in a patchwork of Salesforce Billing, ERP integrations, and custom Apex. Each handoff is a potential failure point, and each custom connector is a maintenance liability.

The revenue lifecycle for a typical SaaS business now includes:

• Initial configuration and quoting
• Contract execution and CLM
• Order management and provisioning signals
• Subscription management across the customer lifetime
• Usage-based or ramp billing events
• Invoicing, revenue recognition, and compliance reporting
• Renewal quoting triggered by contract milestones

CPQ was never built to govern that entire chain. Agentforce Revenue Management is. The architectural shift from a quote-centric managed package to a lifecycle-oriented native platform is the core reason migration conversations are accelerating.

What Changes When You Move to Agentforce Revenue Management

The naming has gone through several iterations: Revenue Lifecycle Management in Spring 2024, Revenue Cloud Advanced through most of 2025, and Agentforce Revenue Management since Dreamforce 2025, but the architectural substance beneath the rebrand is consistent. Understanding that substance matters before committing to a migration.

What to Assess Before Migration

The most common migration regrets stem from starting too fast and discovering dependencies late. A structured readiness assessment before any implementation work begins is not optional; it directly determines whether your migration takes 12 months or 24, and whether your first pilot succeeds or forces a rollback.

Questions to answer before migration:

• Pricing model: How many price books, discount schedules, and exception rules exist?
• Subscription logic: Are there usage-based, ramp, or co-term scenarios in active contracts?
• Billing dependencies: Does CPQ feed Salesforce Billing, an ERP, or both?
• Integrations: Which external systems consume quote/order data via API?
• User roles: Which teams touch quoting, approval, contracting, and invoicing?
• Downstream reporting: Which dashboards rely on SBQQ objects that will not exist in the new model?
• Active contracts: How many open contracts must coexist during a parallel-run period?

Beyond the checklist, the most important diagnostic question is straightforward: can you actually describe, in plain English, how your current pricing logic works? If the honest answer involves phrases like ‘I think there is a rule for that somewhere’ or ‘that was set up by someone who left’, the migration is also a documentation and knowledge recovery project. That time needs to be factored into the plan.

A Phased Migration Plan

Every credible source on this migration (Salesforce partners, independent consultants, enterprise practitioners) agrees on one point: a big-bang cutover is too risky for organizations with active contracts and multi-team quoting workflows. A phased approach is very advisable and is the standard for successful migrations.

Phase 1: Audit and Documentation (weeks 1–6)

Inventory every CPQ object that currently drives business logic: Price Books, Product Rules, Price Rules, Discount Schedules, Quote Templates, Approval processes, and all custom Apex tied to SBQQ objects. Export and document everything. This phase often surfaces logic that nobody currently on the team fully understands, which is a risk to manage rather than skip past.

Phase 2: Logic Mapping and Architecture Design (weeks 4–10)

Map each CPQ construct to its Agentforce Revenue Management equivalent. Some mappings are direct, and many require redesign. Pricing Procedures and Decision Tables offer more flexibility than CPQ’s rule engine, but that flexibility requires deliberate design decisions rather than a copy-paste migration. Involve the revenue architect and the finance team here because both own the output.

Phase 3: Sandbox Build and Dependency Validation (weeks 8–16)

Build the new configuration in a full-copy sandbox before touching production. Validate every integration point: ERP connections, billing triggers, reporting dashboards, and any downstream systems that read CPQ objects via API. Integration failure is one of the leading causes of go-live delays in CPQ migrations, so catching it in the sandbox is far less expensive than discovering it post-launch.

Phase 4: Pilot Rollout (weeks 14–22)

Select one product line, one business unit, or one geographic market and go live on Agentforce Revenue Management for new business only. Existing contracts remain on CPQ during the parallel-run period. This protects revenue continuity while generating real operational data. Measure quote accuracy, approval cycle time, and user adoption rate before expanding.

Phase 5: Phased Full Adoption (months 6–18+)

Expand by business unit or product line based on pilot results. Historical quotes and contracts typically remain in CPQ in read-only mode. Net-new business and renewals migrate progressively. The total timeline for mid-market to enterprise organizations is commonly 12 to 24 months. Not because the technology is slow, but because change management, data quality remediation, and integration work all take real time.

Common Migration Risks

Most migration problems are predictable. The teams that navigate them best do so not because they avoided the problems, but because they identified them early enough to manage them deliberately.

• Pricing logic gaps

CPQ’s discount and pricing rule engine has accumulated years of exceptions and edge cases in most long-running implementations. When those rules are manually mapped to Pricing Procedures, it is common to discover that some logic was never formally documented. It was effectively tribal knowledge embedded in a configuration. Testing for price accuracy across a full range of deal scenarios, including edge cases, before go-live is non-negotiable.

• Hidden SBQQ dependencies

Custom Apex classes, triggers, flows, and third-party AppExchange packages may reference SBQQ objects directly. These do not migrate automatically and will break if not identified and rerouted. A dependency scan of the org before migration begins is worth the effort.

• Broken reports and dashboards

Sales and finance teams often have reporting infrastructure built on SBQQ report types that will not exist in the new data model. Identify all dashboards that use CPQ-specific objects and plan their rebuild in advance. Discovering this the week before go-live, with a VP of Sales asking why their pipeline report is empty, is avoidable.

• Change management underestimated

The teams most affected by this migration (sales reps, deal desk, RevOps analysts, finance) are also the teams whose productivity most directly drives revenue. Migrations that treat user enablement as a final-phase activity consistently underperform on adoption. Executive sponsorship, role-based training, and clear communication about why the change is happening need to be built into the project from day one, not added on afterward.

When Not to Migrate Yet

The fact that CPQ is End of Sale does not mean every organization should begin migration immediately. Migrating before your organization is ready tends to produce the exact outcome teams are trying to avoid. The case for waiting is strongest when your CPQ implementation carries undocumented logic with no institutional memory to explain it.

It also applies when a major M&A, reorg, or business model shift is already in flight, when RevOps bandwidth is absorbed by another strategic initiative, or when your CPQ footprint is straightforward enough that optimizing the current stack costs less than a full platform rebuild.

When any of those conditions apply, the better move is to document your current configuration thoroughly, maintain your Salesforce contract, and schedule the migration for a window where the project can receive the focus it requires.

Need help with implementing Salesforce Revenue Cloud?
If you are evaluating how self-service portals and customer-facing subscription experiences fit into your Salesforce architecture alongside this migration, our work at Advanced Communities on self-service experience on Salesforce covers the UX and portal layer that sits above the revenue lifecycle: a practical portal layer on Salesforce that complements the back-end changes a Revenue Cloud migration involves.