TL;DR
- Salesforce CPQ is end-of-sale, and ARM is a totally different architecture, which is why lift-and-shift migrations stall, oh, roughly three months in.
- The hardest part? Your real quoting logic is undocumented and the methodology you paid a consultant for never makes it into the work.
- Sweep's CPQ to ARM Playbook runs the whole project inside the Agentic Layer: Discovery surfaces what exists, Design produces target-state, Implementation hands a build-ready change list to Sweep's Build environment.
*****
Navigating Salesforce CPQ End of Life
Salesforce CPQ has been in End of Sale for over a year now. No new licenses, no new features, a support runway that gets shorter every quarter. If your revenue process runs on CPQ, you already know the migration question stopped being if a while ago. It's when, and it's how.
Most teams brace for the wrong fight. They scope the migration as a mere rebuild — move the products, recreate the price rules, replicate the approval flows, get to parity, dust your hands, call it done.
Then three months in, the project stalls, and it's never because the rebuild was hard. It's because nobody could find what they were rebuilding.
Here's what actually goes wrong…
The CPQ pain you can see
The clock is a cost, not a deadline. End of Sale doesn't force you off CPQ tomorrow. It’s just that it makes waiting expensive. Every quarter, your CPQ logic drifts further out of alignment with where Salesforce is investing, and the migration you defer gets bigger, not smaller. The deadline is soft. The compounding of dollars is firm.
ARM is not CPQ with a new coat of paint. This is the assumption that kills lift-and-shift: CPQ was built to evaluate commercial intent at quote time — pricing rules, discount schedules, and lookup tables all fire during quote calculation, and once the quote converts, that logic effectively retires. Agentforce Revenue Management works totally differently. It runs on a metadata-driven product catalog instead of brittle bundles, and it enforces revenue behavior across the whole lifecycle: contracts, amendments, renewals, billing events. That's not a feature gap you can patch. It's a different place for your revenue logic to live. Teams that plan a relocation discover the structure they wanted to relocate doesn't exist on the other side.
The CPQ pain you can't see
And this is the part that doesn't show up in any project plan:
The gap between what's in your config and what's documented is likely enormous. Most mature CPQ environments have quoting logic that lives in the head of the admin who built it three years ago, not in a spec doc. That undocumented logic has to be found, mapped, and consciously rebuilt — or deliberately left behind. You can't migrate a thing you can't see, and most orgs can't see most of it.
The arc is fragmented across four or five tools and roles. A consulting partner writes the methodology in the middle of a slide deck. An admin runs ad-hoc AI prompts to investigate the org one question at a time. A project manager tracks status in Jira. A developer eventually builds the changes by hand. LIke a game of Telephone, each handoff mistranslates and/or loses context.
And the methodology — the part you're actually paying for — never makes it into the work. It sits in a PDF. The migration happens somewhere else, in spreadsheets and one-off prompts, and the expensive expert framework you bought becomes a reference doc nobody opens after kickoff. You paid for execution and got a deliverable.
That's the protean form of a CPQ migration. The rebuild is the easy part. The excavation, the handoffs, and the methodology that evaporates between slide deck and org… that's where the months get buried.
Sweep’s Playbook collapses your CPQ to ARM migration
Sweep has created Playbooks to its Agentic Layer, and the CPQ to ARM Playbook is built for exactly this kind of multi-week project.
A Playbook is a workspace for one project. It has stages; it has proven, expert-quality prompts the agent runs against your live org; and it has persistent artifacts (reports, inventories, design specs, change lists) that get saved for the life of the project.
Here's how the CPQ migration runs:
Discovery surfaces what actually exists. The agent scans your live org — not a slide-deck version of it — and inventories the existing CPQ configuration: product rules, approval flows, discount logic, pricing structures, and the dependencies tying them together. The undocumented logic that used to take weeks of discovery workshops and admin interviews gets mapped automatically. The excavation stops being manual, dead in its tracks.
Design produces the target state. With Discovery's output as its input, the agent designs what the configuration should become in ARM — a target-state design and a migration plan that accounts for the architectural shift, not a one-to-one copy of constraints you were trying to escape. The lift-and-shift trap gets avoided because the agent is designing for where ARM puts revenue logic, not pretending CPQ's model still applies.
Implementation produces build-ready output. Design's output becomes Implementation's input. The agent surfaces the changes the project produced and stages them for build — and that change list hands off natively to Sweep's Build environment. The arc that used to die at the developer's desk closes inside the same workflow.
The CPQ to ARM Playbook ships with Sweep's expert methodology baked in as best-practice files the agent reads on every prompt. So the work follows a real migration methodology out of the box. And if you have your own standards (many bring a consulting firm's framework, internal naming conventions, governance patterns) you just attach those files too, and the agent's work follows your standards on top of our baseline.
For your CPQ sunset, the difference is execution
There's a long history of tools that help with a CPQ migration. Documentation tools that map the org. Consultants who bring the framework. AI that answers one prompt at a time. Each of them owns a slice of the arc, and the gaps between the slices are where migrations go to die.
A Playbook owns the whole arc. It takes a methodology, runs it as a sequenced workflow against your live org, and ends with build-ready output. The agent doesn't describe what should happen. It does the work.
Your CPQ migration was always going to be an excavation before it was a rebuild. The question is whether you're doing it by hand, across five tools, with the methodology stuck in a PDF — or running it end to end, with one agent that can actually see your org.
Book a demo to see the CPQ to ARM Playbook run against a real org.
