Skip to content

The Guide to the Salesforce CPQ Sunset and Revenue Cloud Migration

The legacy Salesforce CPQ end of sale in 2025 marks a critical turning point for businesses. This guide explores the architectural shift to Salesforce Revenue Cloud and outlines a definitive roadmap to migrate your quote-to-cash logic successfully.

Raaj Raaj · · 6 min read
The Guide to the Salesforce CPQ Sunset and Revenue Cloud Migration

For years, Salesforce CPQ (formerly known as SteelBrick) has been the unquestioned backbone of quote-to-cash operations for thousands of enterprise organizations. It revolutionized how sales teams handled complex pricing, sophisticated product bundling, and automated contract generation. However, the enterprise software landscape is shifting rapidly, and what once represented the cutting edge of sales automation is now being strategically retired to make way for a more unified, highly scalable, and native architecture.

The official announcement of the Salesforce CPQ sunset has sent ripples through Revenue Operations (RevOps), IT, and finance departments worldwide. Specifically, the legacy Salesforce CPQ end of sale 2025 marks a critical turning point for businesses. As of March 2025, no new licenses for the legacy managed package are being sold to net-new customers. Instead, Salesforce is aggressively directing all future innovation, research and development investment, and customer onboarding toward its modern successor: Salesforce Revenue Cloud.

For businesses currently relying on legacy CPQ, this is not merely an impending software update; it is an urgent mandate to evaluate and modernize your entire revenue architecture. Preparing for a comprehensive Revenue Cloud migration requires a strategic understanding of the timeline, the fundamental architectural differences between the two platforms, and the cascading impact this will have on connected enterprise systems, such as your ERP and billing engines.

This master guide will break down the true urgency of the CPQ end of sale, explore the new platform's expansive capabilities, and provide a definitive CPQ replacement roadmap to help your organization successfully migrate from Salesforce CPQ to Revenue Cloud without disrupting your daily revenue flow.

1. The Reality of the Legacy Salesforce CPQ End of Sale 2025

To navigate this transition effectively, organizations must first understand the difference between "End of Sale" (EOS) and "End of Life" (EOL).

The legacy Salesforce CPQ end of sale 2025 simply means the product is no longer commercially available to new buyers. It does not mean the software will suddenly stop working tomorrow. Existing customers are currently permitted to renew their contracts, add seats, and continue utilizing their customized setups. Standard support and critical security patches will be maintained in the near term.

However, the Salesforce CPQ sunset effectively freezes the platform in time. All meaningful product innovation has ceased. Modern demands—such as native usage-based billing, AI-driven dynamic pricing, and seamless multi-channel composability—will not be retrofitted into the legacy managed package. While a hard End of Life (EOL) cutoff isn't widely anticipated until the 2029–2030 timeframe, the "cost of doing nothing" is already compounding. Businesses that choose to stay on the legacy system will accumulate severe technical debt, experience slower customer support resolution times, and inevitably fall behind competitors who are leveraging modern, AI-augmented quoting systems.

2. Exploring the CPQ Replacement: Enter Salesforce Revenue Cloud

As the definitive CPQ replacement, Salesforce Revenue Cloud is positioned not just as a quoting tool, but as an end-to-end Revenue Lifecycle Management (RLM) platform.

The most critical distinction to grasp is that Revenue Cloud is built directly on the core Salesforce platform (Core CRM). Unlike legacy SteelBrick, which operated as a "managed package" sitting on top of the CRM with its own custom objects and unique data models, Revenue Cloud utilizes an API-first, metadata-driven architecture.

This natively integrated approach shatters the traditional silos between sales, legal, and finance. It allows for high-performance pricing engines, seamless integration with Agentforce (Salesforce’s AI agents), and a highly composable product catalog that can easily serve direct sales, partner portals, and self-service e-commerce channels simultaneously.

3. Revenue Cloud vs Salesforce CPQ Feature Comparison

To truly understand why a CPQ migration is necessary, we must look at how the features fundamentally differ. Below is a high-level Revenue Cloud vs Salesforce CPQ feature comparison highlighting the evolutionary leap between the two systems.

