Lesson 5 of 6
Integration and cutover
10 min
Listen to this lesson
The integration picture changes three times in an APO replacement: today (APO on CIF), during parallel runs (APO live, IBP in shadow), and after switch-off (IBP and embedded PP/DS live, APO frozen). The dangerous phase is the middle one, because two planning systems are connected to one production S/4HANA system.
The double-requirement trap
If both APO and IBP release demand into the same active PIR version, MRP plans twice: rotors CMC-RTR-200 are ordered from Lakeside Components for both plans. Contoso's rule: during parallel runs, IBP releases only to a non-active PIR version (version 02, illustrative) used for comparison, never to version 00. The switch happens once, in the cutover, with a check that APO's last release has been deleted or replaced.
Cutover plan
| Step | Owner | Check |
|---|---|---|
| Freeze APO planning changes (Friday 12:00) | Sunita | Planners notified; no saves after freeze |
| Final APO release and snapshot of APO results | Jonas | Snapshot stored as reference |
| Stop APO jobs; deactivate CIF integration models to SP1 (CFM2) | Sam | No queue entries to SP1 afterwards |
| Activate advanced planning for Detroit materials; create PDS (CURTOADV_CRT) | Kenji's team with Jonas | PDS count equals production versions in scope |
| Final CI-DS loads; IBP cycle; release to PIR version 00 | Theo | Counts and totals against the IBP release |
| Delete or overwrite APO-released PIRs in version 00 | Jonas | No duplicate PIRs per material, plant and date |
| MRP Live run; PP/DS heuristic run for ASSY-10 | Jonas | Planned orders plausible; no rotor double ordering |
| Go/no-go and planner confirmation (Monday 06:00) | Grace's decision group | Checklist signed |
Illustrative course data: Contoso's planning cutover steps.
Integration tests before cutover
Integration testing for the transition covers three flows, each in its own state. Contoso tested them in the quality system first, then repeated the critical ones in the dress rehearsal on a fresh copy of production data.
| Flow | Test | Evidence |
|---|---|---|
| S/4HANA to IBP (CI-DS inbound) | Master data counts and history totals match after a full and a delta load | Task logs, count and total sheet |
| IBP to S/4HANA (release) | PIRs created in the right version, dates, units and plants; MRP plans components | Task log, MD63 output, MD04 sample |
| Embedded PP/DS | Advanced-planning materials have PDS; heuristic run creates planned orders on ASSY-10 resources | PDS list, product view, planning board snapshot |
| aATP | Fixed order set confirms the same or better dates than gATP, explained | Confirmation list with differences classified |
| APO switch-off | No CIF traffic to SP1 after deactivation, including overnight | SMQ1/SMQ2 screenshots, active model list |
The integration tests that gate the planning cutover.
Two tests look trivial and fail often: units of measure (IBP plans in pieces; one Chicago component was planned in boxes of 10 in APO) and calendars (IBP months against S/4HANA factory calendar days). Both produce plausible-looking but wrong requirements, so include them explicitly with numbers.
Fallback
Planning cutovers can fall back more easily than an ERP conversion, but only if nothing irreversible has happened. Contoso keeps SP1 frozen, not decommissioned, for two planning cycles after go-live. Fallback means reactivating the CIF models, restoring APO's PIRs from the snapshot and deleting IBP's release. The point after which fallback stops making sense is the first MRP run that converts planned orders and sends purchase orders to Lakeside on the new plan.
Contoso's fallback runbook has four lines and an owner for each: reactivate the CIF integration models to SP1 (Sam), restore APO's final PIR set into version 00 from the snapshot (Jonas), delete IBP's release from version 00 (Theo), and deactivate advanced planning for the Detroit materials if PP/DS created wrong orders (Kenji's team). The runbook was executed once in the dress rehearsal and took three hours, which set the latest fallback start on the go-live Sunday.
What would you do?
On the cutover Sunday, Jonas sees two PIRs for CMC-ALT-100 in plant 1710 for July: 1,520 from APO and 1,560 from IBP, both in version 00. MRP has not run yet. What should he do?
- During parallel runs only one system may feed the active PIR version.
- Cutover: freeze, final APO snapshot, stop CIF, activate PP/DS, IBP release, remove APO PIRs, run MRP.
- Verify that nothing arrives from APO after switch-off, including the first night.
- Keep APO frozen for fallback until the first irreversible downstream step.
Check your understanding · not graded
Lesson check
1. Why does IBP release to an inactive PIR version during parallel runs?
2. Which transaction deactivates CIF integration models?
3. Where do you check for CIF queue entries after deactivation?
4. When does fallback to APO stop making sense?