Navigating the Challenges of Converting SAP VC/AVC to Tacton CPQ

What if your CPQ model simply didn’t match your ERP data - and you didn’t even know?

When you’re migrating from SAP Advanced Variant Configuration (or the older LO‑VC) into Tacton CPQ, the challenge isn’t just “move the data.” It’s reconciling two very different configurator philosophies. In this first installment of our series, we’ll explain why model conversion often stumbles and set the stage for how you can avoid the common pitfalls.

SAP’s variant configuration tools (VC / AVC) exist primarily to support manufacturing: ensure correct BoMs, validate feasibility, feed production, manage costing. By contrast, Tacton CPQ is built for sales and customer interaction: configure-to-quote, ensure order correctness, guide the user, integrate pricing, produce documents. Because the focus differs, the modelling assumptions differ too. Trying to transplant an SAP model into Tacton CPQ one-to-one will often break: rules that make sense in the ERP world may hamper performance, or may not reflect the sales-centric logic you need.

Here are some common traps:

• Different structure and terminology. What SAP calls a “variant table” may need to become a “combination class” in Tacton.
• Hidden complexity in constraints. SAP engineers may have used preconditions, SELECTED() clauses, hidden defaults - so simply translating them may introduce logic that slows down or misbehaves in CPQ.
• Model drift. Even if you manage to import the rules, there’s no guarantee the CPQ model stays aligned when the ERP side evolves. Manual translation means errors creep in, and QA becomes expensive.
• Performance and maintainability. Models optimized for ERP feasibility are not necessarily optimized for CPQ responsiveness. A brute-force translation might work initially but degrade as your catalog grows.

If your CPQ model doesn’t reflect reality, you risk mis-quotes, invalid orders, sales frustration, and degraded customer experience. At cpq.se we’ve seen projects where conversion took far longer, required numerous iterations because modellers weren’t involved early, or where the automation failed because assumptions were wrong. That’s why readiness, prioritisation and a clear project plan matter - ideally as part of a CPQ Analysis Workshop.

Before jumping into code or tool automation, take these steps:

• Map the current state. Which SAP configurator (VC or AVC) you’re using, catalog size, number of variant tables, rule complexity.
• Define the target state. What you want in Tacton CPQ: guided selling, streamlined UI, performance targets, modular maintainability.
• Engage your modelling team. The people who understand features, constraints and the product logic need to be in on day one.
• Plan for automation + governance. Even if you automate rule translation, you need a governance process for changes, versioning and aligned evolution across SAP and CPQ.

At cpq.se we often see a first phase of about 500 man-hours, normally delivered within 4–5 months. This phase covers model conversion, initial integration, and configuration of key modules for manufacturing (for example clients like HMF and Swift Lifts). Starting the series with this context helps you set expectations and anchor the effort.

In short: converting from SAP VC/AVC to Tacton CPQ isn’t simply a data-migration project - it’s a modelling project, a change-management project, and an automation project. Recognising this up-front gives you a greater chance of success. In our next post (Part 2) we’ll dive into how to convert SAP constraints into CPQ logic - without losing control or performance.

Want to discuss your SAP model and how to bring it into Tacton CPQ?
Book a virtual coffee with Magnus Fasth or Patrik Skjelfoss here: https://www.cpq.se/meetcpqse

Related reading: https://www.cpq.se/the-cpq-blog/tacton-studio-modeling