Thousands of enterprises still run SteelBrick CPQ (Configure, Price, Quote) or Salesforce Industries (formerly Vlocity) managed packages. As these platforms reach end-of-sale, Salesforce has moved many of the advanced capabilities from these applications (particularly Vlocity) onto “Core” in the form of Agentforce Revenue Management (formerly, and for the purposes of this document, called Revenue Cloud Advanced or RCA), where they can be accessed more broadly, across Industries and Cloud solutions. SteelBrick and Industries were different packages, and now RCA on Core is replacing both.
RCA is a stronger architectural foundation than the legacy stacks. The catch: how you migrate to RCA determines the ongoing ease of maintainability, configuration malleability, production performance, and ultimately when Return On Investment (ROI) is achieved. Simply lifting and shifting configuration from old to new preserves debt. Resetting architecture on RCA enables those capabilities to be implemented using best-practice design, clear boundaries, and a more maintainable operating model.
The Questions to Ask Now!
Before reading further, there are three direct questions that will help frame the discussion:
- Does your RCA adoption roadmap assume that configuration copied from SteelBrick or Industries will behave much the same way on RCA?
- When a vendor or Service Implementor (SI) proposes “migration tooling,” can they explain what they intelligently transform (catalog semantics, orchestration, rules, boundaries), not merely inventory, copy, and run?
- Have you identified the pain points in your current implementation, and can your “migration” program explain how the target RCA design resolves them rather than allowing them to persist within the new platform?
If these questions are uncomfortable, that is usually a signal to revisit the planning around your RCA project and re-scope honestly, not to commit to lift-and-shift while assuming known pain points can be fixed in a later phase. After go-live, fixing entangled catalog and process design is far costlier than addressing it in your migration plan. As history has shown, organizations are very good at budgeting for new deployments, but very bad at funding technical debt after go-live.
The journey is demanding, especially when known pain points must be resolved before adoption accelerates. RCA on Salesforce pays off when the program is a deliberate re-implementation with optimization, not when legacy configuration is carried forward with minimal change.
Lift-and-shift is not intelligent transformation
As we have just described, the most expensive potential misunderstanding right now is that “migration” tooling equals an optimized path to RCA. The tooling may still help lightly tidy simple aspects of configuration (for example, catching duplicate records or multiple exit paths in orchestration plans), but the important part is missing and that is intelligent transformation: remapping for how RCA works today, not re-hosting how legacy systems used to work. Let’s take a deeper look.
First, existing tooling analyzes the source (SteelBrick CPQ or Industries) configurations (pre-migration analysis), surfaces misconfigurations and best-practice violations, and provides an “idea” of how much customization exists in the environment by simply counting the number and size of customizations. This analysis is done in the context of the legacy application’s abilities and limits, not against RCA, which has different design and performance considerations. These products encourage “cleanup before migration”.
Next, these tools perform a bulk copy of data (lift-and-shift) into an RCA environment (an object to object copy) and then run some lightweight best-practice rules against the configuration in the context of the expected limits of RCA, many of which are still unknown or remain unpublished (Post-migration analysis). Then the real work begins which is typically running and re-testing until configurations seemingly start to work. Finally, live customer data is migrated onto the new platform.
*A Typical Un-optimized “Lift and Shift” Migration Process
What is missing throughout these processes is intelligent transformation: remapping semantics, rebuilding models, and re-expressing behavior so it works in an optimal way on RCA, not merely as it used to. Legacy processes and configurations have often been uncomfortably bent over time to circumvent limitations of the existing applications and environments; they need to be unpacked and re-examined to see what can be designed more optimally on RCA.
So the direct question to ask any vendor offering RCA migration tooling (or more broadly an RCA “migration” program) is:
What do you transform (not copy)?
What do you redesign for RCA (not re-host)?
What new RCA capabilities will you turn on that I can’t use on legacy CPQ today?
Let’s look at a few real examples to highlight some of the issues with lift-and-shift migration drawn from experience in assessing the possibility of creating migration tools for RCA.
Linear modelling. When legacy CPQ could not model reusable bundles, teams often created a separate SKU for every variant. Linear modelling on RCA addresses that pattern. This feature allows for reusable product components to be defined instead of a separate product for every bundle variant. Legacy CPQ and Vlocity often lacked (or only partially supported) this capability. Detecting the suboptimal pattern in legacy configuration and deploying an optimized model on RCA is a redesign problem, not something bulk copy or rules engines solve on their own.
Product classification. Another example of a feature used to optimally configure the catalog that is not consistently supported in these legacy applications is known as “Product Classification”. With this feature in RCA you can define a set of attributes within a product class. New products that are created use the product class to automatically inherit configuration (e.g. attributes). Think of mobile plans: every “Unlimited Plus” type of offer shares the same attributes (e.g. data tier, roaming, device payment rules), and each named plan inherits them from a plan class instead of re-entering them repeatedly. RCA classification works the same way. Migration models do not typically analyze existing legacy configurations to identify where this (and other types) of inheritance can be optimally configured and apply that configuration during lift-and-shift migration. A bulk copy leaves whatever shape the source had.
Other RCA capabilities. There are many other examples where optimizations could be intelligently applied during migration, such as taking advantage of RCA’s out-of-the-box support for long-running orders, supplemental orders (a sophisticated real-time re-rendering of orchestration plans as orders change), attribute-based pricing, and more.
When you challenge migration tooling proposals, demand specifics: mapping rules that respect target catalog semantics, key features to migrate to such as supplemental orders that can significantly decrease end-to-end solution complexity, new products such as BRE where rule definitions can be centralized, rather than a migration process that simply slides legacy configurations forward blindly.
Customization depth
Customization belongs in the same lift-and-shift conversation. Tools can often report at a very high level how much customization exists in the source org (by detecting custom classes and class sizes), but simply cannot tell you whether the functionality performed by this logic needs to be re-implemented or replaced with out-of-the-box capabilities in RCA. Either way, customization scale helps ballpark re-implementation effort and phasing, not migration feasibility. Lift-and-shift Apex from SteelBrick or Industries to RCA is also not a credible strategy. You are dealing with different APIs, different execution models, and different product logic.
The Spectrum of Re-implementation
Re-implementation is not a one-size-fits-all timeline. In our architectural practice, we find that organizations do not get to select their migration strategy based on budget preferences or timeline optimism. Rather, an honest audit of customization depth and catalog entanglement dictates one of three distinct pathways:
Path 1: Light Re-implementation: Reserved for simple, low-entanglement environments (most commonly standard SteelBrick instances) with clean catalogs, minimal custom scripting, and low system coupling
Path 2: Full Re-implementation with Reset: The default path for the “entangled majority”. For organizations with moderate-to-high complexity, extensive custom logic (like complex JavaScript QCPs or deep Vlocity OmniScripts), and a catalog where commercial and technical definitions have fused.
Path 3: Full Re-implementation with Staged Rollout: Applicable to large, high-complexity operations (typically Tier 1 telcos running Vlocity CME). Because a single cutover is highly risky, the transition must be sequenced by business unit, region, or product line, running legacy and target systems in parallel.
Architectural entanglement and the migration blind spot
Lift-and-shift not only carries the wrong configuration shape and custom code across to RCA, as we have seen, but also preserves entangled commercial and operational configuration and other best-practice violations that are critical for the long-term health, flexibility, and maintainability of the new solution.
A primary risk is lift-and-shift that preserves product models where commercial offers (what you sell) and operational fulfillment (how you deliver) were never cleanly separated. A powerful commercial decomposition layer is essential to achieve this by normalizing commercially named products into forms the back office and other systems understand. A failure to get this configuration correct means that changes to commercial products trigger follow-on changes deep within the back office, and vice versa. A telltale sign of improper separation of concerns is when changes to offerings (e.g. introduction of a new consumer offer) or technical product configurations (e.g. bulk modem upgrade) result in widespread data syncing between commercial and technical layers of the stack. The consequences of migrating such an entangled configuration to RCA mean that we are also migrating the existing pain points of the current solution. Introducing new products remains inherently complex and risky, because that still means changes across many areas of the stack.
Phased business case and ROI: what you cannot defer
Vendors often use phasing to make re-implementation costs look smaller than they are. That framing delays inevitable rework rather than eliminating it. The challenge is again that critical up-front optimizations, such as proper separation of concerns, mean a fundamental change to the underlying product model and to the layers of functionality and customization built on that model. That work can be costly, but it is critical to tackle first, not push off to an “optimization phase later.” Services companies tend to propose a phased approach to make near-term pricing more palatable to service providers. Phases can kick in after the underlying model is properly optimized, building on MVP layers cleanly as needed. This phasing can help de-risk the project but the vendor should provide insight into phasing upfront so the full timeline can be understood.
Key to implementing proper separation of concerns for complex industries such as communications and hi-tech is having strong decomposition and orchestration capabilities in the commercial layer. Too often, service providers view these exclusively as back-office functions.
Can AI Help with RCA Migration?
AI has the potential to reduce the mechanical lift in an RCA migration, but it only works if the agents are grounded in deep domain knowledge: RCA’s architecture, TM Forum standards, and your specific commercial model.
Much of that knowledge still lives with experienced practitioners, not in documentation AI can read on its own. The hard part is not running a migration job, but capturing enough expert judgment to train and steer the agents, and keeping humans in the loop to validate what “optimal on RCA” actually means for that business.
Key takeaways
We have seen that lift-and-shift migration tools risk not only copying unoptimized product configurations across to RCA, but also an entangled model lacking proper separation of concerns, the blind spot that is often overlooked during migration assessments. RCA ROI requires re-implementation with architectural reset and honest sizing of customization, not migration in name only.
Here are some key considerations to discuss with any vendor pushing a migration vs re-implementation story:
- Challenge migration tooling. Ask what vendors transform (not copy), redesign for RCA (not re-host), and turn on that legacy CPQ could not.
- Size the program for re-implementation; customization depth informs effort, not migration readiness.
- Reset commercial vs operational boundaries: commercial product truth in the front office, technical fulfillment truth in the back office, with clean handoffs between them.
- Phase work so advanced RCA capabilities ship with the reset, not relegated to a deferred “optimization” phase.
If this resonates,reach out to Ateko to continue the conversation on RCA assessments, program reframing, and re-implementation planning.
