Downtime components

A system conversion converts the whole ECC database in one go, so the business has to stop using the system for a while. How long is the central planning question of the cutover. Contoso's answer is fixed by the business: 60 hours, from Friday 18:00 to Monday 06:00, when the first shift starts at the Detroit plant. Everything in this course is about fitting a measured conversion into that window with room to spare, and proving it before the real weekend.

Technical downtime is only part of it

SAP's training on downtime-optimized conversion separates technical downtime, the SUM phases that run while the system is locked, from business downtime, which also includes ramp-down, manual post-processing such as importing transports, testing and validation, and ramp-up. Business users experience the whole thing. A plan that budgets only for SUM's runtime will overrun even if SUM is perfectly on time.

Build the estimate from measurements

Downtime estimates are only credible when they come from mock conversions on production-sized copies. Data volume drives the runtime of the database migration and the data conversion, so a run on a small development system says little. SUM records runtimes for its phases; the finance migration monitor shows durations per activity; the runbook records every manual step's start and end. Put them together into one timeline per mock.

Two lessons stand out. First, Mock 1 overran by 11 hours, and that was a useful result: it showed where the time went. Second, Mock 2 fitted, but with only 1.5 hours of float, which is not enough for a real weekend with tired people and a production system. Luis needs contingency: time reserved for things going wrong. A common rule is to plan contingency as a share of the measured duration, agreed by the steering group, and to treat its consumption during the weekend as a key indicator.

Where SUM spends the time

The Software Update Manager (SUM) runs a conversion as a roadmap of main steps: Extraction, Configuration, Checks, Preprocessing, Execution and Postprocessing. The first four run while ECC is still in use: SUM unpacks the target software, takes its parameters (including the number of parallel processes), runs prerequisite checks such as the Simplification Item-Check again, and builds the target repository as a shadow. In phase DOWNCONF_DTTRANS, at the end of preprocessing, SUM asks the last questions before it enters downtime. From that confirmation on, users are locked and the clock of technical downtime is running.

Execution is the technical downtime. Because Contoso's ECC runs on a non-HANA database, SUM uses DMO: in phase EU_CLONE_MIG_DT_RUN it copies the application tables from EP1's database into SAP HANA, then switches to the SAP S/4HANA software and converts the application data into the new data model. SUM's own Postprocessing follows, and only then does the runbook's manual post-processing begin: the finance data migration, follow-on activities and checks. The move from Contoso's data center to the RISE data center also runs inside this path, so network throughput between the sites belongs in every mock measurement.

Three SAP tools help turn runs into an estimate. Before any mock, the Planned Downtime Calculator in the SAP Readiness Check results gives a first breakdown of business downtime by phase, partly from your data volumes and partly from empirical values; you overwrite its figures as soon as you have measurements. After each SUM run, the upgrade analysis file (UPGANA.XML) lists the runtime of every phase. The Technical Downtime Optimization app (SAP Note 2881515) reads those SUM runs to show where technical downtime goes and to simulate what tuning would save. Check what is available for your SUM version and Readiness Check release.