S/4HANA Silent Data Migration Infrastructure (Quick Guide)
Currently I am in a S/4HANA 1909 upgrade project (source 1809 system). I have depicted a quick overview for a better understanding, as there were comments on it.
I was curious in trying out the new announced feature called Silent Data Migration Infrastructure (SDMI). It allows you to migrate application data during uptime, that means during that time you can use the system productively. Thereby, the duration of the downtime can be reduced.
Within SUM 2.0 SP6 (PL1) select the following option: Downtime-optimized
Make sure your HANA Database is at least on Release 2.00.042 otherwise SUM will notify you. Also you have to implement two OS Notes in order to use SDMI:
As said before SDMI allows to migrate application data during uptime, but that means it is client dependent and hence needs a technical user in order to accomplish this. Therefore you have to create a so called SDM User either via Transaction SDM_USER (only works for back-end version 7.54 of AS ABAP corresponds to the SAP S/4HANA 1909 release or newer)
or via automatic creating within SUM.
Hint: The technical user must be a system user (type B) and have the profile SAP_ALL assigned.
Further details for SDMI User creation can be found here:
The migration of applications data (in each client) will run in background jobs every 30min (SAP_SDM_EXECUTOR_ONLINE_MIGR) during system uptime, and thus reducing the overall duration of a system downtime.
You can monitor the status of silent data migration using transaction SDM_MON (only works once you are on back-end version 7.54 of AS ABAP or newer).
After a while in the online S/4HANA 1909 system it looks like this:
UPDATE: Recently I was informed about a Simple Finance example, that uses SDMI.
Introducing a new field ACRVALDAT for table ACDOCA: The new field is created empty during SUM upgrade to SAP S/4HANA 1909. Afterwards, business continues as usual – without impact on business processes, and silent data migration fills new field in background (via SDM User).
UPDATE 2: Another Example for SDMI in the Finance area.
The field RAR_VERSION_CODE in table FARR_D_CONTRACT does not yet exist. The new field RAR_VERSION_CODE on contract level indicates whether the contract has been created in a “Revenue Accounting Classic” or in the new “Revenue Accounting” environment. It will be needed (and automatically introduced) in release “On Premise 2020” and it is highly advantageous to introduce and populate it already in current release “On Premise 1909” as a preparation for upgrade to release “On Premise 2020”.
UPDATE 3: Downtime comparison (a rough try)!
I was able gain experience in two similar Upgrades from 1809 FPS2 -> 1909 Release. One scenario used the standard SUM option and the other one was using downtime-optimized plus SDMI enabled.
Although the systems are not exactly the same (db size, languages, available processes, etc.) you can see that downtime optimization can save a lot of downtime (which I will not comment any further)…
In SUM Analysis SAP calls it “Minimum downtime” and you can see the difference. You can learn more about it in the following blog: https://blogs.sap.com/2019/05/27/sum-2.0-post-processing-import-of-additional-software-and-transports/
SUM standard: 7:55h
SUM downtime-optimized: 4:45h