Migration readiness
This section will cover the various ways in which you can prepare to migrate your SAP workloads over to Azure. Let's begin with the first thing to consider: when should you migrate?
When to migrate
There are three main factors that determine when is a good time to migrate your SAP workloads to Azure, and for many customers it may be some combination of all three:
- Your existing infrastructure is due for a refresh, and you must decide whether to refresh what you have today or use this as an opportunity to migrate to Azure.
- Your existing outsourcing, hosting, or co-location contract is up for renewal and this provides an opportunity to look at different hosting options, such as Azure.
- You are planning a migration to SAP Business Suite on HANA, SAP S/4HANA, SAP BW on HANA, or SAP BW/4HANA, and you want to avoid the capex cost of purchasing new infrastructure to run SAP HANA, and also want the agility and flexibility offered by Azure.
Ultimately every customer that plans to continue to run SAP must plan to move to SAP S/4HANA before the deadline of 31st December 2025, which is the current end of support for SAP Business Suite 7 core application releases and SAP Business Suite powered by SAP HANA29. Whether you are ready to move today, or planning to move in the next few years, moving your existing SAP estate to Azure now will provide much greater flexibility for the future.
From an infrastructure perspective one of the biggest challenges for customers when moving to SAP HANA is that the hardware required to run SAP HANA is very different to that required for AnyDB. SAP HANA is an in-memory database, which by default loads all HANA table data into memory at startup and requires additional temporary memory as working memory to allow the table data to be processed; for example, for table joins. While a VM with 64 GiB memory may be adequate to run a productive AnyDB instance with 2 TiB of data on disk, to run that same database on HANA could require up to 4 TiB memory; 2 TiB for table data and 2 TiB for temporary memory, based on SAP recommendations. In reality there will generally be some reduction in size of the data when migrating to SAP HANA, and potentially even more when migrating to SAP S/4HANA, so 2 TiB or even 1 TiB of memory may prove sufficient, but still that is a lot more than 64 GiB.
By moving to Azure when your next hardware or data centre refresh comes around allows you to better prepare for the migration to SAP HANA. If you make another Capex investment, then that will generally be depreciated over three to five years. If during this time you decide to move to SAP HANA then you will need to purchase new hardware for SAP HANA, while still depreciating the hardware you already have for AnyDB. This can play havoc with budgets, particularly if you decide to buy the new SAP HANA hardware as a further Capex investment. By moving to Azure you can instead stand up today the VMs you need for AnyDB, and when the time is right to move to SAP HANA simply stand up new larger VMs for SAP HANA, and once the migration is complete, shutdown, delete, and stop paying for the AnyDB VMs.
If you are running SAP on-premises and considering a migration to SAP HANA today, then once again deploying SAP HANA in Azure has many benefits. Firstly if you are still depreciating the existing hardware for your on-premises AnyDB then deploying SAP HANA in Azure will normally be classed as Opex, so will not impact your Capex budget in the same way, although this may depend on internal accounting practices along with local regulations. This may well reduce some of the financial challenges.
Also, customers moving to SAP HANA are often uncertain as to the exact size that their databases will be. If it is a net new implementation, for example a greenfield implementation of SAP S/4HANA or SAP BW/4HANA, then it can be hard to size the initial system and also predict future growth, although the SAP Quick Sizer can help here. If it is a migration to SAP HANA or a conversion to S/4HANA or BW/4HANA, then SAP do provide reports that you can run to estimate the future size of your SAP HANA database30. But even then, this is just an estimate, and predicting future growth can be challenging.
In most cases if you are deploying SAP HANA on-premises then you will use an SAP HANA Certified Appliance31. With any capex investment in hardware for SAP it is normal practice to try and predict the size that you will require for the depreciation life of the hardware; typically you are predicting three or even five years ahead. With all the uncertainty over initial sizing and future growth you must choose between choosing a larger appliance and simply accept the high cost, to minimize the risk of outgrowing the appliance, or choose a smaller lower-cost option and risk running out of capacity.
To make matters worse most appliance vendors have to switch server models as the memory grows, so expansion part way through the life of an appliance may in fact mean purchasing a net new appliance.
With Azure these problems mostly go away. With SAP HANA certified Azure VMs you can start with what you need today, and simply resize the VM as and when it is required. This keeps your initial costs lower, by not over provisioning, but still allows you to scale as the database grows. In addition, you can easily scale up the SAP application tier, adding additional application server VMs to address peak workloads, and shut them down again when not required.
In addition, most customers know that they should right size before migrating to SAP HANA, reducing capacity through data archiving or deletion, but the reality is this may not be possible. SAP has always recommended that customers implement Information Life cycle Management for data held in SAP to improve performance, reduce infrastructure costs, and provide governance, risk, and compliance for enterprise data. However, many organizations fail to do this, because no data retention policies exist, and for many years now infrastructure has become faster and cheaper, so it has not been essential.
SAP HANA does change the economics of this as the cost per TB of storing data in memory rather than on disk is typically an order of magnitude higher. It does not take as long to build a compelling business case for archiving when the additional infrastructure costs for SAP HANA are considered. While the project timescales may make right sizing before migration impossible, in Azure it is much easier to stand up an oversized VM for the initial migration, then archive, delete, and right size the VM once the data is in Azure.
Migration order
You may be asking whether SAP should be the first workload that you migrate to Azure, or whether you should leave it until later in your cloud migration strategy, or even right to the end. The answer is that there is no right or wrong answer, and we see customers where SAP is first and others where it is towards the end: it normally depends on the compelling event.
Some of you will have already started to deploy other workloads in Azure, having your cloud adoption framework in place, when the compelling event to migrate SAP to Azure comes along. While the foundations may be in place, for many of you SAP will still be the largest and most critical workload that you have yet moved to Azure. So, all the issues around security, scalability, and availability still need to be addressed with respect to SAP before the migration can begin. However, hopefully at least some of the work will have already been undertaken. What is important is that having the Azure foundation in place should speed up the migration process.
Others may be yet to deploy any workloads into Azure when a compelling SAP event arrives. This means a steeper learning curve for you, because you need to understand a lot more about how SAP runs in Azure before you can make the decision that you want to migrate your SAP workloads. For those in this position, this book should help. Starting with SAP does add an additional step to the process because you will need to build the bare bones of an Azure foundation before you can start to deploy SAP in Azure. You wouldn't build a house without first putting in the foundations, so you shouldn't deploy workloads in Azure without first building the foundations.
Types of SAP migration to Azure
Migrating SAP to Azure is no different to any other type of SAP migration. Many customers will already have undertaken a SAP migration whether it be migrating from a traditional Unix operating system such as AIX, HP-UX, or Solaris to Linux or Windows, or migrating from one data centre to another; from old to new on-premises, or on-premises to co-location, managed hosting, or similar. The migration approaches are very similar when Azure is the target; essentially Azure is just another data centre connected to your corporate WAN.
There are two main types of SAP migration to Azure:
- Brownfield: Where you have existing SAP workloads you want to migrate from on-premises to Azure, potentially with an OS or database migration, and maybe an upgrade or conversion
- Greenfield: Where you plan to start afresh in Azure with a new implementation of SAP, whether or not you have existing SAP workloads on-premises
Brownfield migrations are by far the most common, and these in turn fall into four main categories as shown in Figure 1-3:
Figure 1-3: Options for SAP migration to Azure
- Lift and Shift to Cloud: Where the existing OS and DBMS used on-premises are supported in Azure, and you have no plans to migrate to HANA at this time, a lift and shift or rehosting is possible. This is normally referred to as an SAP Homogeneous System Copy and is the simplest type of migration.
- Lift and Migrate to Cloud: Where the existing OS is not supported in Azure – HPE HP-UX/IA64 or HP-UX/PA-RISC, IBM AIX/Power, Oracle Solaris/SPARC, or Solaris/x64 – or there is a desire to change the DBMS, then a lift and migrate or replatforming is the solution. This is normally referred to as an SAP Heterogeneous System Copy and while it is more complicated than lift and shift, there is a well-proven path using tools such as SAP R3load or the SAP Database Migration Option (DMO) of the Software Update Manager (SUM) where the target DBMS is SAP HANA.
- Lift and Shift/Migrate to Cloud, migrate part to HANA: Particularly if facing an OS/database migration this may be a good time to consider migrating at least part of the SAP landscape to SAP HANA, if you have not already done this. Migrating BW on AnyDB to BW on HANA will provide an immediate performance boost and will allow you to start to get familiar with SAP HANA before you migrate to S/4HANA. Importantly, if you are currently using BW Accelerator then that is not supported in Azure and a migration to SAP HANA is the recommended route forward from SAP.
- Transformation to S/4HANA: If facing an OS/database migration, then this could be an excellent time to consider a conversion from ECC to S/4HANA. A basic conversion can be done with minimal disruption to end users and will ensure you are ready for 31st December 2025.
For some of you the move to S/4HANA represents an opportunity to get rid of years of customizations and to standardize business processes possibly using the SAP Model Company. When you originally implemented SAP those customizations may have been essential to meet your business requirements, but as SAP has evolved the functionality has increased and now the standard functionality may better meet your business needs. If this is the case, then you may prefer a greenfield migration.
Microsoft has several customers globally either live with greenfield S/4HANA implementation, or in the process of deployment. A small number are net new SAP customers, but the majority are customers that have been using SAP for 10, 15, or even 20 years, but want to start afresh with S/4HANA. They are deploying S/4HANA in Azure for all the reasons stated above, because they may still be finalizing the sizing, want to start small and grow with their data, and do not want to make large upfront capex investments in the hardware needed to run the SAP HANA database than underpins S/4HANA.
Migration strategies
When it comes to brownfield migrations it is important to plan the order in which the migrations will take place. To some extent this will depend on whether you are planning a homogeneous or an heterogeneous migration, and also the downtime window available for the migration.
A homogeneous migration, or in SAP terminology a homogeneous system copy, is one where there is no change to either OS or DBMS. For SAP workloads in Azure the supported operating systems are Microsoft Windows Server, Red Hat Enterprise Linux (RHEL), SUSE Enterprise Linux (SLES), and Oracle Linux; the latter only for Oracle DBMS. If you are currently running SAP on any other operating system, then you will need to undertake a heterogeneous system copy.
A heterogeneous system copy is one where either the OS, the DBM, or both are changed. This is a well-proven path and SAP have several tried and tested tools for carrying out such migrations. If you need to undertake a heterogeneous migration because you must change the operating system, then this also provides an opportunity to consider changing the DBMS as well.
While SAP used to advise against combining multiple changes into one, it is now common for customers to combine a SAP application upgrade with an OS and/or DBMS migration into a single delivery. If there are problems it can make diagnosing the cause more difficult – was it the software upgrade, the OS migration, or the DBMS migration? – but in terms of testing effort and business disruption it is generally preferred.
Homogeneous migrations are the simplest and offer the most migration options. The simplest solution will be a simple backup and restore, taking a full system backup on-premises, copying over the backup files, and then restoring them into Azure. Where downtime needs to be minimized then DBMS replication can be used to set up a new database instance in Azure and add it as a replication target to the primary on-premises. Because there is no change to the OS or DBMS there will be no compatibility issues.
In contrast heterogeneous migrations, while well proven, are more complicated and will normally require more downtime. The standard SAP tool for this is known as R3load, which exports data from the source database into flat files and then imports the flat files into the target database. While SAP now refer, to using Software Provisioning Manager (SWPM) and Database Migration Option (DMO) of SAP Software Update Manager (SUM) for heterogeneous system copies, in reality R3load remains at the heart of the actual migration process.
When it comes to the order in which to migrate an SAP estate there are two main options as shown in Figure 1-432:
Figure 1-4: Horizontal versus vertical migration
With horizontal migrations each landscape is moved one environment at a time. For example, you may move all the Development environments into Azure, then the QA/Test environments, followed by the Pre-Production environments, and finally the Production environments. In general, this method only makes sense for homogeneous migrations, otherwise you will have incompatibility between the new environments in Azure and the old environments still on-premises; for example, running AIX/DB2 on-premises and SLES/DB2 in Azure.
For heterogeneous migrations it is more normal to use a vertical approach, moving all the environments for a given SAP application at one time. This avoids any issue of compatibility between the Development, QA/Test, Pre-Production, and Production environments. In some cases, you will use a mix of horizontal and vertical approaches, as some SAP applications may undergo a homogeneous migration while others undergo a heterogeneous migration.
Where you have a large and complex SAP estate it may well not be possible to migrate all the SAP applications at once. In this case it is important to carefully plan the order in which the applications are migrated. While you can maintain network connectivity between the applications that have been migrated to Azure and those still running on-premises, in most cases network latency will increase. If you have SAP applications that are closely coupled and highly interactive, then it is desirable to migrate them together as part of the same move group. When planning move groups it is important not just to consider the SAP applications themselves but also any third-party applications that are an integral part of the SAP landscape and may also be closely coupled and highly interactive, as these will need to form part of the same move group.
If the migration is to be phased using move groups, then you will need to plan the order in which to migrate each group. In general, it is better to start with the smaller, simpler, and least critical SAP applications to prove the migration strategy and to gain confidence with operating SAP applications in Azure. The final SAP applications to move should generally be the largest and most critical. The process does not need to be entirely sequential, as for the largest SAP applications you are likely to need to run multiple test migrations to develop the best approach to minimize downtime and complete the process within the allowed downtime window. Resources permitting, this can run in parallel with migrating some of the smaller less critical SAP applications.
As previously mentioned there are now over 800 customers at various stages of deploying SAP in Azure, with some having their full SAP landscape in production. While a few have been new installations of SAP, either because this is the first time they have implemented SAP or because they have chosen the greenfield migration option, in the majority of cases the customer has migrated from on-premises to Azure using one of the methods described here. There is now a wealth of experience within the partner community of managing such migrations.
This section has so far focused on the traditional SAP NetWeaver-based applications, but not every SAP application uses the NetWeaver stack.