Skip to Content
Technical Articles

SAP HANA Update, Upgrade, and Migration | SAP HANA 2.0 – An Introduction

In this blog series you will find quotes, backgrounds, suggested further readings and other information related to my latest book SAP HANA 2.0, An Introduction published by SAP Press.

In this blog we cover updates, upgrades, and migration scenarios. Are you ready?


The Road Ahead

Clear Path to Plan

In a recent blog post, SAP HANA product management announced some minor changes to the end-of-maintenance schedule for SAP HANA. Basically, one month was added for the SAP HANA 1.0 SPS 12 release and two for SAP HANA 2.0 SPS 04 aligning both to end of June 2021. Time of writing, that’s 9 months ahead: time to start planning the update or migrate to SAP HANA 2.0 SPS 05:

The good news is that like SPS 12, the SPS 05 release is supported for 5 years until end of June 2025.

For the official communication, see SAP Notes

In these notes you also find the links to SAP Release Strategy and the SAP HANA Revision Strategy documents.

A Strong Foundation

We already addressed the new features and highlights of the SPS 05 release in a previous blog but to summarise (leaving out the updates to the SAP HANA 2.0 cockpit administration tool), we can say that SPS 05 mainly provides enhancements to existing features. Capabilities introduced earlier are now marked ready for production like the local secure store (LSS) for master and encryption root keys with key store management (KMS) integration. Another example is the availability of the built-in data tiering feature native storage extensions (NSE) on multiple host systems (scale out).

Of course, when we zoom in we find interesting functionality added to features like SAP HANA Spatial and SAP HANA Graph. However, for the latest and greatest we can now also consider SAP HANA Cloud, database-as-a-service, which has been architected to complement SAP HANA platform on-premises and not to replace it: a single gateway to all your data.

In other words, SAP HANA 2.0 SPS 05 is not Pandora’s box. No major new or re-architecturing as in the past with tenant databases and SAP HANA XS Advanced. Most functionality has already matured over one or more Support Package Packs and multiple revisions: a strong foundation for continued innovation.


Big Steps and Small Steps

Updates and Upgrades

In the spirit of CI/CD (continuous integration/continuous delivery, for those that have not take DevOps 101 yet), SAP HANA revisions are released at regular intervals; as often as every 5-6 weeks in the early days of the appliance although the pace has slowed down considerably since. Revisions contain security updates and corrections (bug fixes in the vocabulary of the developer) but no new functionality. When you are running SAP HANA 2.0 SPS 05 (revision 50, that is) and you install revision 51 this is considered as an update.

New features are introduced with support package stacks (SPS). To enjoy the new capabilities, you will need to upgrade, for example from SAP HANA 2.0 SPS 04 to the latest SPS 05 release. Technically, this is the same as an update as we are going from one revision to the next but as we now activate new functionality a bit more planning and testing comes into play. As a rule, you can update and upgrade your database from any revision but like with most rules there are some exceptions. Before performing an upgrade make sure to find our whether your system is the rule or the exception.


Besides updates and upgrades we also have migrations of course, which could be a little bit more complicated depending on where we are coming from and where we want to go. In some cases, we need to migrate as part of the upgrade. This concerns SAP HANA systems running on IBM Power Systems Big Endian distributions, for example, or when we switch from the SAP HANA XS classic model to advanced.

Migration is also on the agenda when we decide to change the database layer to SAP HANA, move the application stack to SAP S/4HANA, or want to say goodbye to the data center and move to the cloud. For database and application migrations, SAP has launched programs like the Database Migration Factory and S/4HANA Movement. SAP’s cloud provider partners, the ‘hyperscalers” have given cloud migration some thought as well. More on this below.


Plan Your Upgrade

To-Do List

When we upgrade from SAP HANA 1.0 to SAP HANA 2.0 we are looking at a major version change and this requires careful consideration and planning. Here are some of the required and optional steps.


  • Test, test, test
  • Upgrade to latest CPU generation (recommended)
  • Update the operating system
  • Convert to tenant databases
  • Verify backups support persistency changes
  • Verify revision update path


  • Migrate to SAP HANA XS Advanced
  • Transition to SAP HANA Cockpit 2.0 or update SAP Solution Manager
  • Install the EPM-MDS plugin

Even when the business applications remain as-is we need to thoroughly test the effect of the upgrade. SAP HANA 2.0 introduces many architectural changes which could impact performance or introduce side-effects. For the details and additional references (KBAs and Notes), see

