Optimizing SAP to Tacton CPQ Migration: Avoid Overusing Constraints

Written by Rolf Staflin | Dec 4, 2025 7:00:00 AM

Translating preconditions into constraints sounds logical - until it kills your performance.

It’s a common mistake during SAP VC/AVC to Tacton CPQ migration: treating every precondition in SAP as if it should become a CPQ constraint. After all, preconditions are just rules that say when a component is valid, right? But in Tacton, blindly converting these into constraints not only bloats your model - it can introduce unnecessary logic, slow down the solver, and make your models harder to manage. In this post, we’ll show how to avoid that trap by using class structure and features more effectively.

Let’s start with a typical example. In SAP, you might have a precondition attached to a component:

CHASSIS EQ XL

That means this component - say, Sleeper Cab A - is only available if the chassis is XL. When migrating, it’s tempting to write the CPQ equivalent as:

sleeper_cab = A -> chassis = XL

Technically, this works. But this type of constraint is evaluated during solving - after the system has already made a bunch of selections. If the condition fails, the solver hits a dead end and has to backtrack. That slows down the response, which is not a great experience.

Tacton CPQ gives you a smarter option: model this logic through class features.

Instead of writing a constraint, make “chassis” a feature of the Sleeper Cab class. Then, specify which chassis types are valid for which cabs using feature values. Now the CPQ configurator enforces this logic early - before the solver makes an invalid selection.

Why is this better?

It moves logic into the structure of the product.
It avoids needless backtracking during configuration.
It improves performance by reducing the number of active constraints.
It makes the model easier to understand and maintain.

Here’s another SAP pattern: the SELECTED() condition. Often used to delay visibility or validation until the user has made a choice:

SELECTED(CHASSIS) AND CHASSIS EQ XL

In SAP, this prevents the cab from appearing unless the user has already selected a chassis. But in Tacton CPQ, SELECTED() is always true. Why? Because Tacton’s solver always makes selections - even before the user clicks anything. So the above logic doesn’t translate 1:1, and keeping SELECTED() in your CPQ constraint is not only unnecessary - it can confuse the model.

This is part of a broader principle: don’t try to force SAP logic structures into CPQ. Tacton was built around a different solving paradigm. It favors structural logic (via classes and features) over reactive logic (via constraints).

When we at cpq.se help clients migrate from SAP to Tacton, we spend significant time restructuring models. Not just translating rules, but asking: what’s the intent of this rule? Could it be handled more cleanly in a combination class? Could it become a class feature instead? Could a value domain or UI rule eliminate the need for a constraint altogether?

Fewer constraints = faster models + easier debugging.

Constraints should be used when the logic can’t be captured through structure. They are powerful - but not always efficient. Overuse is one of the top reasons CPQ models become slow, unstable, or opaque.

In the next part of our series, we’ll explore how automated testing in Tacton CPQ helps validate these modelling choices and catches silent failures that manual testing often misses.

Want help evaluating your SAP preconditions for CPQ conversion?
Magnus and Patrik can walk through your model and suggest better patterns: https://www.cpq.se/meetcpqse

View full post