If your source system isn't yet running on the SAP HANA database, use the database migration option (DMO) of the Software Update Manager to migrate your database to SAP HANA during the conversion.
Software Update Manager performs the conversion of data into the new data structure used by SAP S/4HANA Server. This refers to the automated part of the data conversion.
Transport requests containing objects delivered in this Software Update Manager run have to be released. Nevertheless, all transport requests should be released in order to have a clean development cut.
Starting from this development lock, no changes to the development are possible anymore: no SE11, no SE80, no SNOTE, no importing of transport requests, and so on.
The SPDD modification adjustment has to be performed in the shadow system, if it exists. SPDD takes place at the beginning of the Software Update Manager procedure.
ABAP programs generation takes place during uptime, if selected.
A scale-out is a landscape reorganization. It distributes the SAP HANA database among several hosts.
A scale-up is a partitioning of large tables in the SAP HANA database.
The dialog for partitioning of MATDOC is always displayed, independent of the resulting size of MATDOC.
The Software Update Manager reaches the point of the procedure where downtime is needed. Now the administrator begins the downtime by locking all users, logging out the logged-on users, stopping all batch jobs, stopping all interfaces, and so on. Several additional steps are described in the Software Update Manager guide.
Note
Note
The Software Update Manager needs a backup of the Software Update Manager directory at this point. If there's a problem during downtime that can't be solved, it should be possible not only to restore the database to the point of the beginning of downtime, but also to restore the Software Update Manager directory. Then you can restart the Software Update Manager procedure to the beginning of downtime.
Remember: The content of the database and the content of the Software Update Manager directory have to be aligned.
The downtime migration migrates the application data, customizing data, and user master records. These can be migrated during downtime only, because they would be changed continuously during uptime.
Several statistics and graphs are available from the Software Update Manager UI under More → Utilities.
Note
In the KX_SWITCH phase, the kernel of the PAS is exchanged for a new kernel, connected to the target database.
In the EU_SWITCH phase, the former shadow repository is from now on used as the normal repository.
In the PARCONV_UPG and PARMVNT_APPL_VIEWS phases, the table structures are adapted to the new release.
New standard customizing and new data, delivered by SAP, is imported. The runtime depends, among other things, on the number of clients defined in transaction SCC4 (table T000), and the number of languages in the SAP system.
XPRAS stands for eXecution of PRogrAmS.
AIM stands for After Import Methods.
Here, the data is redesigned to the table structures and needs of the business processes of the new release. For an SAP S/4HANA conversion, it's redesigned to the business processes of SAP S/4HANA Server. The runtime of this phase depends, among other things, on the number of clients, the applications used, the release gap between the old and new release, and the size of the tables that have been redesigned. There are many data changes, especially for an SAP S/4HANA conversion.
Note
The technical downtime is not finished here – only the Software Update Manager technical downtime. Be sure that all users remain locked.
If users log on to the SAP system at this point, they would destroy data, and you would have to reset the Software Update Manager procedure to the beginning of downtime.
The SPAU modification adjustment takes place at the end of the Software Update Manager procedure, still during downtime.
Depending on the individual objects, different options are available.
The Software Update Manager informs you of the start of the cleanup process. At this point, the administrator can log on to the SAP system and start with some of the post-procedure steps.
No users are allowed to log on yet.
What is still missing at this point are the technical post-procedure steps and especially the business-related steps that have to be performed before using the SAP system again.
Consider sending statistical information and feedback to SAP!
The file UPGANA.XML can be used for a subsequent Software Update Manager run to optimize the progress bar.
The file MIGRATE_DT_DUR.XML can be used for a subsequent Software Update Manager run to optimize the data migration for the downtime migration.
Hint
Some important phases are:
RUN_RSDBSCPY clones tables from the original to the shadow repository (not with upgrade and SAP S/4HANA Conversion).
EU_IMPORT_ALL creates the shadow repository from upgrade/conversion media (upgrade and SAP S/4HANA Conversion, only).
EU_CLONE_MIG_SOT_PRP / RUN creates tables for the shadow system on the target database (DMO only).
DIFF* copies customer-specific objects from the original to the shadow repository (upgrade and SAP S/4HANA Conversion, only).
DDIC_UPG imports dictionary objects from the objects in the download directory to the shadow repository.
ACT_UPG activates all ABAP dictionary objects that aren't delivered or activated via the upgrade/conversion media or that have been changed during DDIC_UPG.
PARDIST_ORIG runs the distributor.
TABIM_SHADOW_UPG2 / INC imports non-dictionary objects from the download directory to the shadow repository, and copies upgrade and language data from the download directory – but only if it's inserted into new tables.
RUN_SGEN_GENER8 runs SGEN, if selected.
EU_CLONE_MIG_DT_PRP / CREATE performs migration preparation steps, for example, table creation (DMO only).
DOWNCONF_DTTRANS is the beginning of downtime and changes profiles.
EU_CLONE_MIG_DT_RUN performs the downtime migration (DMO only).
KX_SWITCH switches to the new kernel.
EU_SWITCH switches to the new repository.
PARCONV_UPG converts application tables.
PARMVNT_APPL_VIEWS moves the nametab of application tables.
TABIM_UPG imports upgrade and language data from the download directory.
XPRAS_AIMMRG executes XPRAs and AIMs (both are ABAP programs executed to adopt data to the new release) – for an SAP S/4HANA conversion, this is the actual conversion.
The active SAP system (old release) is up and running with its old application servers (PAS and one AAS, in this example), its applications data, and the old repository.
The temporary shadow system (new release) is up and running with the shadow instance, a minimum set of customizing data, and the shadow repository, which is linked to the shadow system.
And at the end of the procedure, the PAS and AAS are switched to the new release. The application data is adopted to the needs of the business functions of the new release. The SAP system will be running with the former shadow repository, which is now the regular repository. The shadow instance will be deleted.
In case of DMO, the shadow repository is created on the target database.
The shadow system is used for SPDD, batch monitoring, and troubleshooting during shadow phases:
DDIC user.
Password copied from a productive SAP system.
Create additional users with transaction SU01.
No access to application tables.
Only basis tables are accessible.
No customizing.
No production operation.
No tp import to shadow system.
No tp mvntabs, no DDL statements.
No online activation and conversion.
Only 'inactive' activation in SE11.
No operations in SE14.
The shadow system allows access to the target release repository during production operation on source release.
Note