Skip to Content
Product Information

DMO: shadow repository on target database for conversion to SAP S/4HANA 1909


SUM creates the shadow repository on the target database for all migration scenarios.
This blog provides background information as well as the current status of this new approach.

Latest News [added on June 10th 2020]

With SUM 2.0 SP 08, the approach “shadow-repository-on-target-database” is used for all migration scenarios, independent on the target release (and independent on target database type). This blog was updated accordingly

Introducing the shadow system and shadow repository

The Software Update Manager (SUM) has several means to reduce the downtime of maintenance events like update/upgrade, database migration, or system conversion. One of these means is the shadow system.
A shadow system basically consists of a shadow instance and a shadow repository:
  • The shadow instance is an additional ABAP instance which is created by SUM on the application server on which the SUM was started. It is used to prepare steps executed during the downtime.
  • The shadow repository exists on target product version level. This means that the shadow instance must use the target kernel to create the shadow repository with potentially new object types.

The shadow system is already created and exists during uptime processing of SUM. As a consequence, the downtime is reduced.

[i] You can check this blog for an introduction to the shadow system, but this description does not cover the migration case.

Until SUM 2.0 SP 07, SUM created the shadow repository on the source database specifically for the migration scenarios Database Migration Option (DMO), and System Conversion to SAP S/4HANA for source systems with no SAP HANA database. (Note that non-migration scenarios have only one database, so that is no differentiation of source and target database is needed.)

This has changed for a system conversion to SAP S/4HANA 1909 with SUM 2.0 SP 06 (and higher): SUM creates the shadow repository on the target database. (Again: This only applies if the source system is not yet on SAP HANA database and a database migration happens. Only then we have a source and a target database).


The figure illustrates:

  • SHD REP: the shadow repository
  • PAS: the primary application server
  • PRD REP: the current (productive) repository of the source system

SAP S/4HANA 1909 and the ABAP kernel

SAP S/4HANA 1909 uses SAP kernel 7.77. This kernel version works exclusively with SAP HANA as database. As the shadow instance must use the target kernel, it is obvious that the shadow instance for SAP S/4HANA 1909 can’t work with a database other than SAP HANA DB. That is the reason why SUM has to create the shadow repository on the target database for a migration scenario targeting SAP S/4HANA 1909.

Note: SAP Kernel 7.73 as well only supports SAP HANA as database, but it can be used for the shadow repository on source db in the conversion process targeting SAP S/4HANA 1809.

No changes for SUM handling

If you have used SUM 2.0 for a system conversion before, you will not experience any difference in the dialogs concerning the shadow system handling with SUM 2.0 SP 06. So, there is no user choice or parameter on the shadow system creation – SUM will simply do what is required.

(There is a new dialog sequence introduced with SUM 2.0 SP 06 – described in this blog – but this is not related to the shadow system.)

Advantages for conversions to S/4HANA 1909

The shadow repository created on the source system was the reason for some migration requirements concerning the source database. As an example, Oracle 11.2 database on source systems had to be upgraded to version 12 prior to the conversion run (or NZDT had to be used). And in some cases, it was required to extend the tablespace of the source database to create shadow repository. These requirements are now obsolete, when the shadow repository is no longer created on the source database. Good news!

Additional aspects of the story

SUM 2.0 SP 06 is the first SP version of the tool that uses the shadow repository on the target database – but not for all possible cases. Let me clarify some aspects and typical questions:
  • The requirement for a system conversion to have the source system on Unicode remains!
    • This was announced long ago (see announcement), so SUM 2.0 does not cover the Unicode conversion, and will neither in the future.
  • The conversion planning in Maintenance Planner still requires selecting both new kernels, for source and for target database.
  • SUM 2.0 SP 06 and SP 07 use the shadow repository on the target database only for a conversion to SAP S/4HANA 1909.
  • SUM 2.0 SP 08 and higher uses the same approach now for all migration scenarios
    (also for the use of SUM 2.0 SP 08 inside the classical SAP Business Suite, e.g. for the migration of SAP ECC 6.0 from a non-HANA database to EHP 8 on SAP HANA DB).

Boris Rubarth
Product Manager SUM

