Skip to Content
Technical Articles
Author's profile photo Rajesh Azmeera

SAP HANA/S4 HANA migration to Cloud (AWS/Azure)

In this article will demonstrate complete BASIS/HANA DB steps “How to migrate SAP Apps and HANA DB to AWS/Azure cloud.

Tools are available for SAP Migration to Cloud, Cloud Endure (AWS), Azure Site Replication (ASR), Backup & restore, export and import and DB replication methodologies. The tool we’ve used is open source tool (RSYNC) for applications migration and DB replication (HSR).

Key notes: This is AS-IS migration. No changes on source end and assuming DB was already installed on AWS/Azure. (Refer below link how to install HANA Database)

Complete steps for Migration:

  1. once VMs are built please make sure respective RPMs are installed
  2. Reference SAP NOTE: 2455582 – Linux: Running SAP applications compiled with GCC 6.x  and  2777782 – SAP Hana DB recommended settings for RHEL 8
  1. Hostnames (host name used during DB installation) should be different between source and Target DBs
  2. SID and Instance no for both DB and Application should be same
  3. sid-adm /Sudo -root user and password information for source
  4. SAP* and DDIC access to Source system
  5. For HANA database obtain passwords of users SYSTEM (System DB and Tenant DB), SCHEMA, DBACOCKPIT and any other database admin user from Tenant DB
  6. List down installed Plug-ins in Source DBs
  7. Take the necessary screenshots of the source system like STMS, SMLG, RZ12 etc.

TARGET System Preparation:

  1. Prepare the build sheet for all SAP component systems
  2. VM Systems build with 8.x on AWS/Azure
  3. Maintain UID & GID with On Prem and AWS/Azure same
  4. Verify the SAP recommended packages , kernel parameters, FS, memory & CPU in both Apps and DB nodes
  5. Verify if the required installation packages are available (Database, Application , DAA, SWPM and Kernel)
  6. Database Servers checks/Readiness (Storage, OS, Networks, Files hares) in the target server
  7. Install HANA 2.0 SP05 revision 56 (same as source in our case) with required plugins and Run Hardware check tool, ensure that the target SID matches the source SID and instance number
  8. Please note that HANA replications supports from lower (source) to Higher (Target AWS/Azure)
  9. Connectivity between Database Server and Application Server on AWS/Azure
  10. Check list of IP addresses at Source and allow necessary ports in AWS/Azure firewall for inbound requests
  11. Port 4nn00 – 4nn99 needs to be allowed for HSR between the Source and Target DB’s
  12. Port 3298 can be allowed to check with niping
  13. Run niping command to listen inbound requests from SourceFrom Source : ./niping -c -H <IP> -B 2000000 -L 5

    In Target : ./niping -s -I 0 -T trace_niping &

  14. Configure HSR replication from On-Prem  node to AWS Primary node
  15. Sharing of .dat and .key files  from Source DB & list of parameters that needs to be set in AWS/Azure DB
  16. Stop DB in AWS/Azure
  17. Take the backup of existing .dat and .key files and replace the Source DB .dat and .key files and maintain above mentioned parameters
  18. Maintain source DB IP/hostname in /etc/hosts files in AWS/Azure DB
  19. start DB in AWS/Azure
  20. Enable HSR replication from On-Prem node to AWS Primary node
  21. Monitor the replication (Full and delta completion)
  22. Take-over AWS/Azure Primary DB to normal mode and do the health check
  23. Update DB license

Application sync from Source to Target suing Rsync

  1. Create all OS level application users (<sid>adm, daaadm, sapadm) with proper group ids (sapsys, sapinst ) same as source systems in Target AWS/Azure nodes

Sync FS from on Prem to AWS/Azure Application Server for all

