Skip to Content
Technical Articles
Author's profile photo Boris Rubarth

DMO with system move with shd rep on target DB

Readers of this blog post should be familiar with the approach “DMO with system move”, as introduced in this blog https://blogs.sap.com/2017/05/22/dmo-with-system-move-the-use-case-to-change-pas-host-during-dmo/

Shadow repository always created on target database

SUM 2.0 meanwhile creates the shadow repository always on the target database. The approach was introduced in this blog https://blogs.sap.com/2019/09/09/dmo-shadow-repository-on-target-database-for-conversion-to-sap-s4hana-1909/ and is now used for all migration scenarios (with SUM 2.0 SP 08 and higher; but not with SUM 1.0). All migration scenarios means: it is not depending on the target product release, and it is not depending on the target database type. So this approach even applies for a move from SAP ECC 6.0 EHP 7 on SAP MaxDB (on-premise) to SAP ECC 6.0 EHP 8 on SAP HANA DB in a cloud infrastructure like SAP HANA Enterprise Cloud (HEC).

No shadow in source landscape for DMO with system move

For “DMO with system move”, the consequence is that on the source landscape, no shadow operations happen. There is no shadow repository created on the source database, and no shadow instance created on the source Application Server host (on which you have started the SUM).

The following figure illustrates this.

Shadow repository is created on target database

Changes for the approach DMO with system move

This approach (shadow operations only on target landscape) has a couple of implications:

  • SPAU/SPDD happen in target landscape
  • SUM will only allow the specification of the shadow instance number in target landscape (if expert mode is selected)
  • The shadow operations (creating shadow instance, shadow repository, …) happen in target landscape, and not necessarily in uptime – depending on the transfer mode selected, see below
  • Advantage of the approach is that shadow operations do not affect the source database performance

Strong recommendation to use parallel mode

The shadow operations happen on the target landscape, they take quite a while, and the transfer mode decides whether this is uptime or downtime for the source system.

The serial mode:

  • This is the transfer mode in which only one data transfer happens
  • You run the complete procedure on the source landscape until it is finished
  • This includes entering the downtime for the source system
  • Only then you copy the SUM folder from source to target
  • You start the SUM in the target and continue the procedure there
  • Only then the shadow operations run, which takes a while – in downtime!
    [added on Feb 11 2021] Especially phases like these run in downtime then:

    • ACT_UPG
    • SPDD
    • SHD_IMPORT
    • SGEN

The parallel mode:

  • This transfer mode is based on a continuous data transfer to target
  • You run the procedure in source until the dialog on phase HOSTCHANGE_MOVE_SOT
  • On this dialog (still uptime), you decide on parallel mode,
    so you start a synchronization, either manually or using the delivered script
  • Once the initial SUM folder is synchronized to the target, you start the SUM in the target
  • Still in uptime, the target SUM will execute the shadow operations in target
  • You run the source SUM until downtime dialog, but wait there until target SUM has finished shadow operations and is waiting to import dump files (phase EU_CLONE_MIG_DT_IMP)
  • Only then you enter downtime in source, so that creation of export files in source landscape runs parallel to import of dump files into target database

The following figure shows the point in time for which the source system is still in uptime, source SUM waits on downtime dialog (upper left browser window), whereas the target SUM is executing phase EU_CLONE_MIG_DT_IMP which is waiting for dump files to start the import (lower right window).

Parallel%20SUM%20execution%20in%20source%20and%20target

Parallel SUM execution in source and target

Boris Rubarth,
SAP SE, Product Management SUM

