Your SAP on Azure – Part 2 – DMO with System Move

When you have the SAP landscape on-premise but you’d like to move your solution to one of the cloud platforms you need to think how to transfer your system. Before HANA you could choose one out of following options, depending on your source and target database

1. Homogeneous system copy (when your source and target databases are the same)
   1. Backup / restore
   2. Export / Import
2. Heterogeneous system copy (when you want to migrate from one database to another)
   1. Export / Import

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.

(source: Database Migration Option (DMO) of SUM – Introduction)

Until SUM SP20, DMO had one disadvantage – it didn’t allow you to change your Primary Application Server host. If you wanted to move the instance to the new server you had to perform the whole operation as two-step activity:

1. Execute DMO
2. Use Homogeneous system copy to move the system

Software Update Manager is constantly developed and with every new support package SAP is releasing new features (did you know it can send you e-mails?). One of the newest ones is the possibility to move the system to the new server during single DMO execution. But that’s not all. We don’t even have to update any system component so we focus on the migration process only, which makes it perfect for system migration to cloud platforms.

RESTRICTIONS

However, the tool is available for customers it is important to remember that some restrictions apply:

• DMO with System Move is currently not supported for SAP source systems running with Windows operating system.
• A change of the System-ID (SID) is not possible.
• Short hostnames for source and target PAS must be different

Requirements for Source System and Source Database:

Database: All source databases excluding SAP HANA

OS of source PAS host:  Any Unix-based operating system. In case of an IBM DB2 for i database, the PAS must always run on an IBM i Host.

Requirements for Target System and Target Database:

Database: SAP HANA and SAP ASE only

OS of PAS host: Linux only

(based on SUM SP21, please check note 2426315 for the full list of limitations)

PREPARATION

Prior to starting the migration, it is required to prepare the source and target landscape. SUM doesn’t install the target system during it the movement process. Therefore, we need to install SAP NetWeaver on target application server.

You don’t have to install full ERP system. It is sufficient to install just a NetWeaver AS as all the content will be overwritten during the execution.

I will skip the NetWeaver installation process because there are many valuable blogs on SCN already. What is important to notice is that the SID on source and target instances must be the same. Instance number can be different, but it won’t be changed during migration.

Source system should have implemented SAP Note 1903295, otherwise, you will encounter issues during phase OB_RS_DMO_HDB_CONTENT_ACTIVATE.

As the database is changed during the process, we need to take care of providing the new kernel libraries appropriate to the target configuration.

My source system details:

Operating system: SUSE Enterprise Linux 12 SP1

Database: SAP MaxDB 7.9

SAP Product: SAP ERP 6.0 EHP7 (based on NetWeaver 7.4)

Hostname: linux-zmfo

My target system details (VM on Azure Cloud Platform):

Operating system: SUSE Enterprise Linux 12 SP3

Database: SAP HANA 2.0 SP2

SAP Product: SAP NetWeaver 7.4

Hostname: bjhana2

SOFTWARE UPDATE MANAGER ON SOURCE SYSTEM

Depending on your NetWeaver release you need to download the correct release of Software Update Manager.

If your system is based on:

NetWeaver 7.4 – you should use SUM 1.0

NetWeaver 7.5 – you should use SUM 2.0

As we don’t plan to perform any software upgrade, we need to enable SUM for migration only scenario. This can be done by creating a file called SAPup_add.par inside the bin directory of SUM. The file should contain following line:

Migration_only = 1

After the file is created we are ready to start the Software Update Manager.

The first difference in the process we can already see on the first screen. Usually, SUM requires the stack.xml file to continue, but the added parameter changed that behavior and we can select the option to run the migration only.

During SCAN_DOWNLOADDIR step we need to provide the path to the directory where kernel files have been downloaded.

Now, we need to decide if we want to migrate the database to SAP HANA or stay with the existing one (please check the restrictions section in this blog).

Our goal is to move the system to Microsoft Azure Cloud Platform, therefore we need to select the option Enable the migration with System Move.

Following two screens allow us to do the advanced configuration of the Software Update Manager processes. My source system is very small so I decided to keep proposed values. The only thing I changed was disabling the ABAP generation.

When we are finished with the configuration, SUM starts to perform the checks and preprocessing. This was relatively long process due to the creation of the Shadow Instance (which cannot be skipped). It was also an excellent moment to have a break because the next step is where the fun begins!

DATA TRANSFER MODES

Finally, it took around two hours of processing and SUM stopped at HOSTCHANGE_MOVE phase. This is the moment when we start the synchronization of our two systems. We can choose one out of two synchronization options:

1. Serial mode: when we want to wait until all exports files are created and then move entire content at once
   (source: sap.com)
2. Parallel mode: when we want to enable the online synchronization.
   In this scenario, the import and export jobs are running in parallel. The job dmo2sapcloud.sh is running in the background and sending files from the source to the target host.
   (source: sap.com)

I already knew which mode I want to check out! As there is no need to wait for the complete file export, the parallel mode can be a huge advantage of the System Move process.

EXPORT / IMPORT PREPARATION

The default mode for SUM is to use the Serial mode. If you wish to use it you can just continue with the process and move the SUM directory to the target host after the export of the source system is finished.

In our case, in order to use the parallel mode, we need to perform some activities before clicking Next button. The first thing is to allow user login from the source to the target host without a password. We need to generate the ssh key and transfer it to the target computer.

Then, copy the entire SUM directory to the target host. Use the same path to avoid problems. When the copy is completed, we have to type the target hostname on SUM screen and we’re ready to continue with the process on the source system.

This is the moment when the first files are being exported:

At the OS level, we can see the background job that transfers the file from one server to another.

After some time, we are asked to perform the backup and the system is shut down by the SUM.

Data extraction continues during downtime and in the log files, we can see the synchronization status.

SOFTWARE UPDATE MANAGER ON TARGET HOST

When the whole SUM package is finally transferred you can start the application on the target host (in parallel to the one on the source host) and log in through a web browser. The tool automatically detects the hostname has changed.

During next few screens we are asked to provide basic information about the target system, like instance number, profile parameter file location, database details etc.

We can decide whether we prefer to reuse the current database tenant or rather keep it unchanged.

On the next page, we need to provide the download directory with the system kernel.

And the import begins!

If during execution some files are missing SUM will wait until files are transferred through the background script.

POST MIGRATION PROCESSING

The export job is finished. If we used the serial synchronization mode we would transfer the SUM directory now. In our case, we just need to check the log files if all files are transferred successfully we can click Next.

When the post-processing of the source system is finished we can shut down Software Update Manager and focus on the target server. Such source system can be used at the later time, however, keep in mind that any changes done after the migration won’t be transferred.

The target system is still working on the import, but after some time the DMO procedure is also finished and we can log in to the target SAP system.

Let’s have a look into system information. The hostname is correct, installed product versions as well – I think we can celebrate the successful migration!

If you enjoyed this post please Like it and help it spread by sharing it on Twitter and LinkedIn! Thank you!