The to do list comes from SAP Notes

See also the SAP HANA Master Guide

Hardware Upgrade

IBM Power Systems supports both the Big Endian (BE) and Little Endian (LE) architectures but a strategic decision was made by IBM and Red Hat / SUSE Linux to continue with LE only in the future. As a consequence, should you be running SAP HANA 1.0 on IBM Power Systems BE you need to migrate to LE.

Running the latest software version on older hardware rarely works out very well and SAP HANA is no exception. When you are running SAP HANA on Intel architecture you need to upgrade to at least Haswell, released in 2013 to succeed Ivy Bridge. After Haswell, Intel released Broadwell, Skylake, and Cascade Lake, which may perform even better.

Operating System Update

SAP HANA 2.0 SPS 05 requires the latest SUSE Linux Enterprise Server (SLES) and Red Hat Enterprise Linux (RHEL) operating systems releases. The optimised “for SAP Applications” editions of the OS are highly recommended.

  • RHEL 8.1 (7.7) for SAP Applications / SAP HANA
  • SLES 15 SP1 (12 SP5) for SAP Applications

For the recommended settings and additional information, see

Tenant Databases (fka MDC)

In the original SAP HANA architecture each system (SID) hosted a single database. SPS 09 (2014) introduced the multitenant database container (MDC) architecture with each system hosting a system database and one or more tenant databases. Another 3 years laters with SAP HANA 2.0 SPS 01 (2017), this architecture was promoted to the default and only supported one.

When upgrading from SAP HANA 1.0 you will need to make a system conversion. This is a simple operation using the HDBLCM database lifecycle management tool. However, operating procedures will need to be updated as well to include system database backups, firewall reconfiguration for additional port ranges, etc.

Besides the changes introduced with tenant databases (the term MDC is no longer used), there are also other changes in the metadata persistence layer and the column store persistence format which may invalidate older backups. Here as well: test, test, test.

XS Advanced

We have already covered the XS Advanced / Cloud Foundry topic in much detail elsewhere in a blog, no need to repeat ourselves here, but in short with SAP HANA 1.0 SPS 11 (2015) a new architecture was added for the built-in application development and runtime environment SAP HANA extended application services, SAP HANA XS in short. Although this new architecture had nothing in common with the initial version, the decision was made to keep the same name and tag the architectures as “model”: XS advanced (XSA) and XS classic (XSC) model.

For SAP HANA 2.0, XSA is the default framework for application development while XSC and the associated SAP HANA Repository and SAP HANA Studio IDE have been marked as deprecated. Deprecated means that the software is no longer included in the next major release, which is the case for SAP HANA Cloud. Deprecated does not mean it is no longer supported. It is perfectly fine to continue using SAP HANA XS classic apps and the SAP HANA studio with SAP HANA 2.0 SPS 05 until at least end of June 2025.

For this reason, XSA is an optional upgrade consideration: It is up to you. However, should you want to continue working with your XS classic apps after 2025, you should at some point think about XS app migration. The good news is that there is a well-documented Migration Guide and a Migration Assistant to automate most of the migration.

SAP HANA Cockpit 2.0

As SAP HANA Cockpit supports both SAP HANA 1.0 and 2.0 releases we can be short about this topic as most enterprises have already implemented this tool to administrate their SAP HANA database landscapes. SAP HANA cockpit is also the tool used (as-a-service) for SAP HANA Cloud resulting in a close to zero learning curve for hybrid and multicloud administration.

In case you prefer to use SAP Solution Manager, some updates and configuration changes are required.

You could, if you wanted, continue to use the SAP HANA Studio Administration perspective for system administration except that for all functionality introduced after SAP HANA 1.0 SPS 12 (2016) you would need to use the SQL Console as there is no corresponding user interface available to administrate user groups, native storage extensions, certificates, SAML and JWT providers, etc., etc. (the list is long).


The InformationAccess or InA service was conceived back in the days to enable web client access to SAP HANA models for analytic clients over HTTP/S. It leverages the XS classic architecture and is no longer included with SAP HANA 2.0 by default. To enable this functionality you need to install the plugin for EPM-MDS (Enterprise Performance Management – Multidimensional Services).

Installing the plugin is easy. Making it work can be a little less obvious in particular when reverse proxy, CORS, and SameSite updates are involved but there are video tutorial series that explain exactly what needs to be done.



