Skip to Content
Product Information
Author's profile photo Boris Rubarth

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

Abstract:

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

Assigned tags

      65 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Prithivi Raj
      Prithivi Raj

      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?

       

      Regards,

      Prithivi Raj

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

      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

      Author's profile photo Joachim Rees
      Joachim Rees

      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.

      Best
      Joachim

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

      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

      Author's profile photo Amit Lal
      Amit Lal

      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

      Author's profile photo Former Member
      Former Member

      Thanks Boris,

      it reduces the efforts of upgrading source DB. will this help in reducing UT_RUN runtime.

      Author's profile photo Kotaro Asako
      Kotaro Asako

      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??

       

      Regards

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

      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

      Author's profile photo Kotaro Asako
      Kotaro Asako

      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?

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

      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

      Author's profile photo Claudio Quina
      Claudio Quina

      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

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

      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,

      Boris

      Author's profile photo Jorge López Enríquez
      Jorge López Enríquez

      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

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

      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

      Author's profile photo Jorge López Enríquez
      Jorge López Enríquez

      Hello Boris,

      Thank you for taking the time to reply. I was confused about the second statement, but I think I was missunderstandig it.

      Thank you again!

      Author's profile photo Siva Kumar
      Siva Kumar

      Hi Boris,

      Oracle 11.2 will support ? if the target conversion is S/4HANA 1909.

       

      Thanks

      Siva

      Author's profile photo Deepak Rade
      Deepak Rade

      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

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

      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

      Author's profile photo Umamaheshwar Muramshetty
      Umamaheshwar Muramshetty

       

      Hello Boris

      Do you have any GA Date for DMO with System move for S4 1909 ? I have a requirement to move one customer from On Premise ECC to S/4 1909 version.

      Mahesh Shetty

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

      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

      Author's profile photo Umamaheshwar Muramshetty
      Umamaheshwar Muramshetty

      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

      Author's profile photo Sacha Gosselin
      Sacha Gosselin

      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 11.2.0.3) 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,

      regards,

      Sacha Gosselin

       

       

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

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

      Author's profile photo Anne Freitag
      Anne Freitag

      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
      Anne

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

      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

      Author's profile photo Gang Huang
      Gang Huang

      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

       

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

      Dear Alan,

      sorry, no idea, hope you meanwhile got help or created an incident.

      Best regards, Boris

      Author's profile photo Aditya Chaudhary
      Aditya Chaudhary

      Hi Alan,

       

      I am performing S/4 Hana Conversion with the same exact setup. Can you please tell how did you approach this situation.

       

      Regards,

       

      Aditya

      Author's profile photo Paul Snyman
      Paul Snyman

      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.

      thanks,
      Paul

      Author's profile photo Sacha Gosselin
      Sacha Gosselin

      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

       

      regards,

      Sacha G.

       

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

      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: https://support.sap.com/sltoolset

      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

      Author's profile photo Paul Snyman
      Paul Snyman

      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.

      Regards,
      Paul

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

      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

      Author's profile photo Sveinung Ryland
      Sveinung Ryland

      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)

       

      BR

      Sveinung

       

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

      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

      Author's profile photo Osman Quadri
      Osman Quadri

      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.

       

      Regards,

      Osman

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

      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

      Author's profile photo Anton Gorbachev
      Anton Gorbachev

      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 https://launchpad.support.sap.com/#/notes/2547309 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,

      Anton

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

      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

      Author's profile photo Bryan Parrott
      Bryan Parrott

      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!

      Regards,

      Bryan

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

      HI Bryan,

      thanks for asking: yes, <"DMO with system move" for conversion target SAP S/4HANA 1909> is now supported with SUM 2.0 SP 08, since yesterday.

      We always list the news on support portal pages:

      Regards, Boris

      Author's profile photo Bryan Parrott
      Bryan Parrott

      Thank you, sir! That news makes my life much easier.

      Author's profile photo Sacha Gosselin
      Sacha Gosselin

      Hello Boris,

       

      thanks a lot for the update!

       

      regards,

      Sacha G.

      Author's profile photo Giovanni Longobardi
      Giovanni Longobardi

      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?

      Regards,

      Giovanni

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

      Hi Giovanni,

      correct!

      We have removed the restriction from the respective SAP Note (2882441 for SUM 2.0 SP 08) that was existing up to SUM 2.0 SP 07 (SAP Note 2840346) and we have listed this in the news section on http://support.sap.com/sltoolset. Direct link to the current news is https://support.sap.com/en/tools/software-logistics-tools/sltoolset-news_sps281.html

      Regards, Boris

      Author's profile photo Fabian Wielgusiak
      Fabian Wielgusiak

      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,

      Fabian

      Author's profile photo belhassen etteibi
      belhassen etteibi

      Hi Boris,

      Thanks for updating this post. It was really helpful during the conversion !

       

      Best Regards,

      Belhassen

      Author's profile photo Sacha Gosselin
      Sacha Gosselin

      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 ?

      [UPDATE] 

      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

      regards,

      Sacha

       

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

      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.

      Regards,

      Boris

      Author's profile photo Alessandro Casarico
      Alessandro Casarico

      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.

      Regards

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

      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

       

      Author's profile photo Manoj Dusad
      Manoj Dusad

      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.

      Regards

      zahid hussain

       

       

       

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

      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

      Author's profile photo SAP BASIS
      SAP BASIS

      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?

      Regards,
      Mohamed Sadiqulla.

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

      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.

      Regards,

      Boris

      Author's profile photo SAP BASIS
      SAP BASIS

      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?

      Regards,

      Mohamed Sadiqulla.

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

      Hi Mohamed,

      R3load for source and target is part of the SUM archive (not the kernel). I still recommend to select both kernels in Maintenance Planner, although in midterm I can imagine that only the target kernel will be required.

      Regards,

      Boris

      Author's profile photo Basis S4
      Basis S4

      Hi Boris,

      Thanks for the info provided here, as always.

      Currently we are running an S/4HANA 2020 FPS01 conversion process with the following scenario:

      Source system info: ECC 6.0 EHP7 on MS/SQL 2016 on Windows,kernel 753 (Azure subsciption1)

      Target system info: S/4HANA 2020 on HANA 2.0 revision 55 on Linux, kernel 781(Azure subsc2)

      Info: DMO with System Move from Windows to Linux with parallel export/import procedure

      SUM version used: SUM 2.0 SP10 patch 7

      While running the shadow instance creation process (target environment), we are facing the following error, which is also described in SAP Note:

      RabaxException<ExcKindRbx_CatalogInconsistency> thrown: DDIC object <object_name> inconsistent: 'JSON document in DDNTT~FIELDS_DATA is empty'

      https://launchpad.support.sap.com/#/notes/0003067758

      Seems that there might be bug in the SUM 2.0 SP10 version which influenced the export of shadow repository to be done with R3load for kernel 7.53 instead of copying R3load for kernel 7.81. Basically SUM is not able to switch automatically the R3* executables from bin_781 to bin, before shadow instance creation, therefore we got in the situation described in the note above (https://launchpad.support.sap.com/#/notes/0003067758). To patch kernel in the source system to 781 upfront I would say is not an option as kernel 781 is not supported with Netweaver 7.4 according to PAM. Note was released last week.

      Due to the above, we have decided to reset the process today and start again from the scratch the process by using SUM 2.0 SP11 patch 0, released 2 days ago.

      Could you please check internally if the new SUM version (2.0 SP11) will overpass the current issue? Are there any manual steps required?

      If needed, please forward the above interpretation to your colleagues.

      SAP incident raised: 451892 / 2021

      Thanks in advance, Boris!

       

      Radu

      Author's profile photo AMIT Lal
      AMIT Lal

      Radu,
      Resetting in upgrade and migration is definitely troublesome at any stage on SUM.
      Just wondering programs such as - /SDF/RC_START_CHECK, didn't capture such misalignments on compatibilities issues esp. on the Kernel side and nametab tables go for a toss. Good Luck with your migration!

      Amit

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

      Hi Amit,

      Simplification Item Checks are checking consistency on application level, not on kernel level. And I would not agree to your statement that "resetting in ... migration is definitely troublesome at any stage on SUM".

      Regards, Boris

      Author's profile photo Basis S4
      Basis S4

      Hi Amit,

      Thanks! On your questions, for SI report did not provided any hints on kernel mismatch or anything.

      Actually the problem came from the fact that SUM while is creating the shadow instance in target is not able to switch automatically from old enqueueserver version ENSA1 (enserver) to new version for SAP ABAP Platforms ENSA2 (enq_server).

      The issue got solved by following SAP note:

      https://launchpad.support.sap.com/#/notes/2754662

      Hopefully in the next version SAP will fix this and issue will dissappear.

      Have a good day!

      Radu

       

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

      Hi Radu,

      glad to read that your issue was solved meanwhile. Just a comment on your previous posting with error details: SUM has its own R3load version on board.

      Regards, Boris

      Author's profile photo Basis S4
      Basis S4

      Hi Boris Rubarth ,

       

      Indeed, thanks, it was a communication issue from my side.

      Nevertheless it seems that SUM 2.0 SP10 or 11 is still not able to switch enqueue symbolic links from old en_server (ENSA 1.0) to enqserver (ENSA 2.0) automatically while starting shadow instance.

      Manual changes are required by adjusting the shadow instance profiles using SAP note: https://launchpad.support.sap.com/#/notes/2754662

      Is it something planned to be fixed in the new SUM versions?

      Thanks,

      Radu

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

      Hi Radu,

      patch level 1 for SUM 2.0 SP 11 was released today. It contains the fix.

      Regards, Boris

      Author's profile photo Basis S4
      Basis S4

      Thanks Boris.

       

      We would consider that while we start the next run.

       

      Thanks again for your prompt feedback.

      Radu