Migrating an SAP landscape to Azure is a complicated task with lots of moving parts. Apart from the sheer volume of data, a migration can involve software upgrades and data conversions. Not only will a landscape need to work properly once migrated, but in most cases, the migration needs to happen quickly as SAP systems are usually the information backbone of an organization.

Once the target environment structure has been finalized the next important phase is planning the migration so that system downtime is kept to a minimum. There are different migration strategies to suit multiple scenarios and this course looks at which strategy works best for each scenario. We then look at ways to optimize a migration, and its pros, cons, and issues to look out for.

Learning Objectives

  • Understand the main scenarios and considerations when migrating from SAP to Azure
  • Learn the two methods for getting your data into Azure
  • Understand the difference between homogeneous and heterogeneous migration
  • Understand how the database migration option available in SAP can be used to migrate your data to Azure
  • Learn about the SAP HANA Large Instances service from Azure

Intended Audience

  • Database administrators
  • Anyone looking to migrate data from SAP to Azure


To get the most out of this course, you should have a basic knowledge of both Microsoft Azure and SAP.


The reason for migrating your SAP landscape to Azure will largely determine the migration strategy to employ. For example, if you are currently running SAP HANA on-premises or in a hosted environment, and the hardware is going end of life, or the hosting contract is up for renewal. This will mean a different strategy to one where you want to upgrade from AnyDB to a HANA deployment.

There are four general migration scenarios. The easiest and most well-trodden path is Lift and Shift, where the operating system and database systems you are currently using are available on Azure. Lift and shift is also referred to as a homogeneous system copy. Moving from on-prem Windows Server 2016 or SUSE Linux Enterprise running either SQL Server or Oracle to the same OS and DBMS in Azure is a homogeneous copy.

When your current OS or DBMS systems aren't supported on Azure, but you want to replicate your current environment as close as possible, lift and migrate is the best option. Because either the target OS or DBMS will be different, this is called a heterogeneous system copy. An example of this is moving from either HP-Unix OS or Solaris.

These first two scenarios are SAP system agnostic. That is the type of source SAP system is mostly irrelevant. If you are lifting and migrating a non-HANA system, then it is well worth considering migrating from an AnyDB DBMS to HANA at the same time. While this will involve marginally more effort at the time, you will avoid a future AnyDB to HANA migration, even if that is within the Azure environment. In one respect, this is just a variation on lift and migrate, but in another, it's a greenfield SAP HANA deployment.

The logical extension to migrating from an AnyDB to SAP HANA would be moving to S/4HANA in the same migration process, future-proofing the SAP installation. Support for SAP Business Suite 7 was scheduled to end 31st December 2025 but has been pushed out to 2027 with the option to extend to 2030.

Looking at these different scenarios, we can see that it is not necessarily a one-step process. With the exception of homogeneous lift and shift and exchanging like for like, these steps can involve changing the database provider, upgrading the SAP software, and potentially a Unicode conversion. HP UNIX systems use big-endian, while most modern Linux distributions use little-endian.

Depending on which migration scenario you choose, that is your desired SAP end state; there may be even more additional steps. For example, to meet the minimum requirements for SAP HANA, you will need to be running at the very least NetWeaver 7.4.

Your SAP to Azure migration project could potentially turn into three mini-projects, with the associated testing and downtime. Firstly, upgrading the SAP application software, then migrating from AnyDB to SAP HANA, and finally, the lift and shift to Azure. Because this three-step process is a relatively common and resource-intensive upgrade path, there are several utilities that can simplify the whole process. Software Update Manager (SUM) and Downtime Minimized Option (DMO) are utilities that we'll look at later.

About the Author
Learning Paths

Hallam is a software architect with over 20 years experience across a wide range of industries. He began his software career as a  Delphi/Interbase disciple but changed his allegiance to Microsoft with its deep and broad ecosystem. While Hallam has designed and crafted custom software utilizing web, mobile and desktop technologies, good quality reliable data is the key to a successful solution. The challenge of quickly turning data into useful information for digestion by humans and machines has led Hallam to specialize in database design and process automation. Showing customers how leverage new technology to change and improve their business processes is one of the key drivers keeping Hallam coming back to the keyboard.