DMO with System Move Target Database SAP HANA

Many of you demand for this information and here you go with the step-by-step information migration
of on-premise system to any cloud using DMO procedure.

Cloud adoption during this era is common now for cost saving, more agile, security and moving
toward digital transformation and many more enhancement for making business processes intelligent.

For any activity before execution we need to discover each and every phase to understand the
requirement to make our next move successful, for that your preparation has to be perfect for smooth
execution and achieving the end results.

In 2013, SAP introduced new procedure called Database Migration Option (part of Software Update
Manager), which can help you during the migration to HANA database. It combines Unicode
conversion, system update and database migration into a single step which extremely simplified the
overall process

Scenarios: DMO with System move option provided by SAP, with that you can move you existing
landscape to Public Cloud Hyperscale as well HEC platform deployment model without disturbance in
Source and you can choose your target as HANA DB from any source Database (MSSQL, DB2,
Oracle).

Note: It’s a purely Technical execution document which will help in planning, preparation and
execution using SUM with DMO.

Pre-Steps – At Least Two Weeks before Starting: Always read the guide provided by SAP before
starting of any activities as always mentioned in my post.

Database Migration Option: Target Database SAP HANA:

https://help.sap.com/doc/38301960cfe4484587f9cedb8c6a740f/dmosum20.11/en-
US/dmo_of_sum2_to_hana.pdf

Review SAP Notes: migration guides or Specific SAP Blog Return describing the overall
process.

Never Stop Learning, Never Stop Exploring

Jasbir Khanuja
Page | 1
 SAP Note: DMO Note:3024408 - Database Migration Option (DMO) of SUM 2.0 SP11

SAP Note: SUM Note:2974351 Central Note - Software Update Manager 2.0 SP11

See also the PDF documents, which are attached to the DMO Note and the central SUM Note, for a
graphical representation of the supported update and upgrade paths.

Procedure
1. You start SUM on the PAS host with the normal system update and database migration
procedure.
2. During the SUM with DMO run, SUM displays a dialog in which you can enable the system
move option (see prerequisites above).
3. In a further dialog later on, you are prompted to transfer the SUM directory content from the
source system to the target system. You may also enter the target host name in case you
want to use a script for the parallel data transfer.
For more information on the data transfer, see System Move: Data Transfer
4. After the data transfer, the SUM with DMO procedure is complete on the source system, and
you continue with the procedure on the target system.
5. You finish the system update and database migration procedure on the target system.

 System Data Cleanup: This should be done at least 2 weeks in advance of the
migration.

 Cleanup (delete or archive) non-essential data and logs from the system in order to reduce
the migration volume and improve performance.

 Prepare your Target system: We need to create a shell system on the target landscape
(Message Server, App, DB) prior to migrating HANA.

 Create Large SAN Mounts for R3load transfers: for exported PAS instance to move to
create mount files eg. /mnt/SID_export.

 Activate Inactive Objects: All inactive objects need to be active in the system. Otherwise
SUM will fail and report that it found inactive objects in the system.

For some of the custom objects, we may need SWD to activate them. Have SWD activate at
least 2 weeks in advance.

Also try running program RS_WORKING_AREA_CONSISTENCE in SE38/SA38. This

program can clean up inconsistent inactive objects that aren’t really inactive.
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 2
  Pre-Upgrade Notes that Must be Implemented
 Import pre-upgrade transports
 Take Snapshot of Source Database.
 Perform Consistency Check between SAP ABAP Data In Db02old.
 Cleanup Profile Directory & Check Default Profile: Remove all old or additional versions
of the default and instance profiles, also move backup into alternate Directory.
 Determine Free Space: /usr/sap/trans<comp>,/SAPupg directory, usr/sap/<sapsid>
directory
 Check for duplicate primary key entries in TDCOUPLES and RFCDES; You can having
issues with duplicate entries in these two tables. Ask DRM for a query to detect and remove
duplicate entries prior to downtime
Selection of SOFTWARE UPDATE MANAGER:

Pre-Steps – Just before starting DMO

Ensure Perform the consistency check as a part of preparation it depends on business function for
BW and FICO: source system need to be consistent, user of Financial Accounting (FI) and
Controlling (CO) need to perform some preparatory activities, among others additional consistency
checks. {as mentioned follow the guide within that all step by step procedure are defined if you are
running your source DB in Oracle..}

Never Stop Learning, Never Stop Exploring

Jasbir Khanuja
Page | 3
 Output for example:

BW Default RFC Destination:

In case SAP BW is used in your SAP SCM system check the RFC destination to the BW default
client.

Steps
1. Execute the transaction RSTPRFC
2. Select your production BW client
3. If a Destination is displayed, use transaction SM59 to check if the RFC destination works
4. If no Destination is displayed, enter the Destination name
<SID>CLNT<BW_CLIENT_NUMBER>, User and Password. The user in this RFC connection
should be the user which was created with SAP Customizing Implementation Guide activity
Create User for Background Processing in the standard BW client.
5. Press Enter to create the Destination
Checking pool tables and cluster tables:

Run the following reports in background:

Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 4
 SDBI_CLUSTER_CHECK
SDBI_POOL_CHECK
SDBI_CHECK_BCD_NUMBERS
They apparently run a long time. My suggestion is to kick them off and proceed with the next steps,
and then check the result in the next day or two.

SDBI_CLUSTER_CHECK  Execute in Background

This failed in because VER_CLUSTR doesn’t exist on the DB. We’ll have to see if that’s a problem or
not.

SDBI_POOL_CHECK  Execute in Background

Never Stop Learning, Never Stop Exploring

Jasbir Khanuja
Page | 5
 Request HANA DB Migration Key for your respective systems.
https://launchpad.support.sap.com/  Migration Keys  Request

Never Stop Learning, Never Stop Exploring

Jasbir Khanuja
Page | 6
 You’ll need to take the existing System and change the Database and Operating System to “SAP
HANA database” and “Linux”, as shown above.

Then request the license for the new target system’s Hardware Key (found on the message server
using saplicense -get) store it out in /SAPupg/<SID>

SUM - Extraction, Configuration, and Checks:

Never Stop Learning, Never Stop Exploring

Jasbir Khanuja
Page | 7
 In scenario was lift and shift migration from on-premise to any cloud and no system upgrade was
involved. DMO was invoked only for migration scenario without system upgrade/Unicode conversion.

We need to add a parameter called migration_only = 1 on the file SAPup_add.par in the path

If you don’t have the xml file generated then provide the path:

Never Stop Learning, Never Stop Exploring

Jasbir Khanuja
Page | 8
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 9
 Manually upgrade SPAM

Never Stop Learning, Never Stop Exploring

Jasbir Khanuja
Page | 10
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 11
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 12
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 13
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 14
  Change SQL processes to 64 Uptime and 120 Downtime
 Change R3TRANS to 16/32
 Change R3LOAD to 64/120
 Set SGEN to 20.

Never Stop Learning, Never Stop Exploring

Jasbir Khanuja
Page | 15
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 16
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 17
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 18
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 19
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 20
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 21
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 22
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 23
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 24
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 25
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 26
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 27
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 28
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 29
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 30
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 31
 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
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 32
  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.

Never Stop Learning, Never Stop Exploring

Jasbir Khanuja
Page | 33
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 34
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 35
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 36
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 37
 DATA TRANSFER OPTIONS AND OPTIMISATION

Below table can be used to estimate the time and based on that, choose between an offline transfer
or over the network transfer. The table shows the projected time for network data transfer, for various
available network bandwidths (assuming 90% utilization)

While migrating system from on-premise to azure, data needs to be transferred in 2 phases if we are
using online transfer (This approach was used during this migration)

 Data from source system to Azure Blob storage

 Data from Azure Blob storage to Target server on Azure

