Lesson 6 of 6
Cutover: material variants, open orders and sign-off
11 min
Listen to this lesson
Transforming in CMQ is rehearsal. The real event is the release in production, where configured sales orders, material variants and planned production already exist. Variant configuration models are master data, not customizing, so the cutover is a business event inside a normal release window rather than a transport that "just arrives." This lesson plans that event for Contoso's Chicago work areas.
Decide how the model gets to production
There are two common patterns. Some teams run the transformation tools directly in production after rehearsing the exact steps in CMQ, because the tools work on the master data where it lives. Others build the AVC objects in a development or quality system and distribute them with the same master data distribution they already use for classification and dependencies (for example ALE). Whichever pattern you choose, rehearse it end to end, because the production run must reproduce what was tested. Contoso chose to run the tools in production for each work area, following a step list rehearsed twice in CMQ after a refresh from production.
| Pattern | Strength | Risk | Contoso |
|---|---|---|---|
| Run the tools in production | Works on the live master data; no distribution step | Every manual step must be repeated exactly; needs a rehearsed runbook | Chosen; runbook rehearsed twice in CMQ |
| Build elsewhere, distribute | Production receives finished objects | Distribution must cover every object type; mismatch with live data possible | Rejected; ALE was not set up for dependencies |
| Big bang for all work areas | One event, one communication | Largest blast radius; hard to fall back | Rejected |
| Wave by work area | Small, reversible steps; learning between waves | Two engines in parallel for a while | Chosen: three waves |
The cutover window
Open sales orders
Open configured order items are the hardest part. They were configured with LO-VC, and some will be changed after the switch: a customer changes the pulley type, or sales copies an item into a new order. Before the window, list every open configured item of the work area's models. During the window, run the comparison on a sample of them, chosen to include every model and the semantic risk cases. After the switch, test that a change to an old item behaves as designed in your release; this behavior is exactly what the CMQ rehearsal must prove beforehand.
| Open item state | Risk after switch | Treatment at Contoso |
|---|---|---|
| Configured, no production order yet | A later change re-evaluates rules with AVC | Compare a sample in the window; changes after the switch tested in CMQ rehearsal |
| Production order released | Order already has its BOM and routing; a configuration change triggers change handling | Freeze configuration changes on these items until delivered |
| Delivered, not billed | Billing reads the item price, not the engine | No action beyond the billing smoke test |
| Quotations with configured items | Copy into an order evaluates with AVC | Re-check the 20 highest-value open quotations after the switch |
Open order treatment for WA-CHI-HD (about 180 open configured items; illustrative course data).
Material variants
A material variant is a separate material number that references the configurable material with a fixed set of values, so it can be produced to stock. After the work area is released, run VCHMOVMVAR to switch the variants to the AVC model, then check a sample: open each variant, confirm that its values are still consistent, and check that MRP and a production order for the variant still explode the right components. Chicago has 60 variants of CMC-ALT-900; the team checked all 12 that had stock or open orders and a random sample of 10 others.
Fallback and hypercare
- Fallback: until new orders exist on AVC, setting the profile back to Classic is the simplest fallback, because the classic objects still exist. Rehearse it in CMQ and agree the deadline: once orders have been configured with AVC, falling back creates its own risks.
- Hypercare: for two weeks, inside sales reports every configuration complaint to one queue; the modeler on duty classifies each against the difference register.
- Clean-up: keep the classic objects until the last wave is signed and hypercare ends, then plan their removal as a separate, tested change.
- Engineering change management: if dependencies are changed with change numbers, keep using them; SAP Note 3366124 covers ECM support for constraints in AVC.
- T-2 weeksCMQ rehearsal 2Runbook timed; open-order comparison sample agreed
- T-1 weekGo/no-goRegression signed; difference register closed; fallback rehearsed
- T-0 SaturdayProduction windowFreeze, snapshot, transform, compare, release, variants, smoke test
- T+1 to T+10 daysHypercareDaily review of configuration issues; fallback deadline at the first AVC-configured delivery
- T+2 weeksWave sign-offProcess owners sign; next work area starts its rehearsal
What would you do?
In the production window for WA-CHI-HD, the comparison on the open-order sample shows 2 unexpected differences out of 60 items. Both involve the fan type characteristic. The window has 3 hours of float. What should Luis, as release manager, do?
What goes wrong in testing
- Rehearsal on stale data. CMQ was not refreshed, so the open-order sample in rehearsal has nothing in common with production. Refresh before the final rehearsal.
- Variants forgotten. The work area is released, but VCHMOVMVAR is not run, and stock replenishment for the variants explodes the old logic. Put the variant step and its check in the runbook.
- Smoke tests that only create orders. Include a change to an existing open item, a quotation copy and one variant planning run.
- No fallback deadline. Without one, the team debates falling back after AVC-configured orders already exist.
- Variant models are master data: the production release is a rehearsed business event.
- Snapshot open configured items and compare a sample during the window.
- Run VCHMOVMVAR after release and check variants for consistency, planning and stock.
- Keep classic objects as a fallback until hypercare ends; set a fallback deadline.
Check your understanding · not graded
Lesson check
1. Why is an AVC model release a business event rather than a simple transport?
2. What is the simplest fallback while no orders have been configured with AVC yet?
3. Which transaction switches material variants to the transformed AVC model?
4. Open order items already have a released production order. What did Contoso decide?