Horus Eye · Revenue Cloud Migration
Your CPQ migration effort is a coupling question
Salesforce has named Revenue Cloud as CPQ’s successor, and every SBQQ org now faces the same estimate. The honest version isn’t a feature comparison — it is a count: how much of your custom code, automation, reporting and integration reaches into the SBQQ namespace, and how much of that wiring is load-bearing. See the dependencies before you migrate CPQ — Horus Eye produces that count with the components named.
Salesforce CPQ end of life? What end of sale actually means
The clock, honestlyThe Salesforce CPQ end of sale date was March 27, 2025: no new CPQ licenses, no new features, no future roadmap. That is not end of life — Salesforce has announced no EOL date, existing customers can still renew and open support tickets, and nothing forces an immediate move. But every SBQQ org is now on a clock without a face: the successor is Revenue Cloud, the talent pool follows the roadmap, and the question has shifted from whether to migrate to when, and at what cost. The cost question is answerable today — it is a Salesforce CPQ migration coupling question, and that is what this assessment measures.
What exists today — and what is planned
Truth firstWhat Horus Eye measures now: the package-namespace coupling rule fires one finding per tracked ecosystem — CPQ’s SBQQ among them — once at least 5 distinct custom components carry dependency edges into it, naming the coupled components in evidence. Deep Read of a package draws the coupling and modernization-map diagrams; the Dependency Explorer’s cross-package view walks the edges. The rule is deliberately a migration-cost observation, severity medium: nothing is broken today, and the scan cannot see which couplings are load-bearing versus incidental — that classification belongs to the owning team.
Path-specific readiness scoring — a computed CPQ→Revenue Cloud readiness measure — is planned, not shipped. Horus Eye is extending toward it; this page will say so until it exists.
Significant custom dependencies outside the SBQQ namespace
- What Horus Eye detected
- A representative org where 182 custom components — Apex, flows, fields, reports and integration metadata — carry dependency edges into the SBQQ managed-package namespace.
- Evidence
- Distinct non-namespaced components with at least one edge into SBQQ components, counted from the dependency records and named in a bounded sample.
- Why it matters
- Each coupling is wiring a Revenue Cloud migration must unwind, rework, or consciously keep. The count is the first honest input to the migration estimate — and to the decision of when.
- Recommendation
- Classify each coupling with the owning team — load-bearing, incidental, obsolete. Remove the obsolete now (it shrinks the estimate before any decision), and let the load-bearing count size the real program.
- Confidence
- Moderate — dependency edges observed; load-bearing vs incidental not classified by the scan
From evidence to a migration you can schedule
The clearing
The clearing here is preparatory and human-led, and this page says so: prune the obsolete couplings (some retirements are executable and reversible), rewire the incidental ones, and take the load-bearing count to Kemisoft’s Revenue Cloud practice — which scopes the migration from this evidence instead of a discovery workshop that rebuilds it by hand. The same lens answers the sequencing question boards are asking now: whether to migrate before Agentforce Revenue Management, and what the coupling says about either order.
Frequently asked questions
Straight answersHow do I estimate a CPQ to Revenue Cloud migration?
Count the coupling, classify it, and let the load-bearing share size the program. Feature mapping comes second; wiring is where the effort lives.
What breaks when SBQQ is removed?
Whatever references it — and the dependency evidence names those components before anyone commits. “At least this list” is the honest floor; reports and API consumers need their own check.
Is Salesforce CPQ end of life?
No. End of sale (March 27, 2025) means no new licenses and no roadmap; end of life has not been announced. Existing customers keep renewing and receiving support. The practical consequence is directional, not immediate: investment has moved to Revenue Cloud, so migration planning is a when-and-how-much question.
How long do we have on Salesforce CPQ?
Salesforce has announced no end-of-life date. Planning horizon is a business judgment — but the migration’s size is measurable now, and orgs that measure early get to shrink the coupling before any deadline pressure exists.
Should we migrate before Agentforce Revenue Management?
The coupling evidence informs the order either way: heavy load-bearing coupling argues for untangling first; light coupling makes the successor conversation cheaper. It is a sequencing decision the business owns — with numbers, now.
Protected AI — the Trust Layer
Every AI read in Horus Eye is metadata-first: built from an allowlist, sanitized by pattern, made through one audited gateway and checked by an output firewall on the way back — and AI is off by default, per org. Every request carries an audit id and an AI Data Scope manifest you can open.
Size the migration before anyone promises a date
One scan counts and names the SBQQ coupling in your org — the estimate’s first honest input.
Try Horus Eye Assess Your Revenue Cloud Migration All Horus Eye pages