NFS mount points

  1. Sync the file system permission same as Source system
  2. Update the hdbuserstore in all application servers and verify application to database connectivity in the application host using R3trans -d
  3. Bring-up application server and do Sanity check
  4. Adapt profile parameters for application and DB for if required and restart the SAP application
  5. Perform Post migration steps for <SID> Application and Database
  6. Check system consistency using SICK
  7. Perform Post Installation Action for Transport Organizer in SE06
  8. Import profiles of active servers in RZ10
  9. Generate system loads in SGEN
  10. Modify the GUI initial screen in SE61 if required
  11. Install DAA agents in all the servers
  12. Application monitoring to be configured in Solution Manager and confirmed
  13. Shutdown the application servers

DB Readiness checks:

  1. Take FS screen shot of all Source systems
  2. Check no other backup was triggered after full online backup for HANA DB & application (if applicable) for <SID> and stop all scheduled backups and BTC jobs with BTCTRNS1
  3. Check replication sync status
  4. Stop Batch jobs
  5. Lock Users and Stop Application servers
  6. Wait for Delta replication completion (Point in time data)
  7. Take-over AWS/Azure HANA DB from replication mode to normal mode, run command ‘hdbnsutil -sr_takeover’ in azure DB.
  8. Once takeover is completed, disable the replication in azure DB and disable replication on Source DB (hdbnsutil -sr_disable)
  9. Rename DB hostname to same as Source DB alias hostname
  10. Include DB/App host into Domain along with source system alias name
  11. Stop DB node in Azure
  12. Revert all the parameters in global.ini which was added during HSR configuration
  13. Revert both SSFS files from current to original (during installation) in AWS/Azure DB
  14. Start DB node in Azure
  15. Start the SAP application
  16. Enable the replication on Azure DB between Node A and Node B
  17. Verify the license on DB, Application and perform Sanity checks
  18. Configure & Run Backup and completion.

If you think there is some data to be synced on applications please re-run Rsync (Delta Sync)

  1. Perform a DNS switch so that respective hostnames will point to AWS/Azure IPs
  2. Start Database and applications on Target.

Let us see how to perform HSR between source and Target.

Assuming that HANA Database is already installed on AWS/Azure with same version as of Source.

(HSR Replication from source to target works (lower to higher version) but not other way (higher to lower version replication does not work)

1) Enable replication from Source DB
hdbnsutil -sr_enable –name=SourceA
2) Verfiy the state of primary server
hdbnsutil -sr_state
3) Secondary (DB on AWS/Azure)
Check HANA is stopped
4) Secondary side: register (DB on AWS/Azure)
hdbnsutil -sr_register –name=TargetB –remoteHost=sourceDBHost –remoteInstance=$$ –replicationMode=async –operationMode=logreplay
5) Start Hana on Secondary
sapcontrol -nr $$ -function StartSystem HDB
6) Verify cluster
hdbnsutil -sr_state
7) check the replication status via Hana studio or python script

8) unregister replication on Target Database on AWS / Azure
hdbnsutil -sr_unregister
9) Stop Database and applications on-Premise
10) start HANA Database on AWS/Azure
sapcontrol -nr $$ -function StartService SID
sapcontrol -nr $$ -function StartSystem

Let us see how to perform RSYNC between source and target.

Look at below link how to install and configure RSYNC in case not present at OS

Sudo to root and execute below.

rsync -avhz  –partial /home/<SID>/  <sid>adm@<Target IP>:/home/<sid>adm/
rsync -avhz –partial /usr/sap/<SID>/ <sid>adm @<Target IP>:/usr/sap/<SID>/
rsync -avhz –partial /sapmnt/<SID>/  <sid>adm @<Target IP>:/sapmnt/<SID>/
rsync -avhz –partial /usr/sap/DAA

-a, –archive, archive mode, equivalent to -rlptgoD. This option tells rsync to syncs directories recursively, transfer special and block devices, preserve symbolic links, modification times, groups, ownership, and permissions.

