SAP AVC Migration Checklist (VC to AVC, Free)

0%

0 of 34 items complete

10 critical items still open - these are the highest-risk gaps.

Download checklist:

Scope and decision

Target S/4HANA release is chosen and the availability of Advanced Variant Configuration in that release is confirmed in SAP documentationCRITICALBusiness reasons for AVC are written down, such as web configuration, performance or simplificationThe decision to adopt AVC is recorded, including any models that stay in classic VCLicensing and deployment implications are reviewed with the SAP account teamBusiness owners for each product family are namedCRITICALA project budget and timeline cover model rework and testing

Inventory the classic model

All configurable materials are listed with plant, BOM and routing usageCRITICALCharacteristics and classes (class type 300) are exported and countedAll dependencies by type are listed: preconditions, selection conditions, procedures and constraintsCRITICALVariant tables, variant functions and user-defined functions are identifiedConfiguration profiles and their use in sales and production are documentedUnused or obsolete models, characteristics and dependencies are marked for removalCustom ABAP linked to configuration, such as user exits and function modules, is listedCRITICAL

Prepare the target model

The migration approach per model is chosen: automated conversion, rework or rebuildDependency types without a direct equivalent are mapped to a replacement designCRITICALNaming conventions for the new model objects are agreedIntegration with pricing, such as variant conditions, is reviewedIntegration with other systems, such as CPQ, web shops and external configurators, is reviewedClassification and class assignments are verified for the targetAuthorizations and roles for model maintenance are defined

Test and prove

A test matrix of configurations exists with expected BOM and price resultsCRITICALValid and invalid combinations are both coveredResults from the classic model are compared with the migrated model for every test caseCRITICALSales orders, production orders and MRP are tested with migrated modelsPerformance is measured with realistic configuration loadBusiness users sign off on at least one model per product familyChange numbers and effectivity behaviour are verified

Cutover and support

Cutover sequence for models is agreed with the wider S/4HANA programCRITICALRollback options are documented for each waveOpen sales documents with existing configurations are handled and testedCRITICALUsers are trained on the new maintenance tools and screensHypercare staffing covers configuration questions after go-liveDocumentation of the new model, rules and ownership is handed to supportRetirement of unused classic objects is scheduled

Check items as they are confirmed. Critical items are those that commonly block a move when left open. Verify tooling and support status in current SAP documentation for your target release.

Get a read-only VC inventory outline

Tell us your release and model count and we will describe how a read-only inventory of classic VC objects could be produced.

Optional. The tool and every export work without this. No spam.

How to use the checklist

Work through the five groups in sequence and tick each item once it is evidenced, not merely discussed. Treat critical items as gates for the next phase. Export the list to PDF or Excel and keep it with your project documentation so steering committees can see progress. Run the list again for each wave of models, since later waves usually meet different problems than the first.

Evidence means a document, a report or a test result
Update the list at each project gate
Review the critical items with the business owner

What changes and what to verify

Advanced Variant Configuration is part of newer S/4HANA releases and uses a different configuration engine and model representation than classic variant configuration. Classic objects such as characteristics, classes and dependencies feed the migration, but not every construct has an identical counterpart. Variant tables, constraints and custom code are the usual places for rework. Because tooling, supported features and release-specific constraints change with SAP releases, check current SAP Notes and help documentation for your target version before committing to a plan.

Inventory first, decide second
Rules with no direct equivalent need a design decision
Custom ABAP is a frequent hidden risk

Reading your progress

If the inventory and decision groups are complete, you know the size of the work. Open critical items in the model preparation group are the usual predictors of delay, particularly unmapped dependency types and custom code. A complete test group before any cutover planning is the strongest signal of readiness. If testing is last on your list and not scheduled, the project is carrying hidden risk. Use the open count per group in status reports.

Common mistakes

Projects migrate everything, including models that no sales order has used for years. Others assume dependencies convert without review and discover differences only in user testing. Pricing integration through variant conditions is often forgotten, as are open sales orders with existing configurations. Finally, ownership is left with IT, while business users who understand the product are absent from testing. Start with a clear inventory, retire what you can, and involve the product experts early.

Frequently Asked Questions

What is Advanced Variant Configuration?

Advanced Variant Configuration, or AVC, is the newer configuration capability in SAP S/4HANA, designed to replace the classic variant configuration engine over time. It uses a different model structure and rule handling, so models are migrated or rebuilt.

Do I have to migrate all models?

Not necessarily at the same time. Many programs migrate in waves, and retire models nobody uses. Support and availability depend on your release, so confirm what SAP currently states for your version and plan accordingly.

What is the biggest technical risk?

Custom code and rules without a direct equivalent are the most common risk. Variant tables, constraints and user exits tied to configuration deserve early analysis, because they decide whether a model converts cleanly or needs redesign.

How do I prove the migrated model is correct?

Build a test matrix of valid and invalid configurations, record expected BOMs and prices from independent sources, and compare classic and migrated results case by case. See the configurable material test matrix worksheet for a ready structure.

If you want an inventory of your classic VC objects before you plan an AVC move, we can talk about running that analysis read-only on your own systems. The checklist is complete without us.

Talk to an Expert Explore More Free Tools

Related Tools

SAP

More ERP Migration & Selection tools

See all

SAP AVC Migration Checklist: Classic Variant Configuration to Advanced Variant Configuration