Migrating CPQ Classic to RLM: A 4-Phase Production Roadmap

Salesforce has stopped investing in CPQ Classic. New features land in Revenue Lifecycle Management (RLM) instead. The product is not dead, but it is frozen. Every org running CPQ Classic now has the same question: when do we move, and how.

The migration is a real project. On a mid-sized org with a few hundred products, a couple of regional price books, a handful of approval processes, and the usual custom Apex layered in over the years, the realistic timeline runs 6 to 12 months. Compressing it produces the kind of post-go-live incidents that take quarters to clean up.

The work splits cleanly into four phases. The mistakes happen when teams skip a phase or compress one that genuinely needs its full duration.

Phase 1: Audit (2 to 4 weeks)

The first job is to know what is actually in production. Most teams underestimate this. CPQ Classic has been live for years, customizations have accumulated, the documentation describes the system as it was designed rather than as it is now.

The audit inventories every artifact that the migration has to address:

• Products and price books, with counts and currency variants
• Discount schedules, price rules, and product rules
• Approval processes, including the Advanced Approvals package if installed
• Quote templates and any custom rendering logic
• Custom fields on every CPQ object (Quote, Order, Subscription, Asset)
• Custom objects that extend the CPQ data model
• Apex triggers and classes that customize CPQ behavior
• Validation rules, workflow rules, Process Builder flows, and modern Flows
• Permission sets and profiles that gate CPQ access

For each artifact, the audit assigns a complexity tier. Simple items (standard config, no customization) are 1 to 2 days of migration work each. Medium items (some custom logic) are roughly a week. Complex items (heavy customization or multi-system dependencies) are a month or more.

The total weeks summed across artifacts, with a 30 percent buffer for unknowns, is the rough migration estimate. On Sapota's engagements, the audit alone has surfaced features in production that nobody on the current team remembered building. That discovery is exactly why this phase cannot be skipped.

Phase 2: Map (4 to 8 weeks)

With the inventory in hand, every CPQ Classic artifact gets a designed RLM equivalent. This is not a one-to-one translation. RLM organizes pricing, product configuration, approvals, and subscription management differently. Some CPQ patterns have direct equivalents. Some require redesign.

A typical mapping reference:

CPQ ClassicRLM equivalentProduct OptionBundle ComponentProduct FeatureConfigurator CategoryProduct Rule (validation type)CML ConstraintPrice RulePricing Procedure stepDiscount SchedulePricing Procedure Decision TableQuote TemplateRLM Quote TemplateAdvanced ApprovalsSmart ApprovalsSubscription Management (managed package)RLM Subscription (native)Asset recordsRLM-Managed AssetRenewal ManagerRenewal Flow Template

The mapping work produces design documents per artifact. Each design gets reviewed with the stakeholders who own the underlying business logic: pricing analysts for pricing rules, deal desk for approval flows, finance for renewals.

Two patterns that derail this phase:

The first is treating the mapping as a developer-only exercise. The CPQ Classic configuration encodes years of business decisions. Migrating without business sign-off produces a technically correct RLM setup that does not match how the business actually sells. Build the design reviews in.

The second is trying to fix legacy quirks during migration. The CPQ Classic config has accumulated workarounds and shortcuts that nobody remembers the reason for. The temptation is to design RLM from scratch and clean up. The right move is to migrate first, keep behavior identical, and refactor after parallel run completes. Cleanup work mixed with migration work produces incidents that are nearly impossible to diagnose.

Phase 3: Parallel run (3 to 6 months)

Both CPQ Classic and RLM are live simultaneously. Existing deals stay in CPQ Classic and complete their lifecycle there. New deals start in RLM. Renewals from CPQ Classic deals move to RLM gradually as renewal dates arrive.

This phase is where the real validation happens. The configuration that looked right in design produces actual quotes that the team can compare against historical CPQ quotes. The discrepancies fall into three categories:

Configuration bugs. The RLM setup is genuinely wrong, the pricing produces incorrect totals or the approval routes to the wrong manager. Standard debugging.

Intentional differences. The RLM design corrected a CPQ Classic quirk and the new behavior is what was wanted. The team confirms and moves on.

Edge case surprises. A combination of inputs nobody anticipated produces unexpected output. The kind of thing that only emerges from running real deals through the new system. This is what makes parallel run mandatory rather than optional.

Three operational practices that make parallel run productive:

Daily comparison reports of equivalent quotes between the two systems for the first 4 to 6 weeks. After the obvious discrepancies are resolved, the comparison frequency drops to weekly.

Clear rules for which deals go to which system. A documented decision tree for sales reps. Confusion here produces deals that should have been in RLM ending up in CPQ Classic and vice versa, contaminating the parallel run data.

Stakeholder readiness for the duration. Three to six months is a long parallel run, and stakeholders get impatient. The executive sponsor needs to back the schedule, not collapse it under pressure.

Phase 4: Decommission (1 to 2 months)

All deals have migrated. The last CPQ Classic renewal has converted. The system is no longer needed.

The decommission phase is cheap but easy to skip. Three actions matter:

• Uninstall the CPQ Classic managed package to reclaim org space and reduce license cost.
• Archive historical CPQ Classic data to a reporting system or data warehouse. Compliance requirements often mandate retention for years even after operational use ends.
• Update documentation, runbooks, and onboarding materials to remove CPQ Classic references. New hires should not learn about a system that no longer exists.

The cost of skipping this phase is a long tail of legacy references and a quarterly question of "do we still need CPQ Classic licenses." Knock it out cleanly.

Principles that hold across all four phases

A few practices that Sapota's Salesforce team enforces on every Revenue Cloud migration engagement:

• Version-control the configuration. Both CPQ Classic and RLM configuration should live in source control via metadata APIs. The migration produces clear before-and-after diffs that aid review and rollback.
• Track migration in a single artifact. A migration tracker spreadsheet (or Jira board) with one row per CPQ Classic artifact, its mapped RLM design, current status, and the engineer responsible. Visible to all stakeholders.
• Plan the renewal cliff explicitly. Renewals are the moment a CPQ Classic deal converts to RLM. Renewal volume per month is the bottleneck on migration velocity. Match the parallel-run duration to the renewal cycle.
• Keep finance in the loop. Revenue recognition, accounting integrations, and reporting all read from CPQ Classic and RLM data. Finance has to validate both during parallel run and again at decommission.

When to start

Programs that have not started the migration have a finite window. Salesforce's stated direction is clear, even if the formal end-of-life date keeps shifting. The leverage is in starting before the parallel run becomes a forced sprint rather than a chosen pace.

Sapota's Salesforce team holds the Revenue Cloud Consultant credential (passed May 2026) and has shipped CPQ Classic to RLM migrations across mid-market SaaS, enterprise telco, and B2B subscription commerce engagements. The 4-phase roadmap above is what we run on every engagement, adapted to the artifact volume and complexity of the specific org.

---

Planning or running a CPQ Classic to RLM migration? Sapota's Salesforce team handles audit, mapping, parallel run, and decommission on production engagements. Get in touch ->

See our full platform services for the stack we cover.