In this blog, I wish to give high-level technical details on the new features available with SUM2.0 SP17.
- Homogeneous DMO
- DMOVE2S4
For those looking for quick details, below is a simple explanation in my own words in this regard.
- DMOVE2S4:(Available since SUM2.0SP17)
- DMOVE2S4 is a way to move/convert SAP on anyDB to S/4HANA system or S/4HANA foundation along with a move to cloud (public-AWS,Azure,GCP etc or private cloud) WITHOUT using ‘DMO with SYSTEM MOVE’.
- This uses Standard DMO as a base and must be triggered from a new AAS that must be installed in the target cloud connecting to source DB. We must ensure that the latency between the source and the AAS in the target hyper-scaler is 20ms with a minimum bandwidth of 400Mbit/s
- During the DMO run, we must also be moving the ASCS to target cloud using SUM standard dialog “I want the ASCS instance move during the SUM run”.
- SUM does not provide any explicit dialog for this option
- Homogeneous DMO:(Available since SUM2.0SP17)
- Homogeneous DMO is a way to move/convert SAP ABAP systems running on HANA 1.0 (Minimum source release 1.00.122.05 ) to target system S/4HANA or S/4HANA Foundation-based systems on HANA2.0
- This is not valid for scale-out systems or SAP BW systems or SAP BW/HANA systems
- As a part of this migration, only db-assigned ABAP schemas and HDI schemas are migrated. Remaining schemas like the one created for SLT or any other purposes must be migrated manually
- In simpler terms, when we use DMOVE2S4 type migration for HANA-based source systems to migrate to S/4 HANA or S/4 HANA foundation, it is called Homogeneous DMO
- Until earlier releases, if one have to perform a upgrade and migration of a SAP S/4HANA system from on-premise to cloud, there was always a need for a 2-step approach. Ie, Migration to cloud followed by upgrade or vice-versa. With the new approach, this 2 step approach is no longer required
Now, getting into further details;
As there are detailed list of information available from various source URLs specified at the end, this blog has been designed in Q&A format which aims at summarizing key details from different public sources.
Key questions that will be answered with this blog are: A.Homogeneous DMO: 1. What is a Homogeneous DMO for HANA? 2. What are the key restrictions involved with Homogeneous DMO migration? 3. What are the supported target for Homogeneous DMO for HANA? 4. High-level details of Homogeneous DMO: B.DMOVE2S4: “DMO move to SAP S/4HANA (on hyperscaler)" 1. What is DMOV2S4? 2. What are the difference between DMOV2S4 Vs DMO with system move? 3. What option in SUM must be used to choose this method? 4. With DMOV2S4, are there any changes to SI or readiness checks? 5. What are the supported target for DMOV2S4? 6. What are the detailed technical steps involved with DMOV2S4? 7. What are the list of ports that must be opened between the source and target cloud? 8. What are the advantages of DMOVE2S4 against DMO with system move? 9. What are the restrictions involved with DMOV2S4? 10.How to determine the latency and bandwidth between the source and target (Hyperscaler)?
A.Homogeneous DMO
1. What is a Homogeneous DMO for HANA?
Starting from SUM2.0 SP17, SUM DMO newly supports one-step conversion/upgrade and migration of a source system that is already running on HANA (at least 1.00.122.05) to a target system S/4HANA system or systems running on S/4HANA foundation on HANA 2.0 (on-premise or private edition). However, one must keep in mind that this does not support SAP BW or BW/4HANA as a source system. Also, scale-out scenarios are not supported.
NOTE: It only supports SAP HANA as source DB
2. What are the key restrictions involved with Homogeneous DMO migration?
- As specified earlier, this does not support SAP BW or SAP BW/HANA or scale-out systems.
- Homogeneous DMO will only migrate database-assigned ABAP schemas and HDI schemas. Any other schemas that are manually created (eg for SLT) will not be migrated.
- Downtime-optimized functions for an SAP ECC source system running on an SAP HANA database are currently not yet supported as on date.
3. What are the supported target for Homogeneous DMO for HANA?
Supported source systems:
- SAP for Banking
- SAP ERP
- Systems based on SAP NetWeaver ABAP
- SAP S/4HANA
Note: SAP BW or SAP BW/4HANA systems are not supported
Supported target systems
- SAP S/4HANA (on-premise deployment)
- SAP S/4HANA Cloud, private edition
- Systems based on SAP S/4HANA Foundation
4.High-level details of Homogeneous DMO:
As specified at the beginning of the blog , when we use DMOVE2S4 type migration for HANA-based source systems to migrate to S/4 HANA or S/4 HANA foundation, it is called Homogeneous DMO.
The technical steps for Homogeneous DMO are the same as DMOVE2S4 except for the fact that the source system here must be HANA only. Please refer Q.”5. What are the detailed technical steps involved with DMOV2S4?” in section B for more details
Source Link:https://help.sap.com/docs/SLTOOLSET/7d57e56e12104cc68bce7646cd9f4cbf/6024534f272d477dbcd09fd612385ee9.html
NOTE: As indicated , this procedure uses ‘STANDARD DMO’ rather than ‘DMO with System move’
Please refer help.sap.com link specified above for more details.
==========================================================================
B.DMOVE2S4: “DMO move to SAP S/4HANA (on hyperscaler)”
1. What is DMOV2S4?
Since SUM 2.0 SP17, a single-step conversion and transition from an on-premise SAP ECC to S/4HANA hosted on cloud is now possible. This method uses the standard DMO functionality against the earlier approach of DMO with a system move. However, there are certain restrictions that must be met with respect to network bandwidth and latency between source DC and target cloud during the execution of this procedure.
2. What are the differences between DMOV2S4 Vs DMO with system move?
In the case of a normal DMO with system move, the first part of DMO execution runs on the source PAS and the final part of DMO runs on the target.
In DMOV2S4:
Step 1: We install an additional AAS for the source system in the target cloud. Also, source ASCS must be moved to the target hyper-scaler during the DMO run. However, both of these tasks do not involve any special option or tasks that standard SUM option has recently introduced.
Step 2:.SUM must be triggered from this newly installed AAS hosted on the target hyperscaler.
Step 3: For ASCS move, the normal ASCS move option dialog in standard DMO will be used to move the ASCS to the target cloud.SUM prompts with this dialog as soon as it detects that SUM is running on an AAS that does not have an active central service.
Step 4:Post standard DMO execution, we will have to transfer the shared filesystem (/sapmnt/<SID> and /usr/sap/trans to the target cloud manually. We will also have to adjust RFCs, printers etc like any other normal migration post steps
NOTE:DMOV2S4 also opens the gate for downtime optimization features such as downtime-optimized DMO or downtime-optimized conversion for the move to hyperscaler except for SAP ECC systems that are already running on HANA.
3. What option in SUM must be used to choose this method?
As specified earlier, SUM 2,0 SP17 has not added any specific dialog for this use case or on the user interface as this is almost similar to standard DMO but with AAS and ASCS to be running on the target cloud
4. With DMOV2S4, are there any changes to SI or readiness checks?
No. Normal application-specific preparation for DMO with system move is also applicable here.
5. What are the supported target for DMOV2S4?
Below are the list of supported target for DMOV2S4
- SAP S/4HANA (on-premise deployment)
- SAP S/4HANA Cloud, private edition
- SAP systems based on SAP S/4HANA Foundation
6. What are the detailed technical steps involved with DMOV2S4?
The below diagram is from help. sap.com indicating the sequence of involved steps.
Assume we have a SID with ‘ABC’ on anyDB in on-premise that must be migrated to Azure, then below are the tasks
1.Ensure that source system meets all the prerequisites for a S/4 conversion
2.Share the required shared file systems such as /sapmnt/ABC and /usr/sap/trans etc between source and target in Azure. Also, ensure that the clocks in both source and target are in sync and in same time zone
3.Open the ports as specified in the Q.‘6.What are the list of ports that must be opened between the source and target cloud’
4.Install an additional AAS in target cloud for the SID ABC running in on-premise.
5.Install target HANA DB in target cloud
6.Start the SUM on AAS that was installed in step 4
7.During the SUM run, SUM detects that it is running on a server which is does not have a central services and hence provides a prompt to check if the ASCS must be moved. We will have to choose yes ,so that this ASCS gets moved to Azure as a part of this migration
8.SUM moves the ASCS to the additional application server instance, which then becomes the new primary application server
9. Migration/conversion gets completed with the end of SUM DMO execution phase
10. As a part of post-steps, perform the below tasks
a.Move directories /sapmnt and /usr/sap/trans to Azure
b.Fix connections with respect to RFCs, printers etc
c. Application-specific post steps
d.Backup and monitoring must be reconfigured
NOTE: if your target cloud is Azure, you will be able to find in-depth details on the same in below white paper.
https://www.sap.com/documents/2021/12/a8fcb608-097e-0010-bca6-c68f7e60039b.html
7. What are the list of ports that must be opened between the source and target cloud?
SOURCE:https://www.sap.com/documents/2021/12/a8fcb608-097e-0010-bca6-c68f7e60039b.html
8. What are the advantages of DMOVE2S4 against DMO with system move?
1.No export of source DB to the file system
2.SAP S/4HANA conversion “on-the-fly”
3. Downtime-optimized capabilities such as downtime-optimized DMO and downtime-optimized conversion
4. Based on the requirement, the RAM/CPU of new AAS in cloud can be chosen which can be then downsized post-migration .
9.What are the restrictions involved with DMOV2S4?
DMOV2S4 only supports,
a.Target applications as S/4HANA (on-premise or private edition) or products based on S/4HANa foundation
b.Latency between the source and the AAS in the target hyperscaler must be 20ms; A minimum bandwidth of 400Mbit/s is required. If this restriction is not met, it is recommended to use DMO with system move.
c.Along with this, all the other restrictions of standard DMO are still valid. Eg:no change in SID
10. How to determine the latency and bandwidth between the source and target (Hyperscaler)?
a.As a part of standard DMO, SUM performs a latency check and writes the result to the DBSTAT.LOG file. If the latency is too high, a warning is additionally written to the CHECKS.LOG file.
b.We can also use network tools like iPerf to check that the network connection is sufficient.
c.The benchmark migration tool for DMO can also be used to test the transfer rate and network quality from the source database to the additional application server host in the hyperscaler. . The benchmarking mode Benchmark export (discarding data) is sufficient for this test. For more information, see Benchmarking the Migration: Export Mode
SOURCES:
https://www.sap.com/documents/2021/12/a8fcb608-097e-0010-bca6-c68f7e60039b.html