-z, –compress. This option forces rsync to compresses the data as it is sent to the destination machine. Use this option only if the connection to the remote machine is slow.

-v, –verbose               increase verbosity
–h, –human-readable        output numbers in a human-readable format
–progress              show progress during transfer

1. ASCS & ERS Host ==> Requires Following file system

/sapmnt/<SID> ==> common mount exists across all SAP Servers

2. Validate the FS on target server and verify the permissions with <sid>adm:sapsys after sync in /usr/sap.
3. Verify the host file and maintain “/etc/hosts” on DB ,Ascs, ERS, App and hard code the VIP hostname with physical host IP.

4. Append the entries to the file /etc/services
5. Change Environment variable files if <SID> is different in all APP servers
Go to /home/<sid>adm
ls –alt
egrep <SID> .sap* – change to target <SID> if SID is different
Chown –R <sid>adm:sapsys .sap*
Chown –R <sid>adm:sapsys *
Check the home path for <sid>adm,daaadm

Edit /usr/sap/sapservices accordingly

Make sure below slinks are working. If not exist please do create them

lrwxrwxrwx 1 sidadm sapsys 19 Nov 9 18:49 profile -> /sapmnt/<SID>/profile
lrwxrwxrwx 1 sidadm sapsys 18 Nov 9 18:49 global -> /sapmnt/<SID>/global
lrwxrwxrwx 1 sidadm sapsys 18 Nov 9 18:50 uc -> /sapmnt/<SID>/exe/uc
lrwxrwxrwx 1 sidadm sapsys 19 Nov 9 18:55 nuc -> /sapmnt/<SID>/exe/nuc
lrwxrwxrwx 1 sidadm sapsys 30 Nov 9 18:56 dbg -> /sapmnt/<SID>/exe/uc/linuxx86_64
lrwxrwxrwx 1 sidadm sapsys 24 Nov 9 18:56 run -> /usr/sap/<SID>/SYS/exe/dbg

rsync – sync completion sample screenshot for /sapmnt/SID

Check HDB user store and update with required details
Start Databse
hdbuserstore SET DEFAULT DBHOSTNAME:35015 <schema> <Password>
sapcontrol -nr 00 -function StartService <SID>
sapcontrol -nr 00 -function Start

R3trans –d should return (0000)
Start app server/(s)
sapcontrol -nr $$ -function StartService <SID>
sapcontrol -nr $$ -function StartSystem
Please note that Start will start local instances whereas StartSystem will start all instances

Please like and share your feedback in comments and follow me for more blogs at Rajesh Azmeera 

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Pawan Singh
      Pawan Singh

      Hi Rajesh

      Really thankful for this wonderful blog on sap hana or sap system on hana migration to cloud.

      We are having similar sort of requirement of AS/IS migration but few sap systems are on Oracle/ASE/SQLserver as DB's then in that case we have to go with either backup/restore or export/import option or can you suggest please any other way as well/






      Author's profile photo Rajesh Azmeera
      Rajesh Azmeera
      Blog Post Author

      Hi Pawan Singh,

      Glad to assist further to spread the knowledge. If needed we can connect at   Please let me know. Thank you.




      Author's profile photo Rajesh Azmeera
      Rajesh Azmeera
      Blog Post Author

      Hi Pawan,


      Thank you so much for letting me know that you are able to apply these concepts.

      Yes for SAP HANA, all these steps are concrete and complete.


      For your scenario:

      source Oracle/ASE/SQLserver as DB's  - Target AS-IS - Backup/restore , Export/Import works undoubtedly for Databases and Applications can be rebuilt using SWPM system copy.

      If the oracle Database and Applications are on Linux/RHEL - Target AS-IS - Backup/restore works for database and you can leverage rsync for applications.

      If the application servers  are on Windows - you can't use rsync as registries related windows won't be copied/registered from source to target. Inface rsync utility won't be available for windows.


      Please let me know if you have any other questions. Thank you.