Skip to Content
Technical Articles

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

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 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
    • 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 SUM execution in source and target

Boris Rubarth,
SAP SE, Product Management SUM

You must be Logged on to comment or reply to a post.
  • 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 script but its only for Linux.. can we use custom script for data transfer between different OS? Does SAP support it?


    Umesh PB




    • 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.

    • Hi Umesh,

      using the delivered script 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

  • Thanks Vijay, it helps.

    Meantime, I just tried to manually execute standard (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.


    Umesh B

  • 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



    • Hi Joydeep

      first question is which sources you checked to find the answer. Respective SAP Notes are listed on the landing page
      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.

  • 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


    • 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,


  • 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.



    • 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

  • 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,


        • 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

          • 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,




          • 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,

  • 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.


    • 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

  • 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,


    • 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

      • 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.


        • 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