S/4 1909 Conversion

[former_member655349]

Hi Boris,

Thanks for the DMO and conversion blogs.

will you please give us some idea about the following scenario.

if we have source system OS which does not support S/4 1909 product and S/4 1909 does not supports the DMO system move option, Then which approach should we follow to do migration from from EHP6 to S/4 1909 and how kernel switch will happen.

Our source system is EHP 6 ECC6 with SUSE11 OS and want to do conversion to S/4 1909 OS SUSE 14 at cloud.

waiting for you early response. 🙂

Thanks,

Tushar

[Boris_Rubarth]

Hi Tushar,

just wanted to notify you and everyone else that the scenario "DMO with system move" for conversion target SAP S/4HANA 1909 is now supported with SUM 2.0 SP 08.

Regards, Boris

[jbuttjer1]

Hi Boris. If I recall correctly, as of SUM 2.0 SP06 and higher, SAP changed the default method to creating the shadow instance on the target, AND using pipes to transfer the data between source and target instead of files. This is great in concept for minimizing downtime by doing a majority of the work, over days if necessary, while the system is still available.

However, in practice, I think it needs help. In the now increasingly popular scenario like the gentleman's above, and in a recent POC, his S/4 target is on a cloud (which one doesn't matter). In our similar case, using SUM 2.0 SP09, with an S/4 1909 release target in AWS, we saw terrible transfer rate over a high speed connection. Our problem was not CPU, or bandwidth. It wasn't parallel threads. We FTP'ed a big file with expected and fast performance.

I think the issue comes down to this: while we can either let SUM automagically calculate the number of processes to use or set them ourselves, it doesn't appear we can set the "package size" of the chunks to be transferred and take advantage of the bandwidth available. This is odd because elsewhere in SAP, like BW extracts from ECC, or OS/DB migrations with export/import, we could set the package size based on our needs and resources (and constraints). This caused what should take hours or a day to transfer to take days into weeks because it was basically throwing sand instead of rocks of data.

Our workaround was to relocate the S/4 target to on-prem to reduce the latency penalty of moving many small packets (was 20-40 ms to cloud, now 1ms). Then we'll do a HANA backup/restore to the host on cloud. Any thoughts on this?

[Boris_Rubarth]

Hi Jim,

1) Yes, it is actually since SUM 2.0 SP 08 that for any migration scenario, SUM will create the shadow repository on the target database. (For all migration scenarios, independent on target release and independent on target database type.) It was initially only introduced for specific scenarios, but is used now in general, mentioned in the following blog post: https://blogs.sap.com/2019/09/09/dmo-shadow-repository-on-target-database-for-conversion-to-sap-s4ha...

2) No, the concept of DMO to use pipe mode for the data transfer between the R3load exporting from source db to the R3load importing to target db was used from the beginning, so no news on that. This was already mentioned in the early blog post on DMO technical background https://blogs.sap.com/2014/03/10/dmo-technical-procedure/

3) You actual topic is the move from on-premise to cloud (IAAS). Plain DMO is not supported for this scenario, as listed in the respective SAP Note for DMO (currently SAP Note 2976921 for DMO using SUM 2.0 SP 10, latest note is always listed in http://support.sap.com/sltoolset). Instead, "DMO with system move" can be used, as described in the DMO guide, and in the blog post https://blogs.sap.com/2017/05/22/dmo-with-system-move-the-use-case-to-change-pas-host-during-dmo/

Regards, Boris