Migrating Product Configuration Logic from LO-VC to SAP CPQ

For many manufacturers and industrial B2B companies, the question of how to handle a LO-VC to SAP CPQ transition is one of the most consequential decisions in a broader SAP modernization program. LO-VC — SAP’s Logistics Variant Configuration module — has been the backbone of product configuration for decades. It lives deep inside ERP, governs Bills of Materials, drives production planning, and enforces the logic that determines which product combinations are valid. Moving that logic, or even extending it into a quoting environment like SAP CPQ, is not a straightforward lift-and-shift. It requires careful analysis, clear governance decisions, and an honest view of what you are actually trying to achieve.

This article walks through the key considerations for any organization planning a product configuration migration into SAP CPQ — covering the strategic options available, the practical risks involved, and the governance questions that need answers before a single rule is touched.

Understanding What You Are Actually Moving

Before any migration planning begins, it is worth being precise about what LO-VC actually contains. LO-VC, AVC, and SAP CPQ each serve different purposes within the SAP landscape, and conflating them is one of the most common sources of confusion in these projects. LO-VC is primarily an ERP-side configuration engine. It manages configurable materials using characteristics, dependency rules, variant conditions, and BOMs. Its purpose is to ensure that a valid, manufacturable product is captured in a sales order and passed downstream to production and procurement.

SAP CPQ, by contrast, is a sales-side tool. Its job is to guide a salesperson or customer through a product selection and pricing process, produce an accurate quote, and eventually convert that into a sales order. The two systems are solving different problems, even when the underlying product logic overlaps. This distinction matters enormously when you start asking which rules need to move, which rules need to stay, and which rules need to exist in both places simultaneously.

The Three Layers of LO-VC Logic

When auditing an LO-VC model for migration purposes, it helps to think in three layers:

• Characteristic definitions — the features and options that describe a configurable product, such as material type, dimensions, or output specifications
• Dependency rules and constraints — the logic that determines which combinations of characteristics are valid, including preconditions, selection conditions, and procedures
• Variant pricing conditions — the pricing surcharges and adjustments tied to specific characteristic values, which interact with the SD pricing procedure

Each of these layers behaves differently in SAP CPQ, and each carries its own migration risk. Characteristic definitions are relatively straightforward to replicate or synchronize. Dependency rules are where complexity and risk accumulate. Variant pricing conditions require careful alignment with how SAP CPQ handles pricing automation and condition logic on the quoting side.

Integration vs. Full Migration: Choosing the Right Path

One of the most important strategic decisions in any SAP CPQ migration project is whether to integrate with LO-VC or to fully migrate the configuration logic into CPQ’s own engine. These are not the same thing, and the right answer depends heavily on your deployment scenario, your S/4HANA roadmap, and the complexity of your existing product models.

The Integration Approach

SAP CPQ integrates natively with Variant Configurator via SAP CPS, meaning the mapping and consumption logic for SAP CPS pricing and configuration services — which in turn consume AVC and LO-VC pricing and configuration rules — is already pre-built. This means that in many cases, the configuration and pricing services can be used to bypass SAP CPQ’s own engines, allowing configuration and pricing models created in SAP ERP or SAP S/4HANA to be used in SAP CPQ instead of re-modelling them again. For organizations with mature, well-maintained LO-VC models, this integration path is often the lower-risk option. It preserves the existing business logic, avoids duplication, and keeps the ERP as the system of record for product validity.

SAP CPQ supports a hybrid integration scenario with VC, allowing you to consume what has been built on the pricing and configuration side of VC while also redefining some price conditions and changing the layout on the SAP CPQ side. This hybrid model is particularly useful when a company wants to improve the quoting experience without dismantling years of carefully built ERP configuration logic. It is also worth noting that both SAP configuration engines are supported by CPQ: LO-VC, still available in S/4HANA Private Cloud, and AVC, which is the sole solution in the newest S/4HANA Public Cloud.

When Full Migration Makes Sense

There are scenarios where a full migration of product configuration logic into SAP CPQ’s native engine is the better path. This is typically the case when:

• The existing LO-VC models are outdated, poorly documented, or no longer reflect actual product offerings
• The organization is moving to S/4HANA Public Cloud, where LO-VC is no longer supported
• The product catalog is being restructured as part of a broader commercial transformation
• The quoting process requires sales-specific logic that does not belong in the ERP at all
• The organization wants to decouple the quoting experience from ERP constraints to support faster product changes

In these cases, the migration becomes less about translating LO-VC rules and more about redesigning the product model for a sales context. This is a fundamentally different kind of project, and it requires product management, sales operations, and IT to work together from the start. Organizations evaluating this path should also consider the relationship between CPQ and S/4HANA go-live timing, since the sequencing of these decisions has real consequences for project scope and risk.

The Practical Risks of Product Configuration Migration

Regardless of which path is chosen, product configuration migration carries risks that are easy to underestimate. The most dangerous of these is silent logic breakage — situations where rules appear to work correctly in testing but produce invalid or incomplete configurations in production, often in edge cases that were not covered during validation.

