Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Two Major News with SUM 2.0 SP 17

Boris_Rubarth
Product and Topic Expert
Product and Topic Expert
‎2023 May 31 12:05 PM
22,048

Hello SUM fans, this blog is a bit long and full of text, but it's worth reading, as we have great news!

1. Homogeneous option for DMO


SUM 2.0 SP 17 (available as of May 26th 2023) offers a homogeneous option for DMO!

Until now, DMO was always heterogenous: the database type was always changed, for example from DB2 to SAP HANA DB. Now, for the first time, SUM allows a homogeneous migration from SAP HANA DB to SAP HANA DB.

But this comes only for specific cases:

    • Only SAP HANA DB to SAP HANA DB is supported
      (no plan to offer homogeneous DMO for other database types)
    • Only target product SAP S/4HANA is supported
      (target "SAP ERP on SAP HANA" is not supported)
    • Some restrictions apply for schemas and partitioning
      (documented in SAP Note 3296427 on DMO)
    • doDMO and doC are not (yet) supported for homogeneous DMO
      (plan is to support this with a later SUM SP version, maybe SP 18 in October, or later)
      (with SUM 2.0 SP 17, we accept pilot projects for homogenous DMO with doDMO or with doC)

 

1.1. Main Use Case


So, "DMO with system move" allows SAP HANA to SAP HANA migration. The main scenario that benefits from this new feature is the combined conversion & transition:
convert "SAP ERP on SAP HANA DB" to SAP S/4HANA and transition the system to SAP S/4HANA Cloud, private edition (or any hyperscaler) in one step.

Up to now, this was a 2-step approach:


Now, it is a 1-step procedure:


(The illustrations are based on the PCE documentation: Transition Paths | SAP Help Portal)

1.2. Further use case


Another scenario that benefits from this new feature is the transition of an existing SAP S/4HANA (on-prem) system to SAP S/4HANA Cloud, private edition.




    • Either upgrading to higher SAP S/4HANA release
    • Or keeping source product version level, combining it with „DMO without system update“

        • For this, backup/restore or HANA tenant copy is probably the easier approach

        • Keep in mind that with any DMO scenario, the System-ID of the source system will generally be kept


1.3. Minor further use case


The option can also be used purely on-premise for a change of the SAP HANA database during a conversion from SAP ERP on SAP HANA DB to SAP S/4HANA. Like starting SAP ERP on SAP HANA 1.0 and omitting the separate SAP HANA upgrade to SAP HANA 2.0.

1.4. Overview on new scenarios for "DMO with system move"

 


The illustration shows the main use case in the middle, the further use case above, and the minor further use case left hand side with a dotted line. All three cases are listed in orange. The thin blue lines on bottom indicate the already existing use case for "DMO with system move" from non -  SAP HANA DB on source.

1.5. Further information

 

    • SAP Note 3296427 for DMO with SUM 2.0 SP 17
      (sections on "Homogeneous database migration")
    • DMO Guide for SUM 2.0 SP 17
      (sections on "Homogeneous database migration")

 

2. DMOVE2S4: "DMO move to SAP S/4HANA (on hyperscaler)"

 

2.1. Alternative to "DMO with system move"


For the combined conversion & transition, until now only "DMO with system move" was available and used for projects. Disadvantage is that the approach does not allow downtime-optimization techniques like downtime-optimized DMO (doDMO) or downtime-optimized Conversion. Now with SUM 2.0 SP 17, the DMOVE2S4 approach is available as an alternative to "DMO with system move" - under specific conditions (described below). It allows to use the plain-DMO (plain in the sense of "not-DMO-with-system-move") for the conversion and transition to a hyperscaler.

Note: you may have heard about this approach already, but with other names: "DMO to Azure", or "DMO conversion to hyperscaler".

