Lesson 3 of 5
SUM run
11 min
Listen to this lesson
The Software Update Manager is the technical tool for the conversion. In one procedure it migrates the database to SAP HANA if needed (using DMO), installs the SAP S/4HANA software, and converts the application data into the new data structures. SAP's guides for SUM are on the SL Toolset pages of the SAP Support Portal; read the conversion guide for the SUM support package you use, because details change between support packages.
The roadmap
- UptimeExtractionSUM reads stack.xml and extracts the software
- UptimeConfigurationParameters, parallel processes, transports to include
- UptimeChecksPrerequisites, space, SI-Check at the start
- UptimePreprocessingShadow repository built while users work; dictionary adjustment (SPDD); final SI-Check; system locked at the end
- DowntimeExecutionSwitch to the new software; with DMO, data migrated to SAP HANA; application data converted
- After downtimePostprocessingClean-up, logs and evaluation; SPAU and follow-on work begin
Most of the preparation runs in uptime: SUM builds a shadow repository for the new release while the business keeps working. Business downtime begins when SUM locks the system to switch over. In a DMO run, SAP Learning describes the shadow repository being built on the target database during uptime; at downtime the system's database connection switches to the target, and the application data is migrated and converted. The source database stays unchanged, which gives a fallback until the process completes.
DMO and its variants
| Option | What it does | Typical use |
|---|---|---|
| Standard DMO | Software update plus migration to the target database on the same application server level | ECC on another database, converting in place |
| DMO with system move | Adds a move of the whole system to a different environment | Moving data centers when a direct network link is not suitable |
| DMOVE2S4 | Combines conversion and move for SAP S/4HANA targets; supports downtime-optimized techniques; needs a good network between data centers | Conversion into a cloud data center, for example under RISE |
| Downtime-optimized DMO | Migrates selected large tables during uptime | Shortening the migration part of downtime |
| Downtime-optimized conversion | Moves much of the data conversion into uptime with change recording and replay | Large systems with tight windows; generally available since SUM 2.0 SP10, and for Private Edition it needs an SAP expert trained in course ADM329 |
Which option Contoso uses is a Basis and SAP decision, but the test lead should know the answer, because it changes what the weekend looks like. With a move into the cloud data center, the network between the two sites becomes part of the critical path, and a fallback means switching back to the untouched source system in the old data center. Priya's team plans the technical smoke test and the finance reconciliation around whichever option is chosen.
Running it well
- Include transports. Changes collected in the development conversion (finance Customizing, SPDD and SPAU adjustments, custom code fixes) are handed to SUM for the later conversions, so they are applied during the run instead of by hand afterwards.
- Tune parallelism. Process counts for uptime and downtime are set in configuration; SAP has notes on parallelism and on measures to reduce technical downtime. Tune them in the mocks, not on the weekend.
- Watch the logs. SUM stops on errors and offers repeat, ignore (where allowed) or exit. Every stop and every decision goes into the run log with a time.
- Record durations. SUM reports its runtimes per phase. Keep them from every run; they are the basis for the downtime estimate.
Worked example: what the mocks measured
| Phase | Mock 1 (h) | Mock 2 (h) | What changed |
|---|---|---|---|
| Ramp-down | 6 | 5 | Job and interface stop scripted |
| SUM technical downtime | 29 | 24 | Process counts tuned; table durations from Mock 1 reused |
| Manual post-processing | 17 | 11 | Follow-up steps turned into transports and scripts |
| Validation | 15 | 13 | Finance reconciliation reports prepared in advance |
| Ramp-up | 4 | 5.5 | Interface restart checks added |
| Total | 71 | 58.5 | Mock 1 overran the 60-hour window by 11 h; Mock 2 left 1.5 h float |
Contoso's measured hours from the two mock conversions. The dress rehearsal later finished with 4 h of contingency.
Two habits made the difference. First, DMO can use the table migration durations from a previous run to order and split the largest tables in the next one, so each mock gets faster. Second, Sam fixed hardware parity: CMQ's mock runs used the same SAP HANA sizing and application server capacity as production would, otherwise the runtimes would not predict the weekend.
What would you do?
During Contoso's Mock 2, SUM stops in Execution with an error in a data conversion step for a sales table. The SUM dialog offers to repeat the step. Sam's engineer wants to choose 'ignore' to keep to the timeline. What should Sam decide?
- SUM does the database migration (DMO, if needed), software update and data conversion in one procedure.
- Roadmap: Extraction, Configuration, Checks, Preprocessing in uptime; Execution in downtime; Postprocessing after.
- DMO keeps the source database unchanged until the end, which supports fallback.
- Include transports, tune parallelism in mocks, log every stop and keep phase runtimes.
Check your understanding · not graded
Lesson check
1. Which three things does SUM do in one conversion procedure?
2. In which roadmap step does business downtime mainly fall?
3. Why does a DMO run support fallback?
4. Why hand transports from the development conversion to SUM?
5. Contoso's go/no-go 1 is at Saturday 18:00. What does it check?