Lesson 2 of 5
Optimization
12 min
Listen to this lesson
When measured downtime does not fit the window with enough contingency, there are three families of options: reduce what has to be processed, make the processing faster, or move processing out of the downtime. SAP collects technical measures in an SAP Note on reducing technical downtime for conversions and upgrades, which the conversion guide references; read it with your Basis team and SAP before choosing.
Start with SAP Note 2351294
SAP keeps its technical measures in SAP Note 2351294, "S/4HANA System Conversion / Upgrade: Measures to reduce technical downtime". It is a collection that SAP updates over time, so Sam reads the current version against Contoso's SUM version before each mock, not once at the start. Pair it with the Technical Downtime Optimization app (SAP Note 2881515), which uses the SUM runs you already have to show where the time goes. SAP's training is clear about the limit: these SUM approaches reduce technical downtime only. Ramp-down, manual post-processing, validation and ramp-up are the program's to shorten.
Tuning standard DMO between mocks
- Parallel processes. The number of R3load processes for uptime and downtime migration is set in SUM and can be adjusted while the migration runs. Sam raised it for Mock 2 until the database and the network, not SUM, became the limit.
- Table duration files. After a run, SUM records how long each table took. Feeding those files from the previous run into the next one lets SUM split large tables and start the longest ones first, so the migration ends evenly instead of waiting on one table.
- Downtime migration test cycles. SUM can repeat the downtime migration phase
EU_CLONE_MIG_DT_RUNwithin one mock, so different settings can be tried without converting a new copy. - Benchmarking. SUM's DMO benchmarking tool measures export and import throughput on sample tables before a full mock; useful when the network to the RISE data center is part of the path.
- Customer Transport Integration. Contoso's project transports from CMD are integrated into the SUM run rather than imported by hand afterward, which removes steps from manual post-processing.
The options
| Option | How it saves time | Cost and constraints |
|---|---|---|
| Data volume reduction | Archive or delete data before conversion, so less is migrated and converted | Needs retention decisions and archiving runs months ahead; SAP's DVM tools in Solution Manager help find candidates |
| Tuning and parallelism | More parallel processes in uptime and downtime; table splitting and ordering | Limited by hardware; tuned across mocks |
| Customer Transport Integration | Applies customer transports during the SUM run instead of after it | Transports must be prepared and tested in earlier conversions |
| Downtime-optimized DMO | Migrates selected large tables to SAP HANA during uptime | Extra configuration; a database migration is needed in the first place |
| Downtime-optimized conversion | Moves much of the data conversion, including finance and inventory, into uptime; changes are recorded and replayed | SAP restricts it to experts who passed its specialist training; more project effort and uptime restrictions |
| Moving manual work out of the window | Pre-load checks, static validations and preparation done before Friday 18:00 | Needs discipline and a runbook that marks what is truly in-window |
How downtime-optimized conversion changes the shape
In a standard conversion, almost all data conversion happens in downtime. In downtime-optimized conversion, SUM converts most data while the business is still working. SAP Learning describes what moves to uptime: much of the finance and material ledger conversion, the conversion of material documents, shadow field migration for very large tables such as pricing conditions and document flow, and selected follow-up programs. Changes made by users during uptime are recorded with SUM's change record and replay technology and replicated, so only the delta is converted in downtime.
- Uptime, days beforePrepare and classifyTables classified; replication triggers switched on
- UptimeUptime conversionFinance and inventory conversion on a copy; recorded changes replicated
- UptimeRestrictions applyFor example a short-term lock for asset accounting and controlled finance Customizing changes
- DowntimeDelta and final replicationRemaining changes converted; switch to the new release
- AfterValidation and ramp-upSame reconciliation and tests as a standard conversion
| Topic | Downtime-optimized conversion, per SAP |
|---|---|
| What moves to uptime | Part of the finance data conversion; inventory (MM-IM) conversion; field conversion of KONV and VBFA; selected XPRAs and SDMIs; long-running XCLAs |
| Database | With DMO, affected tables are also migrated in uptime. SAP recommends DMO even when the source already runs on SAP HANA, to get the full feature set |
| Change capture | Database triggers record end-user changes in uptime; SUM replicates them and does a final replication in downtime |
| Restrictions | Customizing freeze and development lock on production before downtime; a short-term Asset Accounting lock; no mass loads during replication |
| Data center move | DMO with System Move cannot be combined with the downtime-optimized options; the DMOVE2S4 variant for moving to the cloud can |
Facts to check before choosing downtime-optimized conversion. Verify the details for your SUM support package.
The approach shortens technical downtime but brings its own constraints. SAP makes it available only to experts who completed SAP's dedicated training: SUM asks for a password that SAP issues through a support ticket in which the knowledge badge for downtime-optimized conversion is shared. Older SUM versions also needed a standard conversion of a production copy first, to produce a transport with the finance Customizing; with current SUM versions, the initial finance Customizing can be done on SUM's temporary instance during uptime, so that extra run is no longer needed. Check the SAP Note for your SUM support package (for SUM 2.0 SP 27 it is SAP Note 3707882). During uptime some business activities are restricted, which feeds the freeze plan in lesson 3.
Choosing
- Does the measured duration fit with the agreed contingency?Yes → keep the standard approach and protect the plan · No → next question
- Can manual and validation work move out of the window?Yes → do that first; it is cheapest · No → next question
- Can data volume shrink in time?Yes → archive or delete candidates now · No → next question
- Is technical downtime the problem after tuning?Yes → evaluate downtime-optimized DMO or conversion with SAP · No → revisit validation and ramp-up
What would you do?
After Mock 2, Contoso has 1.5 hours of float. The steering group wants at least four. Sam proposes downtime-optimized conversion; Luis notes that manual post-processing took 11 hours and validation 13. What should Grace ask the team to do first?
- Three families: process less data, process faster, move processing out of downtime.
- Cheapest first: move manual work out of the window, parallelize, reduce data volume, tune.
- Downtime-optimized conversion moves much data conversion into uptime with change replay.
- It needs an SAP specialist expert, more effort and uptime restrictions; validation stays the same.
- Read SAP Note 2351294 for each mock; tune DMO with process counts, table duration files and test cycles.
Check your understanding · not graded
Lesson check
1. What does downtime-optimized conversion move into uptime?
2. Which optimization is usually the cheapest to try first?
3. What does SAP require for downtime-optimized conversion to Private Edition?
4. Why can data volume reduction shorten downtime?
5. In standard DMO, what lets SUM order and split tables better in Mock 2 than in Mock 1?