With SUM 2.0 SP 10 and higher, the approach is no longer in pilot phase. This page provides an introduction.
The approach is based on the idea to move downtime activities (like data conversion from old to new data model) and database migration (in case of source system on non-HANA database) to uptime processing of SUM. For a standard conversion, the FIN data conversion has to be executed after the SUM has finished, by respective IMG activities (e.g. FIN customizing, FIN data migration). The downtime-optimized approach will even move the FIN data migration (partly) into the SUM uptime processing.
Data conversion is moved to uptime processing. If the source system is not yet on SAP HANA database, the database migration of the affected tables is then done in uptime as well, prior to this data conversion. [Affected tables: tables that are part of the old data model of SAP ERP but not part of the new data model of SAP S/4HANA – table content has to be converted from old to new table]
In addition, the field conversion for tables KONV and VBFA is moved to uptime processing as well. These two tables remain in the new data model, but fields have to be adapted.
In case the source system is not yet on SAP HANA database, selected large application tables (which are not affected by the new data model) will be migrated by SUM in uptime as well. [This is the approach named Uptime Migration respective downtime-optimized DMO, see https://blogs.sap.com/2014/09/08/dmo-downtime-optimization-by-migrating-app-tables-during-uptime-preview/ ].
The migration and data conversion in uptime happens parallel to end user activities. These activities may change table content that was already migrated and/or converted. SUM considers those changes by using database trigger technology: the changes are recorded and later replayed. The technology which is part of the SUM is used in similar approaches as well, like nZDM and downtime-optimized DMO.
Unlike the standard conversion, this approach will not be used for all systems in your landscape. Typically it is not used for the conversion of the DEV system, as downtime is not that relevant compared to PRD system conversion. Nevertheless, several downtime-optimized runs on copies of PRD will have to be executed.
During the downtime-optimized conversion run, SUM will execute the FIN data conversion partly already in uptime. Prior to this uptime conversion, SUM needs the FIN customizing on the new data model. So prior to the downtime-optimized run, a standard run is required in which the FIN customizing is created, and this customizing has to be put into a customizing transport request. This request will then be provided for the downtime-optimized conversion run.