The benefits and challenges of the OS/DB migration methods to get you to a more supportable OS/DB combination for SAP on the Cloud are vast. Over the past decades, we have seen SAP invest in making their product as agnostic as possible when there were a plethora of operating systems and database vendors to choose from.

With the introduction of HANA and SAP’s purchase of ASE, the choice of databases supporting SAP has increased. However, because the Microsoft Azure platform is built on physical servers based on X86 Intel and AMD processors, the choice of operating systems supporting SAP has narrowed to Windows and the family of Linux-based vendors, SUSE, Red Hat and Oracle.

This results in a database and operating system compatibility matrix for SAP on Azure as follows:

Database and operating system cross reference for Azure

These operating systems are little-endian whilst some of the other commonly used operating systems for SAP (e.g. AIX, HP-UX, Solaris SPARC) are big endian; a “lift and shift” for the SAP and database systems hosted on a big endian based to a little-endian based processor, is not possible. An SAP or vendor OS/DB migration must be performed instead.

To distinguish between SAP HANA and the other databases supporting SAP, the term “AnyDB” is used for the group of databases ASE, MaxDB, MSSQL, DB2 and Oracle.

Options for moving your SAP workload to Azure

With reference to the diagram above, we see the following paths available for a move from AnyDB to AnyDB on Azure:

A.   Lift and Shift – the source and target operating system and database are the same. The SAP system and database could be moved to the cloud using backup/restore techniques or similar.

B.   Lift and Migrate – the source and target operating system and/or database are different. The SAP system and database must be migrated with classic SAP OS/DB migration techniques or vendor tools such as SNP CrystalBridge.

For a move from AnyDB to HANA on Azure, we have the following paths available:

C.    Lift and Migrate – the source and target operating system and/or database are different. The SAP system and database must be migrated with classic SAP OS/DB or DMO migration techniques, or vendor tools such as SNP.

D.   Migrate to HANA – after we have completed the move as per A or B

Note: with a move to HANA, an upgrade of the involved SAP software component may also be required as part of the migration (e.g. SAP ECC).

Your choice of path and tools could also depend on one or more constraints that may exist:

  • Minimal downtime available
  • Performance constraint on existing hardware
  • Network bottleneck between existing data centre and Azure
  • OS, Database and SAP version levels supported on Azure
  • Licence / commercial constraints

There are some interesting platform options available to SAP customers wishing to move to Azure who have large investments in SAP and the underlying database, who want to keep the level of change to a minimum. For example, if you’re an AIX/DB2 user, you have the option to migrate your SAP estate to RHEL/DB2; If you’re an HP-UX/Oracle user, you have the option to migrate your estate to Oracle Linux/Oracle or Windows/Oracle.

Although a migration involving SAP HANA with DMO can be performed by any technical SAP consultant, a classic OS/DB migration must be performed by SAP OS/DB migration certified consultants, which is a specialism of Aliter Consulting. We have performed numerous OS/DB migration projects both for cloud and non-cloud SAP migrations.

A typical SAP migration project can take anywhere between 6-12 months depending on the complexity and the number of systems involved. There will be numerous challenges and cloud-readiness activities to be addressed, such as:

  • Software levels may have to change as part of the migration
  • SAP data dictionary health check
  • Data volume management and archiving to reduce database footprint
  • Unicode conversion may have to be considered
  • Development changes may be required if OS and/or DB are changing
  • Available downtime for production may require additional migration tuning
  • Production support during the migration project, e.g. parallel landscape
  • Interfaces need to be identified, adjusted and tested
  • Testing of the migrated systems both functionally and operationally

Embarking on a migration of your SAP workload to Microsoft Azure may seem daunting at first, but with the right level of planning and the best team in place, it is very achievable.

Ready to Innovate but not Ready for S/4HANA?