Lesson 1 of 5
Integrated planning
12 min
Listen to this lesson
A brownfield program fails in the gaps between workstreams more often than inside them. Basis can run a flawless SUM, the developers can clear every finding, and the program can still miss go-live because business partner synchronization finished late, a tax add-on had no conversion path, or key users were booked for year-end when user acceptance testing was due. The program lead's job is to see those gaps first. The tool is an integrated plan: one timeline, one set of dependencies and one definition of done for every workstream.
The workstreams of a conversion
| Workstream | Main deliverables | Contoso owner |
|---|---|---|
| Technical conversion | Maintenance Planner plan, SUM runs, DMO, follow-up, runtimes | Sam (Basis) |
| Custom code | Usage scoping, remote ATC, adaptation, SPDD and SPAU transports | Kenji (ABAP) |
| Finance | Preparation in ECC, migration Customizing, reconciliation, sign-off | Dan (finance) |
| Business partner and data | CVI synchronization, data cleansing, data volume reduction | Maria and Dan with the data team |
| Security and roles | Role adjustment, Fiori catalogs and business roles, GRC rules | Nadia (security and GRC) |
| Integration | Interfaces, output, partners, PO 7.5 connections | Theo (integration) |
| Testing | Strategy, regression set, cycles, defect management, test sign-off | Priya |
| Cutover | Runbook, rehearsals, freeze, go/no-go sequence | Luis |
| Change and training | Impact on users, training, communications | Change lead |
The backbone: conversion cycles
In a new implementation, the plan's backbone is usually design and build sprints. In a conversion, it is the sequence of conversion cycles: each time a system is converted, every workstream has something to deliver before it and something to prove after it. SAP Learning describes the pattern: convert a sandbox first and repeat until it is stable, then plan the conversions of development, quality and production. SAP's conversion guide recommends converting a dedicated development system first and collecting the required changes in transports that SUM applies in the later conversions.
- ExploreSandbox conversionsCopies of EP1 converted until stable; blockers and volumes found
- RealizeCMD conversionDevelopment copy converted; adaptation and finance Customizing collected in transports
- RealizeCMQ conversionQuality system converted with the transports; functional test cycles
- Realize to DeployMock 1 and Mock 2Fresh production copies; timing, reconciliation, fallback
- DeployDress rehearsalFinal runbook proven; frozen afterwards
- Deploy, Q3CMP conversionProduction weekend: Friday 18:00 to Monday 06:00
Two landscapes at once
During the project Contoso runs two landscapes. The maintenance landscape (ED1, EQ1, EP1) keeps the business running, with changes controlled by ChaRM on SAP Solution Manager 7.2. The project landscape (CMD, CMQ, later CMP) is managed in SAP Cloud ALM. Any change made in maintenance must be retrofitted into the project, or it will be lost or conflict at conversion. The integrated plan needs a retrofit process, an owner, and a rule that tightens over time until the development freeze.
Why retrofit matters in a conversion: Mock 1, Mock 2 and the dress rehearsal each convert a fresh copy of EP1, so a maintenance change that reached EP1 is in the copy automatically. But SUM also imports the adaptation transports built in CMD, and those carry the version of each object as it was when Kenji’s team adapted it. If ED1 changed the same object later, the import overwrites the newer maintenance version, and the regression set may never notice. Retrofit closes that gap by re-applying each maintenance change in CMD (double maintenance) and testing it in CMQ.
| Period | Rule for ECC maintenance changes | Retrofit into the project |
|---|---|---|
| Until the CMD conversion | Normal ChaRM changes in ED1 → EQ1 → EP1 | Not needed: the CMD and sandbox copies already contain them |
| CMD conversion to development freeze | Changes allowed, each with a retrofit ticket | Double maintenance in CMD within five working days; tested in CMQ |
| Development freeze to dress rehearsal | Legal, audit and emergency changes only | Retrofitted at once and listed at the next gate |
| After the dress rehearsal | Emergency changes only, approved by Grace’s decision group | Added to the frozen transport list with a retest |
Contoso’s retrofit and freeze rules. The rule tightens as production approaches; the five-day target is Contoso’s choice.
What goes into the integrated plan
- Milestones and gates for every conversion cycle, with entry and exit criteria (lesson 3).
- Cross-workstream dependencies: every hand-off from one stream to another, with a date and an owner on both sides (lesson 4).
- Business calendar constraints: period ends, year-end, peak shipping weeks, holidays, the Q3 go-live window.
- Key resources: named people needed by more than one stream at the same time, such as Dan's controllers or Maria's key users.
- External dates: SAP and partner commitments, add-on releases, the RISE contract's provisioning dates, hardware or data center moves.
- Follow-on programs: Contoso's Wave 2, the load of Alternadores del Norte (company code 1910) into the converted system after go-live.
What would you do?
Contoso's workstream leads each have a detailed plan, and every plan shows green. Yet in the first integrated review, Grace finds that the security team plans role adjustment after CMQ testing starts, and the finance team plans its first regression cycle in the same week as year-end close. What should she do?
- Brownfield programs fail in the gaps between workstreams; the integrated plan exposes them.
- The backbone is the conversion cycles: sandbox, CMD, CMQ, mocks, dress rehearsal, production.
- Run maintenance and project landscapes in parallel, with an owned retrofit process.
- The program plan holds milestones, gates, dependencies, calendar constraints, key resources and external dates.
Check your understanding · not graded
Lesson check
1. What forms the backbone of an integrated plan for a system conversion?
2. Why does a conversion program need a retrofit process?
3. Which item belongs in the program-level plan rather than only a workstream plan?
4. Every workstream plan is green, but two plans collide in the same week. What does that show?
5. After CMD was converted, a ChaRM change to a custom pricing routine reaches EP1. What protects it in the next mock?