Freelancers
Cancel
 Sign In
Join Now

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.

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

Tags: Software Logistics Software Logistics - System Maintenance
Sara Sampaio

Sara Sampaio

Author Since: March 10, 2022

0 0 votes
Article Rating
Subscribe
Notify of
0 Comments
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x