You must be Logged on to comment or reply to a post.
  • Thanks Boris !! This is amazing, this cuts down lots of effort during source system preparation in a conversion project. On the other hand, DMO with system move is a restriction gives me a frown face. Can you please share a rationale for this?



    Prithivi Raj

    • Hi Prithivi,

      up to now, "DMO with system move" had created the shadow repository on the source system landscape. This is no longer possible, as we can't assume to have a connection to the target (SAP HANA) database from the source landscape. The approach is more complex to be switched.

      Regards, Boris

  • Nice read, also for me as a non-basis person.

    So far, as an ABPAer, my contact with shadow instances is that during upgrade, there might be some  PARDIST_SHD DISTRIBUTION ERRORS, fellow basis-person will let me know,

    and I'll AdT into the shadow instance to activate some CDS-views.


    • Hi Joachim,

      good part of the story is that connecting to the shadow system does not change. It uses the shadow instance, and their location does not change.

      Best, Boris

  • Thanks Boris. This is great feature indeed! since lots of customers has lesser resource on source system and you know source is going away, no sense to add resources... This is Amazing!!  Thank you again , Amit Lal

  • Hello Boris


    Thank you for a great blog.

    We are thinking of migrating to S4HANA/ Azure/ RHEL

    from ECC6.0 EHP6.0/Oracle 11.2/On-premise/RHEL.


    Reading youre previous blogs and sap notes, i know that for my above scenario, i need to use DMO with system move option and system update option.

    So if from SUM SP06, system move option is not supported (when SP06 is great creating the shadow rep on target), then we dont have choice to go like below??


    //Use SUM 2.0 SP05, go to S4HANA 1809 on Azure with system move option and afterwards update to 1909??


    Can we use normal DMO when going from onpremise to Azure cloud, so that we can use SUM 2.0 SP06??



    • Hi Kotaro,

      thanks for your question.

      • yes, as you state "DMO with system move" is not applicable with SUM 2.0 SP 06 for target SAP S/4HANA 1909
      • yes, you may use SUM 2.0 SP 05 for DMO with system move targeting SAP S/4HANA 1809 on Azure (and do upgrade to 1909 then), but you may as well use SUM 2.0 SP 06 for that, as SP 06 supports DMO with system move if target is not S/4HANA 1909
      • No, plain DMO does not support a data center move or move to cloud (IAAS) as written in the respective SAP note for DMO

      Regards, Boris

      • Hello Boris,

        Thank you so much for an quick and informative reply!

        Understood about your reply!


        Btw, i heard when i was talking on the SAP expert chat that

        from SUM 2.0 SP06, the os of application server of the target system has to be supported for the target SAP release only according to PAM, not also the ap server of source system.

        Is it correct?

        • Hello Kotaro,

          sorry, I guess I did not yet understand your scenario.

          For a normal DMO scenario, the application server host remains, so there is no difference between AppServer of source and AppServer of target system.

          Regards, Boris

  • Hello Boris,

    In case of having HANA 1.0 on source system, will customers continue to have pre-requisite of updating HANA to a compatible DB version of S/4HANA Product (HANA 2.0), ahead of the Conversion Process?

    Can you kindly share if SAP is planning also to extend the possibility of having contemplated scenario below, with this new fancy feature?

     -> Source-> ECC 6.0 EHPxx running on HANA 1.0 SPS12

     -> Target-> S/4 HANA 1909 running on HANA 2.0 SPS4

     Kind Regards,

    Claudio Quina

    • Hi Claudio,

      thanks for asking - the requirement to start on SAP HANA 2.0 (if source is already on SAP HANA database) remains. The SUM never upgrades the source database software level, and this is true for SAP HANA db as well.

      Kind regards,


  • Thank you for your always interesting and helpful articles,

    I am preparing for a conversion from ECC 607 to S/4HANA 1909, my source DB is ORACLE 12.

    From my understanding S/4HANA 1909 is based on ABAP Platform 1909 (SAP_BASIS 7.54), I am reading the note 2798588 - Database Migration Option (DMO) of SUM 2.0 SP06 to understand the prerequisites and found a confusing statement when your target database is HANA:

    Oracle version 11.2 or higher if target SAP_BASIS is 750, or if target SAP_BASIS is 7.54 or higher

    Oracle version 12 or higher if target SAP_BASIS is 751 or higher and lower than 7.54

    Does this mean that my current Oracle version is not supported to run the conversión to S/4HANA 1909?

    Thank you in advance for your comments

    • Hi Jorge,

      sorry to say that I do not understand your concern:

      • Oracle version 11.2 or higher is required for target SAP S/4HANA 1909 (on basis 7.54)
      • You have Oracle 12
      • Oracle 12 is higher than 11.2

      Where is the question?

      Thanks, Boris

  • Hello Boris,

    Thanks for the excellent blog and keeping us updated with the latest features.

    1. When will the System move option supported, any rough timelines.

    2. When can we expect to support 1809 SP02

    3. How much downtime we can save, creating shadow system on the target, any rough estimates.


    Thanks & Regards,

    Deepak Rade

    • Hello Deepak,

      thank you for the feedback.

      Concerning your question:

      1. I assume next year
      2. SAP S/4HANA 1809 is supported with all available FPS
      3. Shadow system is anyhow created during uptime, and the new approach (shadow repository on target database) does not change this.

      Regards, Boris

    • Hello Mahesh,

      sorry to say that we can't provide a GA date yet. We will announce it as soon as we are confident, but it depends on the outcome of the development and validation tests. My personal hope is that it will be somewhere around mid of 2020 or Q3, but let's see.

      Regards, Boris

      • Thanks Boris

        But what options the customer has now when they would like to Migrate to S/4 1909 on SAP HEC.

        1. Do a In place upgrade to 1809 with On Premise and then use Export/Import to move the Database to Cloud on S/41909.
        2. Migrate to 1809 first with system Move to Cloud and then upgrade the system to 1909.

        The customer does not have much downtime and hence both the options seems to be a time consuming. Also the customer wanted to go live in April 2021 and cannot wait until 3rd Quarter for 1909 Support.

        Let me know if there are any other best options with your experience.

        Mahesh Shetty

  • Hello Boris,

    thanks for your blog and to inform us about last development on SUM/DMO.

    I'm in the same scenario of migration of ECC6 Ehp5 to S/4 1909. Without "System move" option it's for me a regression because of old infrastructure Source System.

    As the migration should be done 'in-place", our current infrastructure is on OS (Linux RHEL5), DB (Oracle and Kernel (7.22) infrastructure on the source must be compliante and upgraded with a target system before the beginning of the SUM process. It means new project with downtime, non-regression tests, etc before S/4 migration project...

    "System move" is really a very good approach to migrate smoothly from old infrastructure system.

    Hope this option will come soon because it' becomes an issue for S/4 Migration

    thanks a lot,


    Sacha Gosselin



    • Hello Sacha,

      sorry, my answer took a while ... maybe you have already seen my other replies today concerning this topic:

      Well, we are working on this option (“DMO with system move” for conversion target S/4HANA 1909) to become available in the future. What I can say is that the next SUM 2.0 SP version is expected in June, with the next Software Logistics Toolset - but disclaimer applies: we can't guarantee this delivery date, and we can't promise that the next SP version will allow this option. (But my strong hope is that it becomes true).

  • Hello Boris,

    many thanks for this very informative overview about the DMO procedure for S/4HANA 1909!

    Is there any schedule when the DMO with System Move function will be available?
    This is such a useful feature we don't want to miss for our upcoming S/4Conversion.

    Thanks and best regards

    • Hello Anne,

      thank you for the feedback!

      Well, we are working on the option ("DMO with system move" for conversion target S/4HANA 1909) to become available in the future. What I can say is that the next SUM 2.0 SP version is expected in June, with the next Software Logistics Toolset - but disclaimer applies: we can't guarantee this delivery date, and we can't promise that the next SP version will allow this option. (But my strong hope is that it becomes true).

      Best regards, Boris

  • Dear Boris,

    I am now doing an S/4 HANA 1909 conversion from ECC6.04 on HP-UX IA64 based Oracle 12g Database. The Target S/4HANA 1909 based on Linux platform X_86. SUM SP07.

    System tell me that Shadow system is not allowed in the HPUX for S4 HANA version over 1709. I think that the shadow repository will be created in the HANA server. Do you have any idea on it?


    Best Regards

    Alan Zhu


  • Hi Borris,

    The only place I can seem to find conclusive info on DMO with System Move not being supported for 1909 is with you via this article or answers to other questions in this forum.

    I don't see anything concrete listed in the release notes, restrictions or the latest versions of the SUM and DMO guides for SP06 or SP07 - in fact these guides actively talk about DMO with System Move which I think it what is confusing a lot of people. Is it just me, am I missing a reference somewhere?

    Happy to post this as a separate question if needed or to log a formal note if needed since I have a customer with the same questions and I'm referring them here which is good since you are the SUM product manager 🙂

    Thanks in advance, I find your content very professional and thoughtful.


    • Hi Paul,

      You can find this information in SAP Notes 2798588 - Database Migration Option (DMO) of SUM 2.0 SP06 and 2840346 - Database Migration Option (DMO) of SUM 2.0 SP07

      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
      • "DMO with System Move" is currently not supported for targeting SAP S/4HANA 1909



      Sacha G.


    • Hi Paul,

      thanks for asking, and thanks to Sacha for providing the answer.

      I take this question as an opportunity to advertise our landing page for SUM:

      You find a section with up-to-date information on SUM related scenarios with links to respective SAP Notes, guides, blogs, and a link to a dedicated page on SUM with more information.

      Regards, Boris

      • Hi Sacha & Borris,

        Yes thank you, I see note 2798588 for SUM SP06 was updated on 27 Jan 2020 to contain the info as you pointed out:

        ----------------< Update D029945 27/JAN/2020 >--------------------------

        ... I was using a version of that note just prior to this update which didn't have that info in it so thanks for being on top of it.

        As a side note, I see SUM SP07 is now released and the same restriction around DMO with system move exists as described in note 2840346 - just FYI for anyone reading this now:

        "DMO with System Move" is currently not supported for targeting SAP S/4HANA 1909

        Thanks again Borris for great info and for this community.


        • Hi Paul,

          yes, SUM 2.0 SP 07 is out. Well, I am already eagerly waiting that we have SUM 2.0 SP 08 out. If everything works out well, this may be mid of June (still: not a promise, sigh)

          Regards, Boris

  • Hi,


    We are working on a conversion project converting from ECC6 running on Windows and MSSQL in one datacenter to S/4HANA 1909 hosted in a different datacenter. So initially we planned to use SUM DMO with System Move option, but realized from SAP Note "2840346 - Database Migration Option (DMO) of SUM 2.0 SP07" that this was not an option anymore.


    As we se it we have two options now.

    1. Classic export import to migrate to ECC on HANA in new datacenter, then perform conversion in target environment.
    2. Run SUM DMO with source in one datacenter and target in the other with a VPN tunnel in beetween.

    Do you have any experience creating the shadow system on the target server over a VPN tunnel (WAN link is a  VPN tunnel between the two datacenters)





    • Hi Sveinung,

      I have no experience with that scenario, and in the respective SAP Note on DMO you will find that we do not support the approach to use "plain" DMO for a data center move (read the note to see the full text on that).

      > ... [DMO with system move] was not an option anymore.

      Well, we are working on this option to become available in the future. What I can say is that the next SUM 2.0 SP version is expected in June, with the next Software Logistics Toolset - but disclaimer applies: we can't guarantee this delivery date, and we can't promise that the next SP version will allow this option. (But my strong hope is that it becomes true).

      BR, Boris

  • Hello Boris,

    As always, your blogs are very concrete and informative. Thank you for taking your time out to create blogs to make our lives easier and for replying in a timely manner.

    I am confused with the DMO with System Move with SUM 2.0 SP07. I just want to know if DMO with System Move is supported as of SUM 2.0 SP7 for target SAP S/4 HANA 1909 as the DMO guide actively talks about this option being supported (only it does not mention target as SAP S/4 HANA 1909).

    Would appreciate your answer.




    • Hi Osman,

      thank you for the feedback!

      And thanks for asking, I have updated the blog now concerning the restrictions: "DMO with system move" is not supported with SUM 2.0 SP 07 either - hopefully with SUM 2.0 SP 08 then, but we have to wait for the results of the validation tests.

      Regards, Boris

      • Hello Boris,

        Am I right that downtime-optimized DMO is supported for moving from ERP based on Oracle to S/4 HANA 1909?

        Because note 2840346 - Database Migration Option (DMO) of SUM 2.0 SP07 says:

        Note that System conversions to SAP S/4HANA 1909 are currently not supported

        When note says:

        With SUM 2.0 SP 07, the target SAP S/4HANA 1909 is now supported for "downtime-optimized DMO"


        I believe doDMO IS supported for conversion from ERP to S/4.

        Kind regards,


        • Hello Anton,

          thanks for asking, and sorry for my first reply, which was wrong. We have now updated the respective SAP Note 2840346.

          As you state, “downtime-optimized DMO” is meanwhile supported for a system conversion to SAP S/4HANA, even for target version 1909. Still the questions is whether it is worth the effort: I guess that the migration of selected large application tables (which are not affected by the new data model of S/4HANA) is only a minor portion of the overall downtime. The portion of the FI data migration (executed after SUM is finished) is not reduced by “downtime-optimized DMO”.

          Kind regards, Boris

  • Hi Boris,

    With the release of SUM 2.0 SP08, is the DMO with system move for 1909 possible? It’s not specifically called out as not possible as it was in previous central notes but it’s not specifically listed as supported now. Could you clarify if it’s supported now? Thank you!



  • Hi Boris,

    thanks for updating this blog post.

    I have read that it is possible to perform an S4HANA Conversion to 1909 with option “DMO with System Move”, as per SUM 2.0 SP08 enhancement.

    In the related SAP Note 2882441 – Database Migration Option (DMO) of SUM 2.0 SP08 this is not stated explicitly. It seems that there is no more this constraint just because it's not stated in paragraph “c) “DMO with System Move”: Requirements and Restrictions” as stated in previous DMO version notes.

    Have I interpreted well?



  • Hi Boris,


    in the most recent version of the SUM SP08 note:2882441 is mentioned that the system move option is not valid:

    "--------------------< D023536 17/AUG/2020 >------------------------------
    Do not use System Move option until further notice!
    Currently, too few objects are shown in the modification adjustment in transactions SPDD or SPAU. Therefore, do not use DMO with System Move until further notice!
    As soon as this issue is fixed, this note will be updated accordingly by removing this entry. "


    Can you add any further information on this topic and maybe another option for moving the application server and ASCS from a windows Server to a new linux server within the context of a S/4HANA Conversion?


    thanks and kind regards,


  • Hi Boris,

    thanks again to share informations about last evolution on DMO. I’m little confused with the new “SUM/DMO with system move” and the fact that the Shadow system is now on the target system.

    Before the shadow phase was during uptime and was not impacting the business downtime. Now the shadow (and SPDD stop with “double check” because SPDD transport order done on Dév is not fully compliant with the SPDD in next systems) is done during business downtime.

    It is impacting production golive cut-over: new stop during the procedure and we need development people during the go-live and it could be lost of time if something go wrong at this phase

    I understand that sometimes the OS level on the source system can’t support the shadow (and SUM tool) system but we have the option to run SUM on AAS with good OS prerequisites so I don’t understand why it’s better to move the shadow phase during the downtime instead the uptime which was transparent for business.

    I know also SAP best pratices and we have to make dry-runs with production data copy but in real life it’s not always possible. The fact that shadow phase was during uptime was stressless and easier to manage with dev/business teams.

    My 2 cents ?


    It seems that with "parallel mode" the shadow activities can be start on the target before the end of data export on the source. It's save time for this part




    • Hi Sacha,

      thanks for asking and for pointing this out: with the new SUM approach of creating the shadow repository on target database (for all migration scenarios), for "DMO with system move" it is essential to use the parallel mode. Only with the parallel mode, the shadow operation activities in the target landscape are executed during uptime of the source system.



  • Hi Boris,


    in the provided picture it seems that shadow instace is always created on PAS source host. What about if the scenario is SUM/DMO with system move and parallel data transfer?

    In this case, shadow operation will be performed on source or target host? As per SUM conversion guide, it seems on target host, but we are not so sure.


    • Hi Alessandro,

      thanks for asking. For "DMO with system move", the shadow instance only exists in the target landscape (on the target AppServer host). Shadow operations happen in target landscape, and only for the parallel mode, this is uptime for the source SAP system.

      Regards, Boris


  • Hi Boris

    I have doubt for Database migration using Downtime-optimized DMO.

    >Downtime optimized DMO option is  available in SUM 1.0 SP26 or not because in my scenario target  system release in SAP NetWeaver 740 and want to migrate database only. I have read the SUM 1.0 guide and not found Downtime-optimized DMO option.

    > So in this scenario can we use DMO 2.0 with target system SAP NetWeaver 740 only for DB Migration.


    zahid hussain




    • Hi Zahid Hussain / Manoj Dusad,

      indeed downtime-optimized DMO is only supported when using SUM 2.0, so not for a target based on 7.40.

      Regards, Boris

  • HI Boris,

    Many thanks for keeping us updated on all latest features with SUM DMO. As you know in earlier releases of SUM(be it 1.0 or 2.0<SUM 2.0 SP06, it used to create shadow repository on source db which gets copied to target via pipe mode using parallel R3loads. Same is the case for application data in downtime.
    With latest SUM(>=SUM 2.0 sp08), it creates shadow repository on target db avoiding uptime migration. Since we dont have target release kernel for source db, how the application data gets migrated to target hana db? How the connection happens between source db and target db for the transfer of appliaction data?

    Mohamed Sadiqulla.

    • Hi Mohamed,

      the migration of application data works as before: SUM delivers the R3load as part of the SUM archive, and SUM starts several R3load pairs that work on "buckets" (work packages) using pipe mode, as you already stated.



      • HI Boris,

        Thanks for updating. So you mean SUM delivers whole kernel or just R3loads to copy application data. Other questions include

        1. SUM delivers latest kernel or just R3oads? and they are for source db?
        2. While generating stack file for SUM-DMO, we usually choose 2 kernels( one is for source db and other for target db). NOw since shadow rep is built on target, are we supposed to select latest kernel for source db?


        Mohamed Sadiqulla.