CPQ Classic or RLM: When to Wait, When to Switch, When to Dual-Track

Every Salesforce org running CPQ Classic has the same question: when to move to RLM. Salesforce has been clear about the direction. CPQ Classic gets bug fixes, RLM gets investment. New features land on RLM only. The end of life date for CPQ Classic has not been formally announced and keeps shifting, but the strategic answer is settled.

What is not settled is the timing for any specific org. Migrating too early means investing in a not-yet-mature target. Migrating too late means a forced sprint with renewal volume stacked against the calendar. The right answer is org-specific and shows up in five signals.

Signal 1: How customized is the current CPQ Classic setup

The audit phase of any migration produces an artifact count. A vanilla CPQ Classic with a few hundred products, standard pricing, and out-of-the-box approvals migrates in 3 to 4 months end to end. The same org with hundreds of Apex triggers, custom objects, and an Advanced Approvals package configured over five years takes 9 to 12 months.

The high-customization case has two implications. The migration itself is expensive. The CPQ Classic investment in customizations is also at risk because some customizations may not translate cleanly. The customization debt is real and should factor into the timing decision rather than be discovered halfway through audit.

Teams with high customization should start the audit phase now, even if the actual migration is months away. The audit takes 2 to 4 weeks and produces the realistic complexity picture. Decision quality improves with audit data.

Signal 2: Upcoming renewal cycle volume

Renewals are the moment a deal natively transitions from CPQ Classic to RLM. The renewal cycle determines how fast existing CPQ Classic deals can move out of CPQ Classic without disrupting customers.

An org with monthly renewals spread roughly evenly across the year completes its renewal-driven migration in 12 months. An org with a heavy Q4 renewal cliff (because most contracts were signed in a single fiscal year) can complete in 3 to 6 months, but only if the parallel run is timed to capture that cliff.

The implication: time the start of the migration relative to renewal volume. Beginning a 3 to 6 month parallel run six months before the renewal cliff captures the maximum number of renewals through RLM. Beginning right after a cliff means waiting another year for the next one.

Signal 3: Stability of the current CPQ Classic configuration

Orgs that change CPQ Classic frequently (new product launches, pricing model shifts, approval restructures) face a moving target during migration. Every CPQ Classic change has to be mirrored in the RLM design, often mid-migration. Parallel run discrepancies multiply.

Orgs that have a stable CPQ Classic configuration (no major changes planned for 12 months) have an easier migration. The target is fixed, the mapping is one-time, the parallel run validates against a steady baseline.

If a major pricing overhaul or product line launch is imminent, the right move is often to do the change in CPQ Classic first, stabilize for 3 to 6 months, then start the migration. The alternative (migrating mid-change) produces failure modes that confuse RLM bugs with CPQ Classic bugs and take twice as long to resolve.

Signal 4: New feature dependencies

RLM has features that CPQ Classic does not, and the gap is widening. Notable additions over the past two years include native Subscription Management, Smart Approvals with parallel routing, Pricing Procedure decision tables, and integrated revenue recognition.

Some of these are competitive needs. An org that needs Smart Approvals to handle parallel approver routing for a new buyer-group sales motion has a forcing function. The migration becomes the path to that feature.

Other RLM features are nice-to-have but not blocking. An org that does not need anything RLM-only is freer to choose timing based on the other signals.

The decision: list the RLM features the business is asking for. If any are urgent, the migration timeline compresses. If none are, the migration can wait for a better window.

Signal 5: Team capacity and concurrent priorities

A migration is not a side project. The team running it (BA, developer, QA, deal desk, finance representative) needs dedicated capacity for the duration. On a 6 to 12 month timeline, that capacity has to be planned around other commitments.

Orgs in the middle of a Salesforce Sales Cloud reorganization, a major CRM data migration, or a finance system replacement should not also be running an RLM migration. The capacity is not there, and the failure modes from these projects interact (Sales Cloud reorg changes opportunity ownership while RLM migration is moving quotes between systems, and now you cannot tell which quote belongs to which rep).

The cleaner sequencing is to finish other major projects first, then commit to the RLM migration as the next big initiative. Trying to do both produces incomplete results in both.

The dual-track option

Some orgs can run CPQ Classic and RLM simultaneously for longer than a typical parallel run. The pattern works when:

• The business has multiple distinct sales motions (e.g., enterprise direct and SMB self-service) with different revenue lifecycles.
• One motion is fully RLM-ready, the other still needs CPQ Classic-specific features that have not yet been ported.
• The team has the capacity to maintain both systems indefinitely.

Dual-track is more expensive operationally (two systems, two sets of integrations, two governance models) but lets the org capture RLM benefits for the motion that needs them while preserving CPQ Classic for the motion that depends on it. The cost is justifiable for some orgs and overkill for most.

Sapota generally advises against extended dual-track. The migration cost is incurred once; the dual-track cost compounds quarterly. Plan to consolidate within 12 to 18 months even when starting dual-track.

The cost of waiting too long

The risk of indefinite postponement is real. As Salesforce's CPQ Classic investment continues to decrease, three pressures build:

• New features land on RLM only. The competitive cost of not having them grows.
• The pool of consultants and Salesforce account team members who know CPQ Classic shrinks. Specialized help gets harder to find.
• When Salesforce eventually does announce a hard end-of-life date, every CPQ Classic org will be migrating simultaneously. The supply of qualified migration consultants compresses, prices rise, timelines extend.

The orgs that migrate during the current window (Salesforce-supported, plenty of consultant supply, well-documented migration path) get the easiest experience. The orgs that wait do not.

What the decision looks like

A simple framework for the timing call:

SituationRecommendationHigh customization, near-term renewal cliff, needs RLM-only featureStart audit now, plan migration in next 12 monthsHigh customization, no urgent driverAudit now, defer migration 6 to 12 months for capacityLow customization, stable configMigration can start within 3 months, complete in 6Mid-project on other major initiativeDefer until that completes, audit thenMultiple distinct sales motions with different needsConsider dual-track, plan consolidation within 18 months

Sapota's Salesforce team works with orgs to produce the audit, the timing recommendation, and the migration delivery. The Revenue Cloud Consultant credential (passed May 2026) supports the engagement profile across migration, design, and post-migration optimization.

---

Deciding when to migrate from CPQ Classic to RLM? Sapota's Salesforce team handles the audit, timing analysis, and migration delivery on production engagements. Get in touch ->

See our full platform services for the stack we cover.