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 a practical framework for choosing the right migration strategy, one based on actual model complexity instead of guesswork.
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 |
|---|---|---|---|
| Big Bang | Highest | High | Lowest |
| Phased | Medium per phase | Medium | Medium |
| Parallel Run | Highest | Lowest | Highest |
1. Big Bang
Convert all LO-VC models to AVC in a single project phase, then cut over.
Pros: One testing cycle, clean cutover, lowest total cost.
Cons: Highest risk. If something goes wrong, all configurable products are affected. Recovery is difficult.
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.
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.
What "Small" Actually Means
Most migration guides tell you to count your dependencies and choose accordingly:
"If you have fewer than 50 dependencies, do Big Bang."
This is misleading. Dependency count alone tells you nothing about actual migration effort.
Real example: A model with moderate internal complexity can still generate a high number of CU06 hits on a single core characteristic. That's not "small."
The same number of dependencies can be:
- Simple preconditions, each independent → relatively fast
- Tightly coupled procedures with cross-references → significantly longer
You need a better measure. This one actually works.
The Framework: Change Point × Impact Radius
Instead of counting total dependencies, assess two independent dimensions for each model:
Dimension 1: Change Point (Internal Complexity)
The question is: how many actual dependencies would you touch if a core characteristic changed?
How to measure: Run CU06 for the 3-5 most critical characteristics. Look at No. of Dependencies. This is your Change Point. Take the highest value across those characteristics.
| Change Point | Meaning |
|---|---|
| 1-10 | Low — one sprint work |
| 11-25 | Moderate — manageable in phases |
| 26-50 | Complex — needs careful planning |
| 51+ | Critical — high risk, plan accordingly |
CU06 also gives you No. of Hits per dependency. A high hit-to-dependency ratio means the characteristic is referenced multiple times inside each dependency. The work per dependency is higher.
Dimension 2: Impact Radius (Cross-Model Coupling)
This characteristic appears in dependencies used by how many other configurable materials?
How to measure: From the CU06 result list, pick the 2-3 dependencies with the highest hits. Click into each → use the WHERE-USED LIST function → check how many configurable profiles reference it. A profile maps almost directly to a configurable material.
| Impact Radius | Profiles Referenced | Meaning |
|---|---|---|
| Narrow | 1-3 profile(s) | Internal — affects one product family |
| Medium | 3-10 profiles | Shared — crosses product families under the same class |
| Wide | 10+ profiles | Global coupling — used across multiple classes |
The Decision Matrix
Combine both dimensions to select your strategy.
| Change Point | Narrow (1-3 profiles) | Medium (3-10 profiles) | Wide (10+ profiles) |
|---|---|---|---|
| 1-10 | Big Bang | Decouple → Big Bang | Decouple → Big Bang |
| 11-25 | Phased per family | Phased per char group | Phased + decouple prep |
| 26-50 | Phased + refactor | Phased + refactor prep | Parallel Run |
| 51+ | Parallel Run or refactor first (any radius) |
Key patterns:
Low Change Point + Wide radius → Don't migrate yet. First decouple the shared dependencies, then Big Bang the decoupled model. The migration itself is easy. The decoupling is the work.
High Change Point + Narrow radius → The model is internally complex but isolated. Phased per characteristic group works well. Invest in refactoring during migration.
High Change Point + Wide radius → This is your highest-risk model. Consider Parallel Run, or budget significant refactoring time before migration.
Any Change Point at 51+ → Regardless of radius, this model needs special treatment. Parallel Run is the safe choice. If you refactor first, re-assess with CU06 after : the Change Point should drop.
The Five-Step Assessment Process
You can assess any model in under an hour using standard SAP reports.
Step 1: Select Target Characteristics
Identify 3-5 characteristics that are core to the model, the ones you know from experience would cause the most trouble if changed.
These include: pricing characteristics, material selection drivers, characteristics referenced in variant tables, and any characteristic that appears in "every other procedure."
Step 2: Run CU06 : Get Change Point
For each target characteristic, run CU06:
- Transaction: CU06 (Where-Used List for Characteristics)
- Input: Characteristic name
- Read: No. of Dependencies column
Record the highest value across all 3-5 characteristics. That's your Change Point.
Also note No. of Hits : a high hits-to-dependencies ratio means the characteristic is referenced multiple times within each dependency. The work per dependency is higher.
Step 3: Scan the CU06 Result List
Look at the dependency names and classes in the result. Quick assessment:
- All from one configurable material? → Likely narrow radius.
- Spread across multiple materials or classes? → Radius may be wider.
Step 4: Drill Into Key Dependencies : Get Impact Radius
From the CU06 result, pick the 2-3 dependencies with the highest hits and run WHERE-USED LIST on each:
- In CU06 result, select a dependency → menu or right-click → Where-Used List
- Count the configurable profiles that reference this dependency
Take the highest count. That's your Impact Radius.
Step 5: Consult the Matrix
Find your position on the Change Point × Impact Radius matrix and select the recommended strategy.
When to Refactor Before Migrating
The framework may suggest refactoring before migration in two cases:
1. Wide radius + low Change Point You have a shared dependency used by many materials. Migrating the dependency as-is means testing across all those materials. Instead:
- Decouple the dependency into material-specific versions
- Test each material independently
- Then migrate the now-isolated dependencies
2. High Change Point on a core characteristic Multiple dependencies reference the same characteristic in different ways. Consider:
- Consolidating redundant procedures
- Standardizing value ranges
- Moving complex logic from procedures to variant tables
- Re-assess with CU06 afterward
In both cases, refactoring pays off twice: it makes migration easier, and it makes the post-migration model more maintainable.
Example: Real Model Assessment
This is what the framework looks like in practice. After selecting core characteristics and running CU06, you record the Change Point (highest No. of Dependencies) and the Impact Radius (highest profile count from WHERE-USED). The decision matrix then maps these two dimensions to the recommended strategy.
Without this framework, teams might misclassify a model based on total dependency count alone and attempt an unsuitable approach, with predictable consequences.
Summary
| Phase | Timeline | Key Deliverable |
|---|---|---|
| Assessment | 1-2 weeks | CU06 assessment of all core models |
| Migrate low-complexity models | 2-4 weeks per product family | Big Bang for Change Point ≤10 |
| Migrate medium-complexity models | 4-8 weeks per product family | Phased migration |
| Migrate high-complexity models | 8-16 weeks | Parallel Run or phased with refactoring |
| Testing & Cutover | 4-8 weeks total | Trace comparison, integration tests |
The best strategy is the one that matches your actual model complexity. Use CU06 data, not gut feel.
Sources: SAP Note 3175712 — VC Transition information | Transaction CU06 (model complexity assessment)
Comments & Danmaku
Leave a comment — it flies across the page as danmaku!