Should the upgrade inspire you for more ambitious projects, here are some pointers with additional information.

Database Migration

As soon as SAP NetWeaver Application Server (AS) ABAP was powered by SAP HANA, tools became available to facilitate database migration from anyDB to SAP HANA, specifically the Database Migration Option (DMO) of the Software Update Manager (SUM), part of the Software Logistics toolset.

Database Migration Factory

More recent and broader in scope, SAP also launched the Database Migration Factory program. This includes not only custom and ISV applications running on anyDB but also Sybase and SAP business applications. The service offering includes the Advanced SQL Migration tool.

Application Migration: Move to S/4HANA | Cloud

In case the focus is on migrating your vintage SAP ERP or SAP Business Suite system to latest-and-greatest, state-of-the-art SAP S/4HANA or SAP S/4HANA Cloud, you can join the S/4HANA movement.

Move to SAP HANA Cloud

In case you are considering to say goodbye to your data center, at least for running SAP HANA on-premises, you could migrate to SAP HANA Cloud, database-as-a-service. This also applies if you are running SAP HANA inside a virtual machine (VM) in the data center of a public cloud provider and even, and this may come as a surprise, in case you were an early adopter of the SAP Cloud Platform SAP HANA Service. For some scenarios, a migration service and tooling is (becoming) available. For more information about migrations to SAP HANA Cloud, see


Should you consider to go all the way into cloud computing and want some advice about migration patterns, the 6Rs, and whether to lift-and-shift or lift-tinker-and-shift, here is some guidance from our cloud provider partners.


Connect and Share

Post a comment, share on social media, and/or give a like. Thanks. If you would like to receive updates, connect with me on


SAP HANA 2.0 – An Introduction

Just getting started with SAP HANA? Or do have a migration to SAP HANA 2.0 coming up? Need a quick update covering business benefits and technology overview. Understand the role of the system administrator, developer, data integrator, security officer, data scientist, data modeler, project manager, and other SAP HANA stakeholders?

My latest book about SAP HANA 2.0 covers everything you need to
know. Get it from SAP Press or Amazon:



SAP HANA 2.0 Certification Guide: Technology Associate Exam

Preparing for your SAP HANA 2.0 technology associate exam? Make the grade with this certification study guide! From installation and configuration to monitoring and troubleshooting, this guide will review the key technical and functional knowledge you need to pass with flying colors. Explore test methodology, key concepts for each area, and practice questions and answers.

Your path to SAP HANA 2.0 certification begins here! Pre-order from SAP Press:



For the others posts, see


You must be Logged on to comment or reply to a post.
  • Hi Denys,

    Many thanks for the blog. It is really informative and helpful.

    I have one question regarding homogeneous system copy of SAP Hana Database using HSR. Our focus is on minimized downtime. However wanted to know what are the limitations for this method.
    We are moving from on-prem to Public cloud and hence would like know more about the method, like how much should be the Network Bandwidth, what should we follow post takeover in the target VM etc. Could you please suggest.


    • HANA only or ECC or S/4HANA also?  Build app server in cloud too and just perform a take over so cloud HANA is primary, start app servers and off you go.  Use iperf to test network performance and see if it’s compliant with the HCMT/HWCCT tools/recommendations.  I’ve done this on GCP & AWS – although HSR did most of the heavy lifting…

      • Many thanks for your reply. Multiple applications are there including S/4 Hana, NW 7.52,ECC etc. The issue is I have to go on with the approach with existing setup as multiple vendors are involved. So I am looking for the baseline information, limitation etc.

        In the SQL statement ZIP there is a SQL “HANA_Replication_SystemReplication_Bandwidth” to determine the required bandwidth to move the persistent data over a Day. I can multiply with the factor to determine the BW required for me. For Example,  lets assume using the SQL I find to move 3 TB of Data I need 1GB/Second, so If I have a downtime windows of 8 hours then I need 3GB/second BW.

        But this is my way of calculation, rather assumption and the same will not hold in front of multiple vendors when we present the same. Hence wanted to check if we have any document, information which states about the calculation, limitation of BW.


        Second point is, is there any recommendation to setup the multitier replication for production ? As i Know I can’t link the Production directly to target as it can choke the live system, though we will use ASYNC mode.

        So my understanding is we will link the DR to target. The replication path Production —-Production DR —Target Hana DB in public cloud. In that case what recommendation I need to follow in terms of replication queue,buffer or any other parameters.

        Best Regards,