Lesson 6 of 6
From deadline map to test calendar
10 min
Listen to this lesson
A deadline map that sits in a slide deck changes nothing. Its value comes when each row becomes a dated piece of work with testers assigned to it. Most clocks on the map end in a migration, and every migration needs a baseline, a comparison and a sign-off. The constraint is rarely money; it is the same twenty people who also run release regression, close testing and user acceptance. This lesson turns Contoso's map into a calendar.
Test workload by deadline type
| Deadline type | Typical work | Test workload | Who signs |
|---|---|---|---|
| ECC maintenance | Conversion to SAP S/4HANA | Full program: unit, integration, regression, UAT, mocks, dress rehearsal | Process owners and Grace's decision group |
| Compatibility Scope use right | Replace one function (LE-TRA by TM, CS by Service) | Process regression around the function, data migration of open documents, UAT | Process owner of that process |
| Integration platform (PI/PO) | Rebuild interfaces in SAP Integration Suite | Message-level comparison old versus new, partner tests, cutover per wave | Theo and the business owner per interface |
| ALM platform (Solution Manager) | Move monitoring, test and change assets to SAP Cloud ALM | Monitoring coverage tests, alert routing tests, archive of test evidence | Run team lead and Priya |
| Analytics and planning (BW, BPC, APO) | Rebuild models and queries | Report and plan reconciliation old versus new with tolerances | Finance or planning process owner |
Each deadline type creates a different test workload.
Sequencing rules
- Use-right dates outrank maintenance dates. Running without a use right is a compliance problem; running without maintenance is a risk.
- Do not stack migrations on the same process in the same quarter. If order-to-cash interfaces move to Integration Suite, do not also replace LE-TRA shipments that quarter: a defect would have two suspects.
- Keep the old system alive until its comparison is signed. Decommission dates come after the sign-off, not before.
- Avoid close and peak periods. Dan's year-end close and the fleet ordering peak are freeze windows.
- Leave the last six months before a clock empty. Slips are normal; a deadline met in the final week leaves nothing for fixes.
Three choices drive Contoso's calendar. First, the Integration Suite waves (pilot at about three months, procure to pay at four to five, order to cash at six to seven) run in sequence, because Theo's team and Priya's interface testers are the same people. Second, monitoring moves off Solution Manager in parallel with the pilot wave, because the new interfaces must be monitored in SAP Cloud ALM from their first day. Third, the two Compatibility Scope replacements go into later years, one at a time: the TM project first, because shipments touch order-to-cash and integration wave 2 must be stable before it starts.
- Go-live, Q3SAP S/4HANA liveECC EP1 becomes read-only for audit
- +3 to +7 monthsPO interfaces movePilot, procure to pay, order to cash waves; comparison tests per wave
- Before end of 2027Solution Manager retired for monitoringTest evidence archived; ChaRM history kept for audit
- Later yearsTM, then ServiceEach with its own regression baseline from tagged test cases
- Before end of 2030No compatibility items leftReadiness or SI-Check shows no usage
Making the calendar real
Grace puts each move on the program's release calendar in SAP Cloud ALM, with a named owner, the regression scope (from the test cases tagged in earlier lessons), the environments (CMQ during the program, CMR after go-live) and the freeze windows. Priya checks capacity: during integration wave 2, the release regression service level in CMR still has to be met, so no other migration runs that quarter.
| Calendar row | Owner | Test environment | Baseline | Signer |
|---|---|---|---|---|
| PO interface waves | Theo | CMR with CMC_TEST | Messages captured from XP1 | Theo and the business owner per interface |
| Solution Manager monitoring off | Sam | CMR and Cloud ALM | Current monitors and alert list in Solution Manager | Sam and Priya |
| Solution Manager test and ChaRM history | Priya | Archive | Exported test evidence and change records | Priya, with Dan for audit-relevant items |
| TM replaces LE-TRA | Maria, the O2C key user, with the logistics lead | CMR | Tagged shipment test cases | Order-to-cash business signer |
| Service replaces CS | Service lead | CMR | Tagged service order test cases | Service process owner |
| ECC read-only copy retired | Dan and Sam | Not applicable | Archived reports for audit years | Dan, after the auditors confirm |
Illustrative course data: Contoso's calendar rows with owners, environments, baselines and signers.
Two rows are easy to forget. Solution Manager holds years of test evidence and change records that auditors may ask for, so it needs an archive plan, not just a switch-off. And the read-only ECC copy kept after the conversion has its own end: once the auditors have closed the conversion year and retention is covered by an archive, it can go. Both belong on the same calendar as the migrations.
What would you do?
Contoso's integration wave 2 move of the Great Lakes Fleet Services EDI flows is planned for months 6 to 7 after go-live (February to March 2027). A manager proposes starting the TM project for LE-TRA shipments in the same quarter "to save time before 2030". What should Priya recommend?
- Every deadline becomes a migration with a baseline, a comparison and a sign-off.
- Use-right dates outrank maintenance dates; earlier clocks go first.
- Never stack two migrations on the same process in one quarter.
- Decommission only after the comparison test is signed and archived.
Check your understanding · not graded
Lesson check
1. Why avoid two migrations on the same process in one quarter?
2. When may a legacy system be decommissioned?
3. Why does Contoso move monitoring to Cloud ALM during the pilot wave?
4. Which type of date should outrank the others when sequencing?