If your company is moving to S/4HANA and you have Variant Configuration, you're facing a decision: migrate from LO-VC to AVC, or stay on LO-VC and deal with the consequences later.
I've been through this on multiple projects. This guide covers the strategies, the actual work involved, and the traps that catch most teams.
Why Migrate?
Three reasons drive every LO-VC to AVC project:
1. S/4HANA Cloud requires AVC. If you're going to the cloud, you don't have a choice. This is the biggest driver.
2. SAP stopped enhancing LO-VC. Bug fixes only. New features like the Fiori configuration app (PMEVC), enhanced variant tables, and improved constraint solver go exclusively to AVC.
3. Skills are shifting. New SAP consultants learn AVC, not LO-VC. The longer you wait, the harder it is to find people who understand your legacy LO-VC models.
The Three Migration Strategies
| Strategy | Upfront Effort | Risk | Total Cost | Best For |
|---|---|---|---|---|
| Big Bang | Highest | High | Lowest | Small models (<50 dependencies), simple products |
| Phased | Medium per phase | Medium | Medium | Most projects — start with one product family |
| Parallel Run | Highest | Lowest | Highest | Critical configs, zero tolerance for errors |
1. Big Bang
Convert all LO-VC models to AVC in a single project phase, then cut over completely.
Pros: One testing cycle, clean cutover, lowest total cost.
Cons: Highest risk. If something goes wrong, all configurable products are affected. Recovery is difficult.
When to use: You have fewer than 5 configurable materials, each with under 50 dependencies, and you can afford a full regression test cycle.
2. Phased (Recommended)
Migrate one product family at a time. Each phase includes full testing and a cutover window.
Pros: Risk is contained to one product family. Lessons from phase 1 improve phase 2. Business continuity is maintained for most products.
Cons: Longer total timeline. Multiple cutover windows. You maintain both LO-VC and AVC environments during the transition.
When to use: 95% of projects. If you have more than 3 configurable materials, start here.
3. Parallel Run
Run LO-VC and AVC side by side. Compare configuration results for every order until they match perfectly.
Pros: Lowest risk. You validate every single configuration before discontinuing LO-VC.
Cons: Highest effort. Two sets of dependencies to maintain. Two support teams. Integration points (CPQ, e-commerce, pricing) need dual connectivity.
When to use: Highly critical configurations where a mistake means production line stoppage or regulatory non-compliance.
The Migration Process: Step by Step
Phase 1: Assessment (2-4 weeks)
Before writing a single dependency, understand what you have:
- Inventory your models. How many configurable materials? How many dependencies per model? Use CU50 trace to document current behavior.
- Identify problem areas. Dependencies with $TEMP variables, nested LOOPs, or complex stateful operations are the ones that will break in AVC.
- Check variant tables. AVC requires explicit conversion or rebuild of variant tables.
- Audit external consumers. Every RFC, BAPI, API, or CPQ tool that calls VC_BAPI needs to be tested with AVC output.
Phase 2: Migration & Refactoring (4-12 weeks)
This is where the real work happens. The scope depends on your model complexity:
| Dependency Type | LO-VC | AVC | Migration Effort |
|---|---|---|---|
| Simple precondition | $SELF.COLOR in ('RED') |
Same syntax | Low |
| Procedure with conditions | $SELF.X = 'Y' if $SELF.Z = 'A' |
Same syntax | Low |
| Chained assignments | $SELF.X = $SELF.X + 1 |
Needs intermediate characteristics | Medium |
| Temporary characteristics | Uses $TEMP or unassigned chars | Must be class-assigned | High |
| Nested LOOPs | Procedural loops | Constraint solver | High |
| Variant table lookups | Single-key | Multi-key, needs rebuild | Medium |
Rule of thumb: count your dependencies. If you have over 200, plan for 8+ weeks of migration work.
Phase 3: Testing (4-8 weeks)
Testing is where most projects underestimate the effort. A proper testing plan includes:
Unit testing: For each dependency, compare LO-VC vs AVC output for:
- All valid input combinations
- Edge cases (empty values, boundary conditions)
- Invalid combinations (should fail gracefully)
Integration testing: For each configurable product:
- Sales order configuration (VA01/VA02)
- Production order configuration
- BOM explosion
- Pricing
- Material status and availability checks
Regression testing: Automate comparison of CU50 trace (LO-VC) against AVC trace for all models. Run weekly during migration to catch regressions early.
Phase 4: Go-Live & Cutover
- For phased approach: Schedule cutover during a maintenance window for each product family. Monitor for at least 2 weeks before declaring success.
- Rollback plan: Keep the LO-VC environment available for at least 1 month post-cutover. You will need it.
- Communication: Notify all configurators, sales teams, and supply chain about the transition.
Real-World Pitfalls
Assuming AVC Is a Drop-In Replacement
AVC uses a constraint-based solver, not a procedural interpreter. This means:
$SELF.PRICE = $SELF.BASE_PRICE,
$SELF.PRICE = $SELF.PRICE + 100 if $SELF.FEATURE_X = 'Yes'.
This works differently in AVC. The solver evaluates constraints as a set, not sequentially. If you have dependencies that depend on evaluation order, expect different behavior.
Skipping the Trace Comparison
Before and after migration, run CU50 trace for every configurable material. Compare the output line by line. If traces don't match, the configuration won't match.
# Run CU50 trace in LO-VC for material ABC
/nsap.com/cu50 material=ABC
# Run PMEVC trace in AVC for same material
# Compare configuration results, selected components, and pricing
Ignoring External Systems
Many companies have CPQ tools, pricing engines, or e-commerce platforms that call SAP through VC BAPIs. AVC changes the output structure of some BAPI calls. Test every integration point.
Forgetting About Archiving
LO-VC configuration data in existing sales orders, production orders, and quotations does not automatically migrate. Historical configurations remain in LO-VC format and may not be readable by AVC reports.
Not Training the Team
AVC looks different. The Fiori UI (PMEVC) is not CU50. Power users who can configure a product blindfolded in SAP GUI will struggle for the first few weeks. Budget for training.
Should You Migrate Now?
If you're still on ECC: Start planning. Include AVC migration in your S/4HANA project scope. Don't defer it to a post-go-live phase — that almost always costs more.
If you're on S/4HANA on-premise with LO-VC: You can stay on LO-VC for now, but start a pilot. Migrate one non-critical product family to AVC. Get experience before you're forced to migrate under pressure.
If you're on S/4HANA Cloud: AVC is mandatory. You're already on it. The question is whether your LO-VC dependencies were properly migrated or just "ported" — and whether they're ready for the constraint solver.
Summary
| Phase | Timeline | Key Deliverable |
|---|---|---|
| Assessment | 2-4 weeks | Migration scope, risk inventory |
| Migration | 4-12 weeks | Converted AVC models |
| Testing | 4-8 weeks | Trace comparison, integration tests |
| Go-Live | 2-4 weeks per product family | Cutover, monitoring, rollback plan |
The best strategy for most organizations: phased migration, starting with the simplest product family. Learn fast, fail small, then roll out to complex models with confidence.