If you work with SAP Variant Configuration, you've heard the question: "Should we migrate from LO-VC to AVC?" It comes up in every S/4HANA project, and the answer is never simple.
I've been through this transition on multiple projects — from early S/4HANA on-premise 1809 to the latest S/4HANA Cloud. Here's what actually changes, what stays the same, and what nobody tells you about the migration.
What Is LO-VC?
LO-VC (Logistics Variant Configuration) is the original Variant Configuration engine, introduced in the 1990s. It runs on SAP GUI (transactions CU01/CU02/CU03, CU41/CU42, CU51). The dependency engine uses an interpreter-based approach — object dependencies are parsed and interpreted at runtime.
LO-VC is battle-tested. Many of the largest VC implementations in the world (automotive, elevator, machinery) run on LO-VC. It's stable, well-understood, and documented extensively across SAP community resources.
The catch: SAP stopped enhancing LO-VC years ago. Bug fixes only. New features go exclusively to AVC.
What Is AVC?
AVC (Advanced Variant Configuration) was introduced with SAP S/4HANA 1809. It's not a replacement of LO-VC from the ground up — it's a new runtime engine with a Fiori-based UI (PMEVC / Fiori App "Manage Product Configuration").
Key architectural difference: AVC uses a constraint-based solver instead of the procedural interpreter in LO-VC. This means AVC can handle complex interactions more efficiently and provides better validation feedback.
For S/4HANA Cloud, AVC is mandatory. For on-premise, you have a choice — for now.
Side-by-Side Comparison
| Dimension | LO-VC (Classic) | AVC (Advanced) |
|---|---|---|
| Introduced | 1990s (R/3) | S/4HANA 1809 |
| UI | SAP GUI (CU50, CU41) | Fiori (PMEVC, Manage Product Config.) |
| Dependency Engine | Interpreter-based | Constraint-based solver |
| Tables | CUCO, CUOB, KLAH, CABN, etc. | Same tables + AVC-specific shadow tables |
| Validity | Precondition + combination logic | Constraint net (more expressive) |
| Variant Table | 1-dimensional, limited size | Multi-dimensional, larger capacity |
| Dependency Editor | SAP GUI code editor | Fiori-based structured editor |
| S/4HANA Cloud | Not supported | Mandatory |
| SAP Enhancement | Maintenance only | Active development |
| Performance | Good for simple models | Better for complex constraint models |
What Changes in Practice?
1. The UI Is Different (And That's the First Thing People Notice)
LO-VC configuration happens in SAP GUI — CU50 for the configuration simulation, CU41 for sales order configuration. These are classic dynpro screens.
AVC uses a Fiori app called "Manage Product Configuration". The key differences:
- Real-time validation — As you select characteristic values, the UI shows which options become valid or invalid immediately
- Table-like interface — Characteristic values appear in a grid, not separate tabs
- Dependency trace — You can see exactly which dependencies fired and why
- Multi-level config — Sub-assemblies unfold inline
The Fiori UI is genuinely better for end users. But if your team is accustomed to SAP GUI speed (keyboard-driven, low latency), the transition takes adjustment.
2. Dependencies Need Refactoring — Especially Temporary Characteristics
This is the most common surprise in migration projects. In LO-VC, you could write procedures with temporary characteristics like Z_TEMP_CHAR in the following:
$SELF.Z_TEMP_CHAR = 'FEATURE_NO',
$SELF.Z_TEMP_CHAR = 'FEATURE_YES' if $SELF.Z_ASSIGNED_CHAR = 'CONDITION_A',
$SELF.Z_TEMP_CHAR = 'FEATURE_YES' if $SELF.Z_ASSIGNED_CHAR = 'CONDITION_B',
$SELF.Z_ASSIGNED_NUM = 100 if $SELF.Z_TEMP_CHAR = 'FEATURE_YES'.
AVC handles variables differently. Temporary characteristics are not supported, all characteristics must be assigned to a class that is bound to the material.
Migration Approaches
There are three strategies I've seen in real projects:
| Strategy | Effort | Risk | When to Use |
|---|---|---|---|
| Big Bang | Highest upfront | High | Small models (<50 dependencies) |
| Phased | Medium per phase | Medium | Medium complexity, need business continuity |
| Parallel Run | Highest total | Lowest | Critical configs, zero tolerance for errors |
95% of projects should choose phased migration. Start with one product family, validate thoroughly, then roll out to the rest.
Common Pitfalls
- Assume AVC is a drop-in replacement. It's not. Every dependency needs to be reviewed.
- Skip the trace comparison. Run CUTRC trace (LO-VC) side by side with AVC trace until they produce identical results for all test cases.
- Test only happy paths. The edge cases — especially incomplete configurations and invalid combinations — are where LO-VC and AVC diverge.
Should You Migrate?
If you're on S/4HANA Cloud: you don't have a choice. AVC is mandatory.
If you're on S/4HANA on-premise: start planning now. Even if you keep LO-VC today, the skills and tools for LO-VC are gradually fading. New consultants learn AVC. SAP's roadmap is AVC. The longer you wait, the harder it gets.
If you're still on ECC: include AVC migration in your S/4HANA project scope. Don't treat it as an afterthought — delaying the VC migration to a post-go-live phase often costs more than doing it upfront.