Phased CPQ migration: running old and new side by side
A phased CPQ migration keeps Salesforce CPQ live for existing business while the new CPQ takes new quotes for one segment at a time — a product line, a region, or a team. Because Salesforce CPQ is end of sale but still supported and renewable, you can keep it licensed as long as the overlap needs. The trick is to move the install base once, not in slices.
When to phase, and when not to
| Phase it when… | Cut over in one step when… |
|---|---|
| Several business units quote independently and can adopt separately. | One sales team uses one catalog and one template. |
| Renewal volume is high and continuous, so there is never a quiet window. | Renewals cluster at a fiscal year-end and give you a natural window. |
| Integrations (ERP, billing) can accept orders from two sources for a while. | Downstream systems assume a single quote source. |
| You are moving to a new data model (Revenue Cloud Advanced) and need time to redesign the catalog. | You are moving to a native alternative that reuses standard Products and Price Books; the whole move fits in 4–8 weeks. |
Salesforce’s own guidance supports either: it says there is no forced migration and existing customers can renew and add users, so the overlap period costs only license fees (Salesforce).
The four phases
- Foundation: catalog and pricing
Load products, price books, bundles, and negotiated prices into the new CPQ for the whole company, not just the first segment. Validate totals against SBQQ for a sample of closed quotes.
- Pilot: one segment, new quotes only
Pick the segment with the simplest catalog and the most patient manager. New opportunities quote in the new CPQ; renewals and amendments stay in SBQQ. Run one full quote-to-order cycle.
- Install base: move it all at once
Migrate every active subscription and contract in one pass, on a date, with a freeze on amendments. Slicing the install base creates renewals that half-exist in each system.
- Expansion and retirement
Bring remaining segments over in order of complexity. Keep SBQQ read-only for historical quotes until reporting no longer needs it, then uninstall.
Coexistence details
- Two managed packages, one org. A native alternative installs alongside SBQQ; the namespaces do not collide. The same Product2 and Price Book records serve both.
- One opportunity, one quote system. Decide by record type or business unit which CPQ owns an opportunity. Do not let both create quotes on the same one.
- Reporting. Build a temporary combined pipeline report early; the month you have quotes in two systems is the month finance asks for a single number.
- Renewals in flight. Any renewal opportunity already generated by SBQQ closes in SBQQ. New renewal opportunities generate in the new system after the install-base move.
- Licenses. Keep enough SBQQ licenses for the users still quoting there; Salesforce lets existing customers add users and renew (source).
How long a phased move takes
To a native alternative, the foundation and pilot together typically fit inside Kugamon’s 4–8 week window; expansion adds a week or two per segment. To Revenue Cloud Advanced, the 12–18 month rebuild in practice applies to the whole program, and phasing usually lengthens it because the catalog redesign has to be complete before the pilot (what the RCA move involves). Sequence everything with the checklist.
Yes. Both are managed packages with distinct namespaces and can share the same standard Product and Price Book records. Assign each opportunity to one CPQ by record type or business unit so both never quote the same deal. See the Salesforce CPQ playbook.
No. Move every active subscription and contract in one pass with a short amendment freeze. Splitting the install base creates renewals that are partly in each system. Object detail: data migration.
Yes, for the users still quoting in it. Salesforce says existing customers can renew and add users under their contracts (source), so the overlap is a license cost, not a contractual problem.
Usually, by the length of the overlap. To a native alternative the difference is a few weeks. To Revenue Cloud Advanced, phasing tends to extend the 12–18 month rebuild in practice (source) because the catalog redesign must finish before the pilot.
See your migration plan
Published timelines by source platform, a fixed implementation fee, and a calculator that labels every estimate.