Assigned Tags

      42 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Umesh Botwe
      Umesh Botwe

      Hello Boris,

      Thanks very much for providing a very useful information in this blog.

      How do we manually synchronize the dir in parallel data transfer esp when Source and target are on different OS e.g. Source is on HP-UX and target is RHEL.

      Right now SAP has provided a dmosystemmove.sh script but its only for Linux.. can we use custom script for data transfer between different OS? Does SAP support it?

      Thanks,

      Umesh PB

       

       

       

      Author's profile photo Vijay Chandra
      Vijay Chandra

      Based on my experience - you can customize the script.  you need to be careful that you're copying the dump files in proper binary mode and have a method to verify complete copy (MD5 checking, etc).  I say this because I've done similar in the past with my own custom script.  Essentially my team replicated this DMO parallel move with earlier versions of SUM.

      Author's profile photo Boris Rubarth
      Boris Rubarth
      Blog Post Author

      Hi Umesh,

      using the delivered script dmosystemmove.sh should be possible on all operating systems supporting rsync. I am not an expert on rsync, guess all Unix OS should work. For windows, I read that cygwin may be a way to use rsync, but I haven't yet heard of anyone using this.

      Currently azcopy is not supported, as it creates the initial files in the target with final size already which makes SUM assume the file transfer is complete.

      Thank you Vijay to share your experience.

      Regards, Boris

      Author's profile photo Mike Piercy
      Mike Piercy

      Hi Boris, is azcopy now supported?

       

      Thanks Mike

      Author's profile photo Boris Rubarth
      Boris Rubarth
      Blog Post Author

      Hi Mike,

      it is not yet supported. I forgot to mention that the restriction is listed in the respective SAP Note for DMO. So once supported, the restriction will be removed there.

      You find the respective SAP Note on DMO on the landing page for the Software Logistics Toolset: http://support.sap.com/sltoolet, in the section on System Maintenance.

      Thanks,

      Boris

      Author's profile photo Umesh Botwe
      Umesh Botwe

      Thanks Vijay, it helps.

      Meantime, I just tried to manually execute standard dmosystemmove.sh (which internally calls up rsync ) from HP-UX (In the DMO guide it says that this script is for Linux Only) and it works similar to Linux. I feel, only thing you might need to do is to setup the password less authentication e.g. for <sid>adm, between source and target and script would do its job of parallel transfer. I am planning to test this in upcoming  DMO run. Will share the outcome of the same.

      Thanks,

      Umesh B

      Author's profile photo Joydeep Gupta
      Joydeep Gupta

      Hi Boris,

      Our Requirement is to Migrate SAP ABAP System(GRC) running on oracle db to GCP Cloud with HANA as the Target DB.

      Can we use the System Move option? Is it applicable for ABAP Systems other than ECC?

      Source- GRC, Oracle, On-Premise

      Target-GRC,HANA,GCP

       

      Author's profile photo Boris Rubarth
      Boris Rubarth
      Blog Post Author

      Hi Joydeep

      first question is which sources you checked to find the answer. Respective SAP Notes are listed on the landing page http://support.sap.com/sltoolset.
      The SAP Note on DMO with SUM 2.0 (currently SAP Note 2935107) has a section on requirements and restrictions for "DMO with system move". This section does not restrict the products that can be used compared to standard DMO.

      Author's profile photo Antonino Chirico
      Antonino Chirico

      Hello Boris,

      With the system move option and parallel mode transfer, SPDD transaction will be perfomed on target system. In this situation will the source system be down or up ?

      Best regards

      Antonino

      Author's profile photo Boris Rubarth
      Boris Rubarth
      Blog Post Author

      Hello Antonino,

      for the parallel mode, SPDD is done during source system uptime. I have now listed in the blog post relevant phases that run in downtime for the serial mode in blue (they run in uptime for the parallel mode).

      Best regards,

      Boris

      Author's profile photo Andrea Curzola
      Andrea Curzola

      Hi Boris,

      thank you very much for your valuable contribute!

      As far as I know, using parallel mode in a system move approach is only possible from linux to linux; is there an equal solution in a system move between Windows source and Linux as target platform?

       

      Thank you very much!

      Kind regards.

       

      Andrea

      Author's profile photo Boris Rubarth
      Boris Rubarth
      Blog Post Author

      Hi Andrea,

      thanks for asking. Indeed, you can also use the parallel mode if OS for source and target host are different! It is only the delivered script (triggering rsync) that only works from Unix to Unix.

      The parallel mode requires synchronization either by using the script or by manual synchronization. So for manual synchronization, you will copy the SUM folder once, as stated on dialog for phase HOSTCHANGE_MOVE_SOT. Then you can start the SUM on the target host to pass all the shadow operation phases. Once you finish the SUM on the source (dialog for phase HOSTCHANGE_STOP), you do the second (final) copy of relevant SUM folders (stated on the dialog). Downtime is longer compared to using the script, but still much less than using the serial mode.

      There are even possibilities to have a continuous synchronization for the case "windows-to-Unix", but I will update the blog on that once I have details.

      Kind regards, Boris

      Author's profile photo Boris Rubarth
      Boris Rubarth
      Blog Post Author

      Hi Andrea,

      sorry, I meanwhile have to update / correct my comment: for parallel mode with manual synchronization, three sync points are required:

      • Dialog of phase HOSTCHANGE_MOVE_SOT
      • Downtime dialog
      • Dialog of phase HOSTCHANGE_STOP

      Kind regards, Boris

      Author's profile photo Clarisse Sabulao
      Clarisse Sabulao

      Hi Boris,

       

      Is System Move supported for Windows Domain Installation to Windows Local Installation ? I am in the middle of DMO and already did the initial transfer of SUM directory to target PAS. When SUM was started in target, it is performing checks in the Hana DB user store using the Domain SAP Service User of source. Target system is not added to the domain so the check is failing.

       

      Kind regards,

      Clarisse

      Author's profile photo Boris Rubarth
      Boris Rubarth
      Blog Post Author

      Hi Clarisse,

      this is supported. Which SUM version in detail are you using? SUM 2.0 SP xx PL yy

      Kind regards,
      Boris

      Author's profile photo Clarisse Sabulao
      Clarisse Sabulao

      Hi Boris,

       

      It's SUM 1.0 SP26. We are also doing unicode conversion along with the update.

       

      Thanks,

      Clarisse

      Author's profile photo Boris Rubarth
      Boris Rubarth
      Blog Post Author

      Hi Clarisse,

      thanks - I didn't thought about that: although "DMO with system move" is supported for SUM 1.0 as well, the target OS has to be Linux. Please check SAP Note 2882431 for DMO with SUM 1.0 SP 26.

      Regards, Boris

      Author's profile photo Clarisse Sabulao
      Clarisse Sabulao

      Hi Boris,

       

      Thanks, our target PAS OS is Linux. However, OSS note 2882431 was recently updated last month and it has restriction for DMO system move : SAP source systems runs on Windows OS: The target PAS host must run on Windows OS so we have this temporary Windows server just to meet this requirement. We are still waiting for a reply from SAP with regards to the error but might just go ahead and add it to the AD.

      Kind regards,

      Clarisse

       

       

      Author's profile photo Boris Rubarth
      Boris Rubarth
      Blog Post Author

      Hi Clarisse,

      thanks for the information and your patience. Indeed we had an inconsistency in the text of SAP Note 2882431 which will be adapted soon. "Windows to Windows" is supported, and your incident is been worked on.

      Kind regards,
      Boris

      Author's profile photo Radu-Andrei Besnea
      Radu-Andrei Besnea

      Hi Boris Rubarth,

      Thanks for the input provided in SUM tools, excellent as always.

      Quick question - not sure if already discussed or not.

      We are planning to start a brownfield conversion (DMO with System Move) from ECC 6.0 EHP7 on MS/SQL both PAS and DB on Windows towards S/4HANA 2020, PAS and DB on Linux.

      ECC is running now in Azure and we will be moving while converting in a new Azure subscription.

      In this case, do you know by any chance in case of "Parallel mode" option what is the best approach for Data Transfer? We were looking for AzCopy via Azure BLOB Storage or RoboCopy?

      Any clue what is the best approach here?

       

      Thank you in advance.

      Radu

      Author's profile photo Boris Rubarth
      Boris Rubarth
      Blog Post Author

      Hi Radu,

      sorry for the delay. What I know is that we had issues with azcopy, that is why we have listed in the respective SAP Note for DMO that it should not be used. Looks like there is a new version of azcopy available which should overcome the issue (using temporary file names), but I had no chance yet to check this.

      Regards, Boris

      Author's profile photo Basis S4
      Basis S4

      Thanks Boris!

       

      We continued by using robocopy to transfer data and process went fine.

       

      Thanks again!

      Radu

      Author's profile photo Paul Secunde
      Paul Secunde

      Hello Boris,

      One question regarding DMO on Windows servers, which is listed a 'manual sync' with parallel mode.  We perform the initial copy using Windows Explorer of \SUM\abap\load from source to target server and start SUM on the target.  When we perform the second copy when the export is complete from the source in downtime, there are files that were copied on the initial copy that still exist in the target.  Do we overwrite those duplicates in the target server directory or ignore them?

      Thank you,

      Paul

      Author's profile photo Boris Rubarth
      Boris Rubarth
      Blog Post Author

      Hello Paul,

      I understand the situation as follows: on dialog HOSTCHANGE_MOVE_SOT, you have followed the steps (describing the parallel mode with manual sync) and manually copied the complete SUM directory to the target. You have continued the SUM run on the source and started the SUM run on the target in parallel, but without any synchronization (so skipping step 4 of the description).
      You have reached the dialog HOSTCHANGE_STOP in the source, so the export is complete. Now you want to copy the delta to the target, i.e. the abap/load directory.

      Finally the answer 🙂
      it should be irrelevant if you overwrite or ignore the duplicates, ignoring them will take less time.

      Kind regards, Boris

      Author's profile photo Ricardo Fontes
      Ricardo Fontes

      Hi Boris,

      In the HOSTCHANGE_MOVE_SOT phase, the step 5 presented by SUM:

      Synchronize the directory "E:\usr\sap\SID\SUM\abap\load" continuously with the target host until phase "HOSTCHANGE_STOP" has been reached.

      I can to move the files from the source directory to the target? My scenario is windows, i know i cant use the auto copy script which is linux only.

      As files are being created, can we cut from the source and paste in the target? In this way not compromising the source disk space.

      Regards

      Author's profile photo Boris Rubarth
      Boris Rubarth
      Blog Post Author

      Hi Ricardo,

      Looks like you have the same scenario like in my comment above for Paul.
      Concerning your question on cut&paste files from source to target (instead of copy&paste): I would not recommend this approach. You should keep the full folder of the completed SUM directory in the source available. it is required for example in the case that you have to restart the procedure in the target. As described in the guide, a reset in the target does not restore the SUM folder to a state on which you can simply repeat the target procedure (with the current SUM SP version).
      Regards, Boris

      Author's profile photo Kets P
      Kets P

      Hi Boris,

      Nice Blog and I think everyone with the kind of conversion scenario "DMO with System Move" should check this.

      can you please clarify the below scenario whether it is feasible with "DMO with System Move"

      Source Environment (Datacenter1): SAP ECC  + DB (Oracle 11g) on SUN Solaris , here will start SUM tool for S/4HANA conversion in source PAS with parallel mode using delivered script

      Target Environment(Datacenter 2) : SAP S/4HANA on SUSE pre-build PAS & database and then copy and sync the SUM folder to start conversion on target as mentioned in the blog.

      so can you please advise in the above condition with the kind of OS and DB environment is it possible to use this approach or should we go for any other approach.

       

      Regards,

       

      Author's profile photo Boris Rubarth
      Boris Rubarth
      Blog Post Author

      Hi Kets,

      in general "DMO with system move" works for this environment, but you should check the respective SAP Note on DMO for potential restrictions - I am not aware of any. The parallel mode can be used, and assuming that rsync works on SUN Solaris, the script can be used as well.

      Regards, Boris

      Author's profile photo Christian Takeda
      Christian Takeda

      Hi Boris,

      We are planning a system move of an ECC 6.06/DB2 running at IBM to S/4HANA Cloud (Rise), which means, using DMO with system move. Is it possible to do a system and Unicode conversion in one step?

       

      Our customer SAP system is non-unicode, and the customer is avoiding two steps approach.

       

      Thanks

       

      Christian

      Author's profile photo Javier Poot
      Javier Poot

      Hi Christian,

      As per the official S/4H 2020 conversion guide:

      https://help.sap.com/doc/2b87656c4eee4284a5eb8976c0fe88fc/2020/en-US/CONV_OP2020.pdf

      "3.1 System Requirements
      Unicode

      As a prerequisite for the conversion, your system needs to be a Unicode system. If your system is still non-Unicode, you can follow a two-step conversion approach: First, perform a combined upgrade and Unicode conversion with one of the supported start releases as target, then perform the conversion to
      SAP S/4HANA."

      I found the same req. for earlier S/4 versions, so I think it also applies to S/4H Cloud.

      Hope this help

      Best Regard

      Javier

      Author's profile photo Christian Takeda
      Christian Takeda

      Thanks Javier!

      Author's profile photo Boris Rubarth
      Boris Rubarth
      Blog Post Author

      Hi Christian,

      as Javier already stated: the (one-step) conversion to SAP S/4HANA requires the source system to be on Unicode.

      This requirement is valid for targeting SAP S/4HANA (on-premise edition) as well as for targeting SAP S/4HANA Cloud, private edition. [A move to "SAP S/4HANA Cloud" is not supported by a system conversion]. And the requirement is also valid for "DMO with system move". [DMO: database migration option]

      In general, SUM 1.0 is capable to include the Unicode Conversion as part of DMO, but a system conversion is executed with SUM 2.0. The requirement to have the source system on Unicode already (for all target product versions on SAP BASIS 7.50 and higher) was announced by SAP in 20214, and is attached to SAP 2033243 Note "End of non-Unicode Support: Release Details".

      Regards, Boris

      Author's profile photo Christian Takeda
      Christian Takeda

      Thanks Boris, Appreciated your quick feedback.

      Author's profile photo Roby fab
      Roby fab

      Hello Boris,

      Thanks for this blog.

      We are new project "Conversion to SAP S/4HANA" using SUM/DMO + system move

      Source : On-premise ECC6 Ehp5 on SQL Server 2017 on Windows 2012
      Target : SAP Rise: S/4 2020 on Hana 2.0 SLES15

      Could you please clarify the 2 points below

      SAP note 3070443 - Database Migration Option (DMO) of SUM 2.0 SP12

      1/
      "For System Move only: The operating system of the application server on the source host has to be supported for the source SAP release according to PAM.
      The operating system of the application server on the target host has to be supported for the target SAP release according to PAM."

      Source OS, windows 2012 is not supported for target release, but I use option "system move" and the shadow instance run on target OS.
      In this case we can start SUM on source system on windows 2012?

      2/
      "Do not use the AzCopy tool for file transfers when using the parallel mode:
      Instead, we recommend using other file transfer techniques such as ftp, rsync, or the SUM tool internal script based on rsync."

      and previous reponse in this blog
      "
      Boris Rubarth
      March 17, 2021 at 6:48 pm
      There are even possibilities to have a continuous synchronization for the case "windows-to-Unix", but I will update the blog on that once I have details."

      Do you have any news, how to synchronize the SUM repository for the case "windows to Linux"?
      It's supported, no impact with different path ( \\path on windows vs /path on Linux)?

       

      Thanks for your help.

      Regards,

      Roby

      Author's profile photo Boris Rubarth
      Boris Rubarth
      Blog Post Author

      Hello Roby,

      1/ Yes, for "DMO with system move", as stated in the SAP Note text, the source OS does not have to be supported for the target release, as the shadow repository is not created on the source database.

      2/ Let us distinguish two different techniques for the parallel mode: a) manual synchronization and b) synchronization with a script. Both cases are supported even for change of Application-Server-OS (in your case: Windows -> Linux).

      a) For the manual synchronization, the SUM dialog for phase HOSTCHANGE_MOVE_SOT now tells you more explicit the three sync points to use.

      b) Using a script: in your case as source OS is Windows, the script delivered with SUM (dmosystemmove.sh) can't be used (SUM will not display the text box for the target host name on the dialog for HOSTCHANGE_MOVE_SOT). Nevertheless other possibilities exist, such as:

      • b1) Meanwhile the colleagues from Microsoft have released a new version of azcopy. With version 10.10 and higher, the detected issue should not occur any longer (during the transfer, the tool now uses temporary file names). Unfortunately I am not aware of a project that had validated this, that is why we still have the restriction in the SAP Note.
      • b2) Some projects install mingw (https://sourceforge.net/projects/mingw) on their source Windows OS and manually trigger the dmosystemmove.sh script then.

      Regards, Boris

      Author's profile photo Roby fab
      Roby fab

      Hello Boris,

      Thanks a lot for these clarifications.

       

      Regards,

      Roby

      Author's profile photo Vikram Ramanathan
      Vikram Ramanathan

      Boris, SAP community,

      I face the same issue. My source PAS Is windows 2012/MS SQL DB. My Target is Linux/HANA in Azure. I am moving from bw 7.4 to bw 7.5 using SUM DMO. Serial method (export, then ftp, then import) is causing 100+ hour outage. I need to use parallel method and I am having hard time to get rsync to work on windows. When I execute rsync with the ssh option, windows cannot find ssh. Can you point me to the right way to get rsync to work? I also saw the SAP note which says 'do not use azcopy for parallel method'.  I will be most appreciative of any pointers. I have been googling through a lot of blogs but not yet got a solution.

      I have to transfer 1.6 TB of export files to azure and it is taking me 45 hours to copy it over sftp. So I need to try rsync to use the parallel dmo option to reduce the downtime. rsync does not like windows back-shlashes G:\SUM. So I had to install cygwin (linux emulator) but when I use ./rsync /cygdrive <SUM dir path> -ave ssh sidadm:remotehost:/export, I get error "failed to exec ssh". Any thoughts from anyone on how to get rsync with ssh  to work on windows PAS?

      From what you mention above, azcopy using sync option can be used even though the note says 'do not use'?

       

      Author's profile photo Boris Rubarth
      Boris Rubarth
      Blog Post Author

      Hi Vikram,

      sorry to hear that you experienced those hurdles, and sorry for the late comment.

      I have no experience with rsync on Windows, so can't help on that. Hopefully you did at least use the parallel mode with manual synchronization, like explained in my answer above, step 2 a): " ... three sync points to use."

      Regards, Boris

      Author's profile photo Balashchenko Andrei
      Balashchenko Andrei

      Hi Vikram.
      Please read the following brilliant article [1] (see the link below in references). It says SSH can be a bottleneck in rsync (SCP,SFTP) transfer. Also disk subsystem may be limitation at some speeds over 150 MB/s.

      Then you may try using weaker encryption and disabling logging options of rsync as advised in article [2].

      Based on article [1] I considered using either HPN-SSH [4] or BBCP[3]. I evaluated BBCP as this is much simper.

      Working variant for me looks as adopting standard dmosystemmove.sh script to use BBCP. Looks it should optimally saturate every channel. Using portable  HPN-SSH library is also possible [4, 5]. In any case on Windows looks you have to use cygwin or MinGW+MSYS.

       

      I tested this in own data center using commands [6]. But for me  single 2 GB file transfer was little faster with rsync (76 vs 71 MB/s). For multiple files directory they were similar about 99 MB/s.
      Evidently I saturated my 100 MB/s  (1 Gbit/s) data center channel. But I did not reach yet SSH or HDD limit. With longer distances (longer pings) tools should behave differently of course.

      In your case that was (1.6 TB/45 hr) about 10 MB/s. This looks far from HDD speed limitation. SFTP is known for slowness. But not the case.

      Most logical in your case is: your connect to cloud datacenter is simply such a slow. Your organization may have just 100 Mbit/s external internet channel. So maybe ask about temporary leasing a wider internet channel or using channels bonding of wire+LTE/5G (software like Speedify).  But I did not play this this. This is another interesting challenge....

      Also consider using some closest to you cloud data center (or azcopy maybe will do this for you).

      References:
      [1]
      Data Transfer Basics and Best Practices  https://princetonuniversity.github.io/PUbootcamp/sessions/data-transfer-basics/PUBootCamp_20181031_DataTransfer.pdf

      [2] How to speed up rsync? - Super User https://superuser.com/questions/109780/how-to-speed-up-rsync

      [3] Using BBCP http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm

      [4] GitHub - rapier1/openssh-portable: HPN-SSH based on OpenSSH https://github.com/rapier1/openssh-portable
      [5]
      install HPN-patched version of SSH without overriding the system-installed OpenSSH https://gist.github.com/mkll/6e86d27f4b256c3720eb7b73793779d4
      [6] Commands used to test time of transfer:
      time rsync -avm --out-format="FILE=%n" /hana/data/HDB/mnt00001/hdb00001/datavolume_0000.dat root@<target.hostname>:/tmp/trans/
      time /tmp/bbcp -v -4 -P 5 --port 50000:51000 /hana/data/HDB/mnt00001/hdb00001/datavolume_0000.dat root@<target.hostname>:/tmp/trans/

      Author's profile photo Taryck Bensiali
      Taryck Bensiali

      Hi Boris,

       

      Can this approach be used across data center. I mean in a Go to cloud (Azure in our case) scenario ?

      As note 3110934 - Executing and Monitoring Downtime-Optimized Conversion to SAP S/4HANA with SUM 2.0 SP 13 clearly indicates :

      Symptom

      You want to use the Software Update Manager 2.0 for the downtime-optimized conversion to SAP S/4HANA, that is, you want to significantly reduce the technical downtime for the conversion of your SAP system to SAP S/4HANA (on-premise edition).

      Interference with other SUM scenarios

      • "DMO with System Move" is not possible for downtime-optimized conversion
      • Using downtime-optimized Conversion for a migration across data center is not supported (PAS host and DB host in different data center);
        but SAP is currently investigating possibilities and boundaries of combining this, see respective text in SAP Note 3106947, section "General Release Restrictions and Limitations"

      And note 3106947 - Database Migration Option (DMO) of SUM 2.0 SP13

      Indicates

      --------------< Last Update D029945 11/MAY/2020 >---------------------
      a) General Release Restrictions and Limitations

      • DMO keeps the application server stable. This means that you start the SUM tool on a dedicated host on which there is an instance of the application server, and both the instance and the host are not changed during the DMO procedure. The only exception is the scenario "DMO with system move", in which the application server can be changed during the DMO procedure.
        Note that although the option "ASCS instance move" allows you to change the ASCS instance, the application server on which you start the SUM tool is not changed (host and instance).
        However, it is possible to install application servers before or after the DMO procedure. You can switch to them after the SUM with DMO run is completed.
      • Using DMO for a migration across data center is not supported (PAS host and DB host in different data center). There are no technical restrictions, but it comes with a high performance and latency impact. You may use it at your own risk. No support is provided in case of performance issues or broken procedures due to network/latency issues. Consider "DMO with System Move" instead.
        • Note that SAP is currently investigating possibilities and boundaries of using DMO (without "system move" option) for a system conversion to SAP S/4HANA combined with a data center move. We are looking for customer projects as Proof-of-Concept to verify our assumptions. If this may be interesting for your project, contact us by creating an incident on component BC-UPG-TLS-TLA with title "Registration for conversion with data center move". Specify the source database size, rough timeline, and locations of source and target environments.
        • If you move to hyperscaler Microsoft Azure, you may check the whitepaper "Converting from SAP ERP on Premise to SAP S/4HANA on Microsoft Azure" published at https://www.sap.com/documents/2021/12/a8fcb608-097e-0010-bca6-c68f7e60039b.html.
      • Product Version SAP NW AS for ABAP 7.51 Innovation Package is not offered as possible target release for the DMO scenario.
        (Note that this limitation does not apply for the system conversion to SAP S/4HANA 1610, because SAP S/4HANA 1610 is based on software component SAP_BASIS 751  and not on this specific SAP NetWeaver product version SAP NW AS for ABAP 7.51 IP.)
      • Product Version SAP NW AS for ABAP 7.52 is not offered as possible target release for the DMO scenario.
        (Note that this limitation does not apply for the system conversion to SAP S/4HANA 1709, because SAP S/4HANA 1709 is based on software component SAP_BASIS 752  and not on this specific SAP NetWeaver product version SAP NW AS for ABAP 7.52.)

      ----------------< Update D029945 11/OCT/2021 >--------------------------
      c) "DMO with System Move": Requirements and Restrictions


      Requirements for Source System and Source Database:

      • Source Database: All source databases excluding SAP HANA database
      • Operating System (OS) of source primary application server (PAS) host: Any Unix-based or Windows operating system. In case of an IBM Db2 for i database, the PAS must always run on an IBM i Host.
      • The operating system of the application server on the source host has to be supported for the source SAP release according to PAM. The operating system of the application server on the target host has to be supported for the target SAP release according to PAM.
      • During a "DMO with System Move" run, dump files are created in the SUM folder that contain the contents of source database tables in compressed form. Since the entire source database is exported, make sure that there is enough space available.
      • As of SUM 2.0 SP11, a particular phase checks for left-over data in physical table pools. This means that SAP Note 2930154 no longer needs to be applied before the start of the procedure.

      Requirements for Target System and Target Database:

      • Target Database: SAP HANA and SAP ASE only
      • OS of PAS host: Any Unix-based or Windows operating system

      Restrictions:

      With regard to operating systems:

      If the OS of the source and the target PAS hosts are different, you have the following options:

      • On condition that
        • the phase HOSTCHANGE_MOVE_SOT is finished on the source system
        • you have copied the SUM directory from the source to the target application server (either manually, or using the script provided by the tool)

      extract the SUM archive for the target OS over the target SUM directory to replace the executables.
      Make sure that you use the same SUM version (including patch level) in the source and the target system. You have to consider this already when downloading the SUM archives!

      • As a workaround, install in the source system an additional application server (AAS) that runs on the same OS as the target PAS host. In this way, source OS and target OS are identical.

      With regard to scenarios and applications

      • Migration of SAP SCM with automated LiveCache:
        • Before you start the Software Update Manager, consider the consistency checks of report /SAPAPO/OM_LC_DOWNLOAD_UPLOAD (part A and B) to cleanup inconsistencies.
        • Install the LCAPPS plug-in on the target database for the installation of the database instance in the target system. Make sure that you install the plug-in version that is compatible to SAP HANA database.
        • Note that part A and B of report /SAPAPO/OM_LC_DOWNLOAD_UPLOAD run in the source system, but part C runs in the target system.
        • Note also that due to technical restrictions, part A and B of report /SAPAPO/OM_LC_DOWNLOAD_UPLOAD run in roadmap step "Preprocessing", however only after the explicit decision to enter the downtime. Hence, they run in the SUM technical downtime.
      • Table comparison:

      Checks are only supported if both the source OS on which the SUM is running, and the target platform have the same endianness. See SAP Note 552464 for more information on endianness.

      • "DMO without System Update":
        • You can combine “DMO with System Move” with the approach “DMO without System Update”. However, this is supported for target database SAP HANA only.
        • Implement SAP Note 1903295 in the source system beforehand to prevent an abortion of phase JOB_RS_DMO_HDB_CONTENT_ACTIVATE with error message:
          "Batchjob 'RS_DMO_HDB_CONTENT_ACTIVATE' ... is aborted".

      With regard to SUM tool and systems

      • SUM tool version:

      Make sure that the release version and the patch level of the SUM tools are identical in both the source and the target system. To avoid different tool versions, we recommend to download the same SUM version for both systems, ideally at the same time.

      • Change of the System-ID (SID):

      Not possible.

      • Short host names for source and target PAS:

      They must be different. Otherwise the Software Update Manager does not start on the target system.
      Note that fully qualified domain names are not affected.

      • SAP HANA and SAP NetWeaver AS ABAP on one server (see also SAP Note 1953429):

      The system ID of the database must not be the same as the system ID of the PAS on the source system.

      • SUM on an AAS:

      You may not run the SUM on an AAS if ASCS is not yet running separately (such as during the standard DMO procedure).

      • Resetting the procedure on the target system:

      As of SUM 2.0 SP12, you can now also select the reset function on the SUM user interface in the target system.
      Note: If you use the reset function with the initial delivery of SUM 2.0 SP12 and then start a new SUM run, an error may occur in the INSTANCELIST_SERIAL phase with the following message:
      SYSTEM MANAGER: System without sapcontrol is not allowed.
      To solve the problem, restart the SAP start service manually. A solution is delivered with one of the following patch Level. This text is then adjusted accordingly.

      • Resetting the procedure on the source system:

      This works directly by using the reset option as described in the DMO guide.

      • Support package (SP) version of SUM:

      You need the identical SP and patch level version of SUM in both the source and target system. Pay particular attention to this when you download the SUM archive.

      • Do not use the AzCopy tool for file transfers when using the parallel mode:

      The AzCopy tool creates the target file immediately with the target file size. SUM always uses the file size to check whether the copy process for a file has been completed or not. Therefore, SUM cannot recognize whether the file transfer has also been completed. Instead, we recommend using other file transfer techniques such as ftprsync, or the SUM tool internal script based on rsync.

      So I'm not sure that DMO with System Move is allowed accross data center:

      • In a down time optimized way : I guess not due to note 3110934
      • without any downtime optimization : I guess yes due to note 3106947, but not sure

      Could tell us when the content on this blog applies ?

      • For all system move scenario ?
      • For move across data center ?

      Thanks in advance for your clarifications.

      Author's profile photo Boris Rubarth
      Boris Rubarth
      Blog Post Author

      Hi Taryck,

      thank you for asking, let me try to sort this out.

      1) This blog is about "DMO with system move", the approach to combine a SUM activity (update/upgrade/conversion) with the move to a different data center / from on-prem to a hyperscaler environment. (In particular, it focuses on the SUM approach to create the shadow repository on the target database, but this is not relevant for this discussion.)
      So concerning your question "Can this approach be used across data center ... go to Azure ..." (where I understand <this> as <DMO with system move>), the answer is yes.

      2) You finish your question with the wish to know when the content of the blog applies.
      "DMO with system move" is the term for the SUM approach allowing to

      • change the hardware of PAS application server (move to different host)
      • move the complete system from one data center to a different data center
      • move the system to a hyperscaler environment

      3) In-between, you reference the SAP Note on "downtime-optimized Conversion" (latest version is always referenced on this SAP Support Portal page) stating that this cannot be combined with "DMO with system move". Correct: "DMO with system move" does not allow to apply "downtime-optimized Conversion", neither "downtime-optimized DMO". The downtime optimization that we strongly recommend for "DMO with system move" is to use the parallel mode instead of the serial mode, as outlined in this blog post.

      4) We currently evaluate the option to use "DMO to Azure" (~plain DMO) for a combination of system conversion to SAP S/4HANA with the move to a hyperscaler, see my blog post https://blogs.sap.com/2021/12/02/dmo-to-azure-combine-sap-s-4hana-conversion-with-the-move-to-azure-without-dmo-with-system-move/. With that, it would even be possible to allow "downtime-optimized Conversion" or "downtime-optimized DMO".

      As a summary overview:

      Without move:

      • plain DMO
      • "downtime-optimized DMO"
      • "downtime-optimized Conversion (for a system conversion)

      With move:

      • "DMO with system move" (parallel mode as downtime optimization)
      • "DMO to Azure" (for a system conversion) (on request, see blog post),
        optionally with "downtime-optimized DMO" or "downtime-optimized Conversion"

      Hope this long answer helps, not sure if I rather should have created a new blog post instead 🙂

      Regards,
      Boris

       

      Author's profile photo Taryck Bensiali
      Taryck Bensiali

      Thank you so much. Now it's fully clear.

      In our group we had different reading of the documentation now it's perfectly clear.