# SAP AVC Migration Checklist: Classic Variant Configuration to Advanced Variant Configuration > Source: https://netray.co/tools/sap-avc-migration-checklist > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer A planning checklist for inventorying classic VC objects, preparing for Advanced Variant Configuration and proving the result before cutover. ## Category erp-migration ## Erp SAP S/4HANA ## Audience - SAP VC consultant - SAP architect - S/4HANA project manager ## Tool **Kind:** checklist **Scoring Note:** 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. **Groups:** #### Scope and decision **Items:** **Text:** Target S/4HANA release is chosen and the availability of Advanced Variant Configuration in that release is confirmed in SAP documentation **Critical:** true Business reasons for AVC are written down, such as web configuration, performance or simplification The decision to adopt AVC is recorded, including any models that stay in classic VC Licensing and deployment implications are reviewed with the SAP account team **Text:** Business owners for each product family are named **Critical:** true A project budget and timeline cover model rework and testing #### Inventory the classic model **Items:** **Text:** All configurable materials are listed with plant, BOM and routing usage **Critical:** true Characteristics and classes (class type 300) are exported and counted **Text:** All dependencies by type are listed: preconditions, selection conditions, procedures and constraints **Critical:** true Variant tables, variant functions and user-defined functions are identified Configuration profiles and their use in sales and production are documented Unused or obsolete models, characteristics and dependencies are marked for removal **Text:** Custom ABAP linked to configuration, such as user exits and function modules, is listed **Critical:** true #### Prepare the target model **Items:** The migration approach per model is chosen: automated conversion, rework or rebuild **Text:** Dependency types without a direct equivalent are mapped to a replacement design **Critical:** true Naming conventions for the new model objects are agreed Integration with pricing, such as variant conditions, is reviewed Integration with other systems, such as CPQ, web shops and external configurators, is reviewed Classification and class assignments are verified for the target Authorizations and roles for model maintenance are defined #### Test and prove **Items:** **Text:** A test matrix of configurations exists with expected BOM and price results **Critical:** true Valid and invalid combinations are both covered **Text:** Results from the classic model are compared with the migrated model for every test case **Critical:** true Sales orders, production orders and MRP are tested with migrated models Performance is measured with realistic configuration load Business users sign off on at least one model per product family Change numbers and effectivity behaviour are verified #### Cutover and support **Items:** **Text:** Cutover sequence for models is agreed with the wider S/4HANA program **Critical:** true Rollback options are documented for each wave **Text:** Open sales documents with existing configurations are handled and tested **Critical:** true Users are trained on the new maintenance tools and screens Hypercare staffing covers configuration questions after go-live Documentation of the new model, rules and ownership is handed to support Retirement of unused classic objects is scheduled ## Content **Intro:** Moving from classic variant configuration to Advanced Variant Configuration in S/4HANA is a model project, not a switch. This checklist helps you inventory what you have, decide what to migrate, and prove that results match before cutover. **Sections:** #### How to use the checklist **Body:** 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. **Bullets:** - 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 **Body:** 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. **Bullets:** - Inventory first, decide second - Rules with no direct equivalent need a design decision - Custom ABAP is a frequent hidden risk #### Reading your progress **Body:** 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 **Body:** 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. **Cta:** 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. **Faq:** #### What is Advanced Variant Configuration? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms sap avc migration checklist, advanced variant configuration s4hana, sap vc to avc migration, sap ivc to avc, sap avc readiness, sap variant configuration s4hana conversion, sap avc project plan, sap configuration model migration --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json