2.2. Advantages

 

    • Proven SUM technology is used
      (not brand new coding)
    • Approach works for source systems on anyDB as well as on SAP HANA DB
      because SUM now allows homogeneous migration (SAP HANA DB to SAP HANA DB, see section 1 above)
    • DMOVE2S4 can be used as is, or additionally with downtime-optimization techniques
      like doDMO, or doC (but currently only if source is on non-SAP HANA DB, see section 1 above)
    • R3load pipe mode is used, not file mode
      so no dump files are created like for "DMO with system move"


So the approach comes with three potential usages / flavors:

    • DMOVE2S4 (plain)
      DMOVE2S4 with downtime-optimized DMO
      DMOVE2S4 with downtime-optimized Conversion

 

2.3. Main steps of approach




    1. Install AAS in target
      In the target environment, in which the target SAP HANA DB is installed, you install an Additional Application Server (AAS) which belongs to the source SAP ERP 6.0.
    2. Extract and start SUM on that AAS
      You start SUM for the conversion on that AAS host in the target environment.
    3. You confirm the "ACSC instance move" offered by SUM
      As SUM detects that it is not running on the Primary Application Server (PAS) host, it offers the ASCS instance move. This will install the ABAP central services on the AAS in the target, and the previous PAS will not be started again after downtime.
    4. Post-activities
      Some post activities are required which are described in the DMO Guide, like moving the directories sapmnt and trans to the hyperscaler.

Although it is not listed here, it is important to enable the required communication between the source and target environment, like opening ports.
The whitepaper "Converting from SAP ERP on Premise to SAP S/4HANA on Microsoft Azure" (listed below) explains those steps in detail, for the case of target hyperscaler MS Azure.

Note that the "ASCS instance move" will move the ASCS instance to a host on which an AAS is running. If the source system had the ASCS running separately from any Application Server Instances, this setup will not be restored by SUM (see blog post  https://blogs.sap.com/2019/04/12/ascs-instance-move-use-sum-to-switch-your-ascs/). It is of course possible to afterwards manually create such a setup. In case of a transition to "SAP S/4HANA Cloud, private edition", the AAS is anyhow installed (by the executing partner) on the "migration server" which is provided by SAP (ECS). After the partner has finished the conversion run, the migration server will anyhow be dismantled.

 

Note on point 1: Install AAS in target [added on June 16 2023]
The OS of the AAS host has to be supported, e.g. for MS SQL database, it must run on Windows. You should check if the target environment supports that OS.

Note on point 3: Confirm "ASCS instance move" [added on July 6 2023]
If your ASCS instance is not yet running separately on your source system, SUM will automatically execute the "ASCS instance split" (see SUM guide: ASCS Instance Split | SAP Help Portal). The new ASCS instance will then be created on the AAS.

2.4. Approach is not a SUM option


Note that the DMOVE2S4 approach is the appropriate combination of SUM features and option, but it is not an option which is offered by SUM. The SUM is not aware if it is used for the approach, and will not show this for example in the title of the browser window. This is different to "DMO with system move" which is a SUM option, and which is shown on the SUM browser page.

2.5. Prerequisites and conditions



    • DMOVE2S4 is only supported for target SAP S/4HANA
    • It is supported if the technical requirements are met (actual values are listed in SAP Note 3296427 on DMO with SUM 2.0 SP 17)

        • Latency < 20 ms

        • Bandwidth > 400 MBit/s



Note: SUM runs a latency check (result is visible in DBSTAT.LOG file). For higher latency values, a warning is shown in log file CHECKS.log. The latency check is executed for conversion with migration and for an SUM "extended prerequisite check" (with target database).

2.6. Further information





2.7. Illustration


The illustration shows both options for a combined conversion & transition.
Note that DMOVE2S4 requires target product SAP S/4HANA, different to "DMO with system move".


So if two options are available, which one to chose?

    • First question is whether the latency and the bandwidth are good enough for DMOVE2S4. If not, then "DMO with system move" is to be used.

        • Only if conditions are met to use DMOVE2S4, then the second question is:
          is downtime optimization required? If yes, then DMOVE2S4 is the right choice.


Boris Rubarth
Product Management SUM, SAP SE

51 Comments
Labels in this area
Popular Blog Posts