Capability Area Legacy Salesforce CPQ Salesforce Revenue Cloud (RLM)
Foundation & Architecture Managed Package (Custom Objects) Native Core Platform (Standard Objects)
Product Bundling Heavy, SKU-intensive product rules Attribute-based Product Catalog Management (PCM)
Pricing Engine Price Rules, QCP (Custom JavaScript) Business Rules Engine (Declarative, Flow-based)
Approvals Advanced Approvals (Separate add-on) Native Flow Orchestration
Billing & Subscriptions Disconnected; requires heavy integration Native support for usage/consumption-based billing
API & Headless Selling Highly constrained API-first, composable architecture for omnichannel

When analyzing Revenue Cloud Advanced vs legacy CPQ, it becomes immediately clear that the new platform is designed for agility. Instead of creating hundreds of separate SKUs for a product that comes in different sizes and colors, Revenue Cloud utilizes dynamic attributes, drastically simplifying catalog maintenance.

4. Revenue Cloud Advanced vs Legacy CPQ: Why It’s a Rebuild, Not an Upgrade

One of the most dangerous misconceptions circulating among RevOps teams is that the move to the new system will be a standard software upgrade.

Because of the architectural disparities outlined above, you cannot simply press a button to migrate from Salesforce CPQ to Revenue Cloud. It is a fundamental reimplementation of your quote-to-cash logic.

Your existing custom Apex triggers, complex JavaScript pricing calculators (QCP), and legacy Price Rules will not smoothly translate into Revenue Cloud's modern Business Rules Engine. Your data model must be meticulously remapped—for example, transitioning legacy Quote Lines into new Transaction Line Items. This reality makes the Revenue Cloud migration an ideal opportunity to clean house. Before moving, organizations should ruthlessly audit their product catalogs, retire "zombie" SKUs, and eliminate convoluted pricing workarounds that were only built to bypass the limitations of the old system.

Post 1: "The Technical Blueprint: Data Mapping and Architecture for Your Revenue Cloud Migration"

5. Ecosystem Impact: Rebuilding ERP Integrations and Microsoft Dynamics 365

Your CPQ system does not exist in a vacuum; it is the critical bridge between your CRM's front-office sales data and your ERP's back-office financial ledgers. Because the underlying data model is completely changing in Salesforce Revenue Cloud, your existing downstream integrations will inevitably break and must be re-architected.

For enterprise organizations utilizing Microsoft Dynamics 365 as their financial backend, this integration rebuild requires careful planning. You must ensure that the new Transaction Line Items generated by Revenue Cloud accurately map to your Dynamics 365 finance and operations modules to preserve accurate ledgers, revenue recognition, and supply chain fulfillment.

When planning your CPQ migration, IT leadership must consult official integration frameworks to ensure data consistency between Salesforce and Microsoft ecosystems. Microsoft provides extensive, officially documented patterns for these exact cross-system enterprise scenarios.

  • For high-level architectural guidance on integrating external applications with Dynamics 365, review the Microsoft Dynamics 365 Integration Guidance.
  • Additionally, organizations often leverage robust middleware or third-party logic engines to bridge complex pricing data between these two giants. You can explore standard connector documentation to understand how modern APIs facilitate secure, real-time data handoffs.

Treating your ERP integration as an afterthought is the fastest way to derail a CPQ implementation. Engage your enterprise architects early to map the flow of master data between Salesforce and Microsoft Dynamics 365.

6. The Path Forward: Structuring Your Migration

Recognizing the monumental scope of a Revenue Cloud migration, executive leadership must prioritize business continuity. A "big bang" rollout—where you shut down legacy CPQ on Friday and turn on Revenue Cloud on Monday—is highly discouraged for complex enterprises.

Instead, the most successful transition strategies rely on a phased, parallel-run approach. Organizations should establish a timeline where net-new product lines, or entirely new geographic sales regions, are onboarded directly into Revenue Cloud. Meanwhile, existing, inflight contracts remain securely housed within legacy CPQ until they reach their natural renewal cycle, at which point they are migrated to the new architecture.

Post 2: "Business Strategy: Timelines, TCO, and Alternatives to Revenue Cloud"

Frequently Asked Questions

