Lesson 5 of 6
Performance and downtime
9 min
Listen to this lesson
Contoso has 60 hours, from Friday 18:00 to Monday 06:00, to stop the business, convert EP1, validate it and hand a working CMP back to users. The mock conversions are where that window is proven or broken. A conversion strategy that measures runtimes only in the dress rehearsal finds out too late whether the weekend is possible.
Technical downtime versus business downtime
Technical downtime is the time SUM and the related technical steps need with the system unavailable. Business downtime is the whole time users can't work: ramp-down, final interface runs, technical downtime, finance migration, follow-on activities, technical validation, reconciliation and business verification, and ramp-up. SAP's downtime-optimization options reduce only technical downtime; the course on downtime-optimized conversion states this plainly. The test plan must measure both.
- Fri 18:00Business stopsRamp-down: interfaces drained, jobs stopped, users locked
- Fri 20:00Before extractsFinance and logistics comparison data captured
- Fri 23:00 – SunTechnical conversionSUM downtime phases, finance data migration, follow-on activities
- SunValidationTechnical smoke checks, reconciliation, business verification
- Sun 14:00Go/no-go 2Grace's decision group decides, leaving time for a nine-hour fallback
- Mon 06:00Business resumesRamp-up and hypercare
Measuring runtimes in the mocks
Each mock should produce a timed runbook: planned and actual start and end for every step, including manual ones. SAP provides useful inputs. The Planned Downtime Calculator in SAP Readiness Check gives a first estimate based on project statistics when no run data exists. After a run, SUM's statistics file (UPGANA.XML) covers the technical downtime phases, and an application-side statistics file (APPLANA.XML, which can be created from the finance migration monitor) adds the data conversion activities. SAP's Technical Downtime Optimization app can visualize both, simulate approaches and provide a cutover plan to adjust.
| Measure | Mock 1 | Mock 2 | Dress rehearsal target |
|---|---|---|---|
| Ramp-down to SUM downtime start | 6 h | 5 h | ≤ 5 h |
| SUM technical downtime | 29 h | 24 h | ≤ 24 h |
| Finance data migration and follow-on activities | 17 h | 11 h | ≤ 9 h |
| Technical validation, reconciliation and business verification | 15 h | 13 h | ≤ 12 h |
| Ramp-up | 4 h | 5.5 h | ≤ 6 h |
| Float left in the 60-hour window | −11 h (71 h in total) | 1.5 h (58.5 h in total) | ≥ 4 h |
Runtime tracking across Contoso's mocks. Mock 1 overran the window by 11 hours; Mock 2 fitted with only 1.5 hours of float, short of the 4-hour minimum.
Mock 1 at Contoso took 71 hours, 11 more than the window, which triggered three actions: Sam added parallel processes in SUM after reviewing the statistics, Dan's team shortened reconciliation by preparing report variants and comparison templates in advance, and Luis moved two non-critical follow-on steps to after go-live with the owners' agreement. Options such as downtime-optimized conversion exist, but SAP positions them for experts and specific conditions (the guide notes that for Private Edition it requires an SAP expert with the corresponding training), so treat them as an architecture decision with its own testing, not a quick fix.
Performance after conversion
Downtime is one half; the converted system's performance is the other. Use the mocks to run the critical batch chain and the most-used transactions on production-sized data, and compare with EP1 baselines. Adapted custom code is the usual suspect: code that was fine on the old data model can read much larger structures after the conversion. Feed findings to Kenji's team early, and rerun the same measurement in the next mock.
| Question | Evidence | When |
|---|---|---|
| Does the conversion fit the window? | Timed runbook, SUM and application statistics | Every mock; final proof in the dress rehearsal |
| Is there time for validation and rollback? | Buffer to Monday 06:00; rollback decision point | Mock 2 and dress rehearsal |
| Does the converted system perform? | Batch chain and key transactions versus EP1 baselines | Mocks, with CMQ rebuilt from mock data |
What would you do?
Planning the dress rehearsal, Sam finds that the latest EP1 copy has grown and SUM downtime will likely run 3 hours longer than planned. The planned float shrinks from 4 hours to 1 against the 4-hour minimum. What should Priya recommend?
- Measure business downtime, not only technical downtime; optimizations reduce only the technical part.
- Time every runbook step in every mock; use SUM and application statistics and SAP's downtime tools.
- Keep a buffer for validation and a rollback decision; treat a breach as a finding.
- Use the mocks to compare batch and transaction performance with EP1 baselines.
Check your understanding · not graded
Lesson check
1. What do SAP's downtime-optimization approaches reduce?
2. Which tool gives a first downtime estimate before any run data exists?
3. Which file contains SUM statistics on the downtime phases?
4. Why is cutting reconciliation a bad way to fit the window?