AzCopy – Use this command-line tool to easily copy data to and from Azure Blobs, Files, and Table
storage with optimal performance. AzCopy supports concurrency and parallelism, and the ability to
resume copy operations when interrupted

Never Stop Learning, Never Stop Exploring

Jasbir Khanuja
Page | 38
 We have 2 options while copying data from source to target system via AzCopy tool.

 OPTION – 1

Once the export phase is completed, copy the entire SUM folder to the Azure blob and from Azure
Blob to target server.

For example: It would take 12 hours for copying data(1.5 TB) from source to target with 500 Mbps
speed

 OPTION – 2

When the export phase is started, data can be transferred intermittently to Azure blob and from Azure
Blob to target server.

For example, if EXPORT phase runs 16 hours, data can be copied every 3 hours intermittently to
Azure blob and from Azure Blob to target server since AzCopy supports parallelism, and has the
ability to resume copy operations when interrupted.

In this scenario data is copied to target server parallelly while the EXPORT phase is running and
hence optimizing the copying method and saving around 12 hours (compared to OPTION -1 as
mentioned above)

Once the data was available on target server, start the SUM and proceed with IMPORT phase of
DMO.
Target system

Copy the SUM directory in target system and extract SUM on top of copied SUM directory and start
SUM

Never Stop Learning, Never Stop Exploring

Jasbir Khanuja
Page | 39
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 40
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 41
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 42
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 43
 Switch to the target host.

Post Processing:

SUM saves the log files and prompts you to start certain follow-up activities.
The following actions are carried out:
 Cleanups
 Transaction SPAU
 Transport unlock

DMO specific actions:

●Phases related to SAP Business Warehouse (SAP BW)
● Runtime evaluation

Further features:
● Postprocessing includes several SAP BW-specific phases
● Evaluation of the update and migration process is written to the file /abap/doc/ UPGANA.XML. To display this
file in a human-readable form, store the file UpgAnalysis.xsl in the same directory.
Never Stop Learning, Never Stop Exploring
Jasbir Khanuja
Page | 44
 Benefits of SAP DMO
 Migration steps are simplified
 System update and database migration are combined in one tool
 Business Downtime is reduced, Unicode conversion can be included as well
 Well known tool SUM is used, with improved UI
 Combined procedure needs only one maintenance phase (not two)
 In place upgrade and migration keeps application server and System-ID stable (avoids landscape
changes (SID, host name, …))
 Original database is kept, can be reactivated as fallback
 Lower prerequisites for SAP and DB start releases
 Well known tool SUM is used, with improved UI
 DMO can be used for SAP Netweaver BW and for SAP Business Suites systems
Technical aspect and Restrictions of SAP DMO
 No certification required for consultants using DMO of SUM
 No migration check service required for DMO on productive systems
 Still the migration key has to be entered during the DMO run, as R3load requires the key
 DMO supports a migration only to SAP HANA DB
 DMO works only for AS ABAP based systems
 A dual-stack split is not be included in DMO

Start release of different database which support SAP DMO

Reference: SAP Notes reference for the DMO

• SAP Notes 813548 Database migration option (DMO) for Software Update Manager
• SAP Notes 1799545 Using DMO of SUM for SAP BW systems
• SAP Notes 1875197 Using DMO of SUM for SAP Business Suite systems
• SAP Notes 1031096 Installing Package SAPHOSTAGENT
• SAP Notes 1968508 Release change & Single Code Page Conversion to Unicode with DMO
• SAP Notes 1813548 for the latest information regarding Database migration option (DMO) for Software Update
Manager

This document is the ask from with multiple request who all are currently in planning phase or plan
moving their existing system migrating into Cloud with target database HANA, that the reason before
week I share the post and mentioned go through this DMO document and wait for a week.

Never Stop Learning, Never Stop Exploring

Jasbir Khanuja
Page | 45
 Thanks You

Jasbir Khanuja

Never Stop Learning, Never Stop Exploring

Jasbir Khanuja
Page | 46