IF statements in rules have different semantics in AVC than in LO-VC, meaning you cannot simply migrate a KMAT and be guaranteed it will work as before. Actions are no longer supported. Preconditions behave differently. These differences become even more pronounced when configuration logic is moved into SAP CPQ’s own engine, which operates on a completely different rule paradigm. Every rule that touches product validity must be tested end-to-end, not just verified for syntactic correctness.

Other practical risks include:

• Undocumented dependencies — LO-VC models built over many years often contain logic that no one fully understands, written by consultants or engineers who have since left the organization
• Pricing misalignment — variant pricing conditions in LO-VC interact with SD pricing procedures in ways that may not translate cleanly into CPQ’s pricing engine without careful mapping
• Data synchronization gaps — material master data, characteristic values, and BOM structures need to remain consistent between systems during and after migration
• Quote engine compatibility — the Variant Configuration integration is supported on both SAP CPQ quote engines, but adding nested Variant Configuration products as bundles is supported only on Quote 2.0
• Known functional limitations — promotions are not supported in scenarios with back-end Variant Configuration materials, and quotes with configured materials containing characteristics with the type Date cannot be synchronized with a back-end system

For companies dealing with data quality challenges in SAP CPQ, migration adds another layer of complexity. Garbage in, garbage out applies just as much to product configuration rules as it does to pricing data.

Governance and Business Logic Ownership

One of the most overlooked aspects of an LO-VC to SAP CPQ migration is the question of governance — specifically, who owns the product configuration logic after the migration is complete, and where the authoritative version of that logic lives. This is not a technical question. It is an organizational one.

In a pure LO-VC environment, the configuration model lives in the ERP and is typically owned by a combination of product engineering, master data management, and IT. When configuration logic is extended or replicated into SAP CPQ, a new set of stakeholders enters the picture: sales operations, commercial teams, and CPQ administrators. Without clear ownership boundaries, you end up with two versions of the truth — and eventually, they diverge. Staying within the SAP ecosystem helps reduce this risk, since data and logic flows can be governed through native SAP integration patterns rather than custom middleware.

Key Governance Questions to Resolve Before Migration

Any organization planning a product configuration migration should be able to answer the following before the project begins:

• Which system will be the system of record for product validity rules — ERP or CPQ?
• How will changes to product characteristics be propagated across systems, and who approves them?
• What is the process for retiring obsolete configuration rules, and how will that be managed in both environments?
• Who has the authority to modify CPQ-side product logic, and what controls exist to prevent unauthorized changes?
• How will the organization test configuration changes before they reach production?

These governance structures need to be in place before go-live, not after. The internal team understanding of CPQ pricing logic is equally important here — the people responsible for maintaining CPQ rules post-migration need to understand both the sales context and the ERP dependencies that underpin those rules.

Preparing for a Successful SAP CPQ Migration

A well-prepared migration starts with a thorough audit of the existing LO-VC landscape. This means documenting every configurable material, mapping all active dependency rules, identifying which rules are actually in use versus which are legacy artifacts, and understanding the pricing condition structures that will need to be replicated or replaced. Many organizations discover during this audit that their LO-VC models are significantly more complex — or more fragile — than they assumed.

The next step is defining a clear scope boundary. Not everything in LO-VC needs to move into CPQ. Some logic belongs in the ERP and should stay there. Other logic — particularly the guided selling rules, option filtering, and commercial pricing adjustments that sales teams need — belongs in CPQ. A structured CPQ discovery workshop is one of the most effective ways to draw this boundary clearly, involving the right stakeholders from both the business and IT sides.

Testing is the final and most critical preparation step. A robust test plan for a product configuration migration should include:

• Unit testing of individual rules and constraints in the target environment
• Integration testing of the full configuration-to-quote-to-order flow
• Regression testing against a library of known-valid configurations from the current system
• Edge case testing for the most complex and unusual product combinations
• User acceptance testing with actual sales team members who know the products

For manufacturers and industrial companies where product complexity is a core business challenge, the migration itself is also an opportunity. It is a chance to simplify product models that have grown unwieldy, retire rules that no longer reflect the product range, and build a CPQ environment that actually supports the way sales teams work today. For companies in sectors like manufacturing or automotive, where configurable products are central to the business model, getting this migration right is not just a technical milestone — it is a strategic one.

The organizations that succeed with LO-VC to SAP CPQ migrations are the ones that treat it as a business transformation project first and a technical migration second. They invest in discovery, they establish governance early, they test thoroughly, and they bring the right expertise to bear on the complexity that inevitably surfaces. Working with a partner who understands both the ERP configuration layer and the CPQ quoting environment is not a luxury in these projects — it is a prerequisite for avoiding the kind of logic breakage that can quietly undermine quoting accuracy long after go-live. Explore how Solvetect’s SAP CPQ services can support your migration planning and execution from discovery through deployment.