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
- Homogeneous system copy (when your source and target databases are the same)
- Backup / restore
- Export / Import
- Heterogeneous system copy (when you want to migrate from one database to another)
- 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:
- Execute DMO
- 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.
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)
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)
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
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:
- Serial mode: when we want to wait until all exports files are created and then move entire content at once
- 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.
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!
This is the second part of my blog series about SAP and Azure. You can access previous parts by using following links:
Part 1 – ARM Templates
You might be also interested in enabling SAML Single Sign-On with Azure Active Directory.
I just performed an DMO migration with System Move, and indeed its great to move systems to a cloud service or other On-Premise without upgrading the system, I would disagree with the simplicity of moving Primary Application Server.
In your blog you mention, its necessary to execute DMO as step 1 and then a Homogenous system copy as step 2.
But if you just execute a DMO migration from anyDB to HANA for example, you can simply uninstall source PAS, and then install a new PAS in target server, and HANA Database is still up and untouched.
So, I dont understand why it is necessary an Homogenous System Copy, when by just reinstalling the App Server you moved your system to different platform, keeping in mind you already migrated your DB to a Linux Server.
thank you very much for your comment!
There are different ways to achieve the goal and I'm pleased I had the opportunity to present one. Is the system move the best way to migrate to cloud providers? I think it depends.. Just look at the restrictions section to see how much there is still to be done.
If the exist was from SAP HEC back to on-prem, would the process still be using DMO system move back to on-prem? Are the files/db or system copy sent back to on-prem on physical movement (delivery)? Or do we leverage the connections of cloud providers (Azure ExpressRoute or AWS Direct Connect)?
In these days, there should be the capability of a snap copy (i.e. NetApp), but I know that entirely depends on RAM size, network and latency from source to target.
But maybe using third-party software lwould not be certified by SAP.
you can use the DMO with system move whenever you want to transfer your SAP system. It can be from on-premise to Cloud, but I can't see a problem moving the system from Cloud to On-Premise.
Regarding the data transfer - it's just using what is available. In my case, it was just an internet connection, but you can secure it with VPN or you can use the ExpressRoute. Just remember that in case of a large system the process can be quite long, so a fast and reliable network connection is essential.
My organization would like to perform migration of our current ECC 6.0 EHP7 running on SUN OS with Oracle to HANA on Azure using DMO with System move option.
As we are meeting the prerequisite(EHP7), System update is not required, but our current ECC 6.0 EHP7 landscape is NUC.
In this scenarios, can we use DMO with System move option for Unicode conversion and HANA Migration?
If possible then,
Where do we need to do Unicode preparation(on-premise)?
Once we prepare Unicode preparation on-premise, can we follow similar steps as you explained here?
Could you please explain, how do we proceed on this scenarios
Thanks for this informative blog.
You took a very practical use case/scenario of moving the PAS host from existing Data Center to Cloud (Azure) using System Move option with DB migration as well , from MaxDb to HANA DB but no Software update.
I have a question here.
Can we attempt to include SAP Software Update also along with all above tasks in 1-step conversion process?
For example, if my source environment hosted on our own Data Center looks like this :
SAP ECC 6.0 EhP6 on SAP NW 7.4, Oracle 11.2.04, IBM AIX
And target environment on Cloud (say Azure) should be as below :
SAP S/4 HANA 1709 on SAP NW 7.5, HANA DB 2.0, SLES 12 SP2 with SAP S/4 HANA instance running on a different host and HANA DB on another host in cloud.
So can we accomplish it all in one go, by firing SUM with DMO using Stack file and also using "System Move" option ?
Your expert views and advise will be appreciated.
I'm afraid you need to use a two-step approach. Firstly, use DMO to upgrade / migrate your system to SAP ERP EHP7 on HANA. Then you can perform the system conversion to S/4HANA.
Thanks Bartosz for quick reply, appreciate it.
If I elaborate further my understanding of 2 steps conversion as you have proposed, in first SUM run with DMO while selecting “System Move” option, we move the SAP Application (with NO update/upgrade) server from local datacenter to Cloud while migrating the DB from Oracle to HANA And in second step/SUM Run, we just upgrade the SAP ECC to SAP S/4 HANA which will be in-place upgrade at Cloud itself.
I have tried to put in more details in attached pic.
Is my understanding above correct ?
Sorry, I think there is a problem with the attached picture.
My proposal would be:
Execute DMO with system move to ERP EHP7 on HANA (upgrade in scope). Just check if your system in unicode or not.
Run system conversion to S/4HANA.
Sorry Bartosz if attached pic is not opening, trying to attach it again here, hope it is visible now.
On your proposed approach, if we can include Software Upgrade in 1st step along with DMO & Susyem Move then I was wondering why to upgrade to Ehp7 first and then upgrade to S/4 HANA in 2nd step. I believe, SUM 2.0 allows conversion/upgrade of SAP ECC6.0 EhPx (any version) to direct S/4 HANA. Or is there any limitation here ?
Correct me if my understanding is not correct.
Yes, now I can see the picture, thanks!
I'm not sure where did you get the picture from (please provide the source), but I believe there is a bug. You can't use the HANA database with Netweaver 7.02, so therefore you can't use the EHP5 with HANA. You can confirm that on the SAP Product Availability Matrix (https://apps.support.sap.com/sap/support/pam)
However, I had a look to the conversion guide and SAP Note 2482453 - SAP S/4HANA 1709: Release Information Note and I believe that something has changed, because it is written you can perform the system conversion form any ERP6 release:
Supported source releases:
If I were you I would just run the Maintenance Planner and see if it allows you to create such conversion path.
Thanks Bartosz for efforts and updates.
The pic shared earlier was not from any specific document or link but I only proposed/made it to elaborate on my thought process.
Refer below another pic which I captured from attachment of SAP Note 2472850 - Central Note - Software Update Manager 2.0 SP01, which suggests that using SUM2.0SP1 we can upgrade EhPx (from NW 7.0 to 7.4) to Ehp8 (on NW 7.5). SO I guess, with new Sum2.0SP1 SAP Softwatre Upgrade and DB migration alogn with System Move on 1-step is feasible.
Your thoughts !!
I'd like to check with you on the steps on "SOFTWARE UPDATE MANAGER ON TARGET HOST".
On the SAP SYSTEM HOST, it did mentioned enter the host name of your central instance (PAS instance). I have ASCS (sapt04ci), PAS (sapt0421) and AAS (sapt0422). In this case, I should enter the ACSC or PAS?
I'm currently enter PAS server and it's instance number, but in the RZ10 profile, it did show me the error "ASCS profile /usr/sap/T04/SYS/profile/T04_D21_sapt0421 cannot be imported as profile name is already reserved for another profile type".
I am confusing, should I provide the ASCS as the system host in the SUM? What I am confuse is it is mentioned CI (PAS).
Can you please advice?
Thanks & Regards
It says you should provide Primary Application Server profile parameter. It looks for me like you are somehow trying to import PAS profile as an ASCS profile in RZ10. Look for the issue in RZ10 and not in SUM.
I am doing S/4 Hana Conversion from ERP 6 EHP5 which is on maxDB .I have completed the pre-processing on the source host and i have selected the seriel mode of DMO,the process is completed on the source host.I transferred the SUM directory to my target host.I started the SUM tool on the target host ,it is prompting me to enter the PAS host and instance number on the target host,it is not able to fine the profile parameter with the target host details.Could you please suggest how to proceed this,do we need to create anything manually on the target host?
this blog doesn't treat about S/4HANA System Conversion but about migration to cloud platform so the DMO steps are most probably different.
I would check where DMO is trying to get the profile from - this information is probably included in one of the logs. Then I would check if I can access the profile.
Please attach log files and maybe some screenshots.
I was checking the S/4 conversion 1709 guide,the process is quite similiar.i am attaching the error i am facing,it is just not able to find the PAS instance on the new host.so the black cross out is my new host where HANA is installed.
4WETQ399 Cannot find 'R3trans' in current path!
2 ETQ367 Connect variables are set for standard instance access
4 ETQ399 System-nr = '02', GwService = 'sapgw02' Client = '000'
1 ETQ200 Executing actual phase 'MAIN_MIGSERIALSETUP/HOSTCHANGE_MOVE'.
1 ETQ399 Phase arguments:
2 ETQ399 Arg = 'FORK_FILES;REQ_HOSTMOVE;SETUP_ON_TARGET'
4 ETQ399 Starting dialog 'MigrateMoveHost' at 20180709040653.
4 ETQ399 Dialog finished at 20180709040722.
4 ETQ399 Starting dialog 'HostInstNr' at 20180709040722.
4 ETQ399 Dialog finished at 20180709040735.
4 ETQ399 Starting dialog 'Profiles' at 20180709040735.
4EETQ399 Dialogue validator 'InstanceProfileValidator' failed with 'Unacceptable SAP instance profile '/usr/sap/D01/SYS/profile/D01_DVEBMGS02_newhost: File does not exist!'.
4 ETQ399 Repeat dialog since input validation failed.
Can you see if you have the file available on any of the servers?
My issue was resolved,I was missing the NW installation part on my target host. Now, my system is converted to S/4 HANA successfully.
Hi, great, thanks for sharing a solution!
During the SUM export, the size of the export should be the same as database size or it will be in the compressed format like SWPM export? if not how much percentage will it compress?
We are planning for a large database and we don't have any other filesystem to export the content.
Parallel transfer is not possible because of firewall rule
Please suggest me how to proceed.
SAP First Guidance – Using the new DMO to migrate to BW on HANA
Can we migrate SAP IDES system to Azure Cloud.
as long as the SAP IDES fulfills the minimal requirement specified in SAP Note 1928533 - SAP Applications on Azure: Supported Products and Azure VM types you should be fine!
Thank you Bartosz for reply. I will go through SAP note.
Is a change of the System-ID (SID) still not possible?
We need a different SID after migration, will it be possible to change the SID afterwards using SWPM in HEC?
Hello Bartosz Jarkowski,
We are planning to migrate out Solution Manager 7.2SP09 which is on VPC linux on oracle DB to Solution Manager 7.2SP11 on AWS and on HANA db.
My question is, can we use DMO to achieve this? What should be our approach in doing so. In some blog i have seen reference for SAP Note saying -
But the Note 2277055 clearly says:
There are some limitations to use DMO across data centers is not supported.
There are no technical restrictions, but it comes with a high performance and latency impact.
You my use it at your own risk. No support is provided in case of performance issues or broken procedures due to network/latency issues."
You could use the DMO to move the ABAP part of the Solution Manager. To use the DMO across data center you have to start it with the system move option.
SUM 1.0 / 2.0 DMO System Move would work on Oracle Linux 7.x also?
EHP6 on Oracle 18 (Oracle Linux) => S/4 Hana on Hana 2.0 (SLES 15.x)
Hope you're doing well.
I would like to know the approach if the DB moves to the cloud when we've source database(MCD) is shared between ABAP and Java(standalone setup). Our customer has two landscapes PI and Solman in this nature which has to be moved to cloud from their on-premise. Both PI and Solman systems(standalone) ABAP and JAVA are using the same databases.
Simple ABAP systems can be migrated to Cloud through DMO(Oracle to HSB) with system move; however , I would like to know how a Java system can be linked to a migrated Database in this scenario.