What is the difference between Salesforce CPQ and Revenue Cloud?
The primary difference lies in their underlying architecture and scope. Salesforce CPQ is a legacy managed package (originally SteelBrick) that sits on top of Salesforce and relies on custom objects and heavy, rules-based configuration. Revenue Cloud is built natively on the core Salesforce platform using an API-first, metadata-driven architecture. Furthermore, Revenue Cloud extends far beyond standard quoting; it is a comprehensive Revenue Lifecycle Management (RLM) suite that natively handles advanced subscription management, usage-based consumption billing, and AI-driven pricing strategies.
What does “end of sale” for legacy CPQ mean for our product roadmap and customers?
The "end of sale" designation means that Salesforce is no longer selling new licenses of the legacy CPQ product to new customers. For your internal product roadmap, it signifies that the foundation of your quote-to-cash process is now effectively frozen. Salesforce will not add modern features, AI enhancements, or new billing models to the legacy package. To offer your own customers flexible, modern purchasing experiences (like self-service portals or consumption-based pricing), you will eventually be forced to transition to a modern platform.
Can I keep using legacy CPQ after end of sale?
Yes, you can absolutely continue using legacy CPQ after the end of sale. Your current system will not shut down, and your sales team can continue generating quotes as they do today. However, doing so means accepting a steadily increasing burden of technical debt. Over time, as your business requirements evolve and outgrow the legacy package’s frozen capabilities, you will be forced to rely on expensive, manual workarounds and custom code to keep your revenue operations functioning.
Will existing CPQ licenses still be supported after the end of sale?
Yes, existing CPQ licenses will continue to be fully supported in the immediate future. Existing customers can renew their current contracts, add new user licenses to their existing orgs, and access standard technical support for bug fixes and critical security patches. However, industry analysts predict that as the ecosystem shifts toward Revenue Cloud, the pool of support resources and third-party consulting expertise dedicated to legacy CPQ will rapidly shrink.
How will Salesforce roadmap and feature investment change after CPQ sunset?
Following the CPQ sunset, 100% of Salesforce’s quote-to-cash research and development investment is being channeled directly into Revenue Cloud (RLM) and Agentforce integrations. The roadmap for legacy CPQ is essentially zeroed out, meaning no new features will be introduced. All future enhancements regarding generative AI for contract drafting, dynamic margin optimization, omnichannel catalog management, and seamless ERP billing integrations will exclusively be available to Revenue Cloud customers.
What teams should own CPQ migration?
The migration should be co-owned by Revenue Operations (RevOps) and Enterprise IT. RevOps owns the business logic, pricing strategy, and change management, while IT owns the technical execution, data security, and ERP integration architecture.
When should we consider switching to a third-party CPQ instead of migrating?
Consider a third-party CPQ if your business does not require the massive scale of Revenue Cloud, if you want to avoid a 12-month heavy development cycle, if you operate a multi-CRM environment, or if you need a solution with more predictable, lower out-of-the-box licensing costs.
What are the competitive alternatives to Salesforce Revenue Cloud?
Top alternatives include Conga (excellent for enterprise scale and complex manufacturing), DealHub (ideal for agile RevOps and rapid deployment), PandaDoc (great for document-heavy quoting), and Subskribe (optimized for modern SaaS and subscription billing).

More from our Blog

The Business Strategy for Revenue Cloud: Timelines, TCO, and CPQ Alternatives
Salesforce

The Business Strategy for Revenue Cloud: Timelines, TCO, and CPQ Alternatives

Facing the retirement of legacy Salesforce CPQ? This strategic guide breaks down the true Total Cost of Ownership (TCO), realistic migration timelines, and deployment strategies for moving to Revenue Cloud. Discover whether a complete architectural rebuild or pivoting to third-party CPQ alternatives is the safest financial move for your enterprise.

Raaj Raaj · · 4 min read
The Technical Blueprint: Data Mapping and Architecture for Your Revenue Cloud Migration
Salesforce

The Technical Blueprint: Data Mapping and Architecture for Your Revenue Cloud Migration

Transitioning from legacy Salesforce CPQ to Revenue Cloud requires a fundamental architectural shift toward an API-first, core-native setup. This technical blueprint guides engineering teams through mapping legacy data, adopting Product Catalog Management (PCM), and refactoring custom QCP scripts into the declarative Business Rules Engine (BRE).

Raaj Raaj · · 6 min read