Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
Showing results for 
Search instead for 
Did you mean: 
0 Kudos

Introduction:  This blog explains few downtime optimization techniques while using SUM DMO for any SAP Migration. Optimization is mainly categorized in below area :

  • Infrastructure Layer
  • Tool Layer
  • Application  Layer
  • Database Layer

We have seen a significant reduction in technical downtime after implementing these recommendations.

Scenario: We have used in below scenario in recent large scale migration:

  • HANA Migration & Upgrades for abap from On-prem to Cloud using SUM DMO
  • HANA Migration for Java applications from On-prem to Cloud using classical SWPM


As highlighted above , here are the details of achieving the proposed downtime for our Cloud migration :

  1. Infrastructure Layer : We implemented below recommendation from Infra layer
    1. Upsize PAS : As we aware that SUM will run in Primary Application Server in both Source and Target , we have increased PAS CPU + Ram 10 times in target. Since this needs a Server reboot hence due to downtime restriction we couldn’t not achieve Source Server upsize however if possible upsize source PAS as much as possible which will benefit during export in Downtime. We follow below steps :
      1.       Run the SUM and reach “Lock Development “ in Source.
      2.       Upsize the target PAS where we will be running SUM to 10 times
  •       Resume SUM in Source and copy the same in target in subsequent phases
  1. Upsize IOPS : During import in execution phase, IOPS of certain drive is very critical factor. Hence we increase IOPS 3 times in /hana/log & /hana/data which helped us in optimization. For AWS , we don’t need any reboot and EBS can be upsize online for the mentioned mounts.
  2. Provision separate Mount to RUN SUM : Provision a separate Mounts to run SUM with high IOPS. Once we are done with Migration , we can decommission the Mounts to save the cost.
  1. Tool Layer : We implemented below recommendation from Tool layer
    1. Managing R3load : As we aware R3load is responsible for export / import but it also responsible for splitting the tables into packages. So In the roadmap step Configuration, in the INITSUBST phase  we added R3load as 10 times than PAS CPU. We have not seen any impact on server performance due to this but we need to reduce to 3-5 times before starting Downtime phase and keep monitoring the same till the time we reach 80% of CPU utilization.

This will create high number of packages for your large tables which will faster your export / import process.


  1. Uncheck Migration Repetition Option : Although its very standard , but we have to ensure that we uncheck below option in SUM . Else there will extra downtime.




  1. Keep MIGRATE_DT_DUR.XML in Download directory : As we aware SUM will build its algorithm hence its very important that we keep this xml file in download directory from our earlier Run.
  1. Application Layer : Apart from the standard check , we need to analyze MIGRATE_DT_DUR.XML file which table took maximum export / import time . There will be a lot of optimization we can do with downtime in case we can reduce those table counts / archive.

Here are few abap tables which we face challenges : BALDAT /SOFFCONT1 / EDI* tables.

We also do faces challenges with PO ( SWPM export / import ) on BC-MSG* tables. Reducing counts helped us to optimize downtime.

  1. Database Layer : We implemented below recommendation from Database layer
    1. Source Database : For our case source Database was Oracle where we implemented parameters recommendation as per SAP Note : 936441
    2. Target HANA Database : As per standard Hana mini check , we need to implement the recommendation else there will be impact during import phase.
    3. Network Errors : There might be few scenarios where due to temporary network disruption during Execution – Import phase , overall execution time got increased. Hence its strongly recommended that we should keep checking “Index server “ logs in Hana OS level and in case we are getting any “rc=110” , “rc=104” & “rc=15” , we should highlight immediately to network team. This is as per : 2222200.


Reference : Along with  SUM & SWPM  Master guide , we have followed below Notes in order to come up with above recommendation :


Labels in this area