Skip to Content
Technical Articles

HANA 1.0 upgrade scenarios

A lot of customers want to upgrade their HANA 1.0 databases toward to HANA 2.0. Usually this is not a big deal, if you have enough downtime. You can go straight on from HANA 1.0 >= 122.04 to any supported HANA 2.0 revision. The MDC conversion will take place automatically during the upgrade procedure. You need a revision >= 122.04 because there were some changes in the persistence layout which are needed for an upgrade to HANA 2.0 (see note 2372809). Best practice is to go for the latest HANA 1.0 revision and upgrade to the latest HANA 2.0 revision. But be careful if your HANA 1.0 SPS12 revision is newer than the HANA 2.0 revision it is not supported to upgrade (see note 1948334). Also check if your application is supported to run on HANA 2.0.

Another possible way (kudos to Nicholas Chang) is to create a backup on source DB and restore this one on the new target DB which is installed directly on HANA 2.0 with MDC. Here the MDC conversion will take place during the recovery procedure. But this can take a lot of time depending on the size and the underlying architecture, but is a valid option if your current hardware is not supported for HANA 2.0 or you want to change the location anyway. Details can be found in note 1642148.


But some customers are using HSR (HANA System Replication) and want to profit from the near zero downtime update (NZDU) feature with DBSL suspend (1913302 / 1984882). Another scenario is if you want to change the data center. For instance you want to change your hoster.
Here you want less downtime as possible. This means no upgrade steps between. This can be create some trouble because since HANA SPS01 the standard operation mode is MDC (see note 2423367). Does it work to sync from SDC (Single database container) to MDC? Just simple: not touching the old HANA instance and sync with HSR to the target HANA 2.0 revision. Is this possible?

There is some information in the documentation and notes which can be very confusing:

SAP HANA Tenant Databases Operations Guide
You can perform a near-zero downtime update of a single-container system to SAP HANA 2.0 SPS 01 in a system replication landscape. A single-container system will be automatically converted to a tenant database system during the update. Converting an SAP HANA system to a tenant database system is permanent and cannot be reversed.


– The statistics server is not running as a separate server process (statisticsserver), but instead as an embedded service in the master index server. If this is not the case, migrate the statistics server to the embedded statistics service as described in SAP Note 1917938.
– The SAP HANA system has been installed with its server software on a shared file system (export options rw, no_root_squash).
– The SAP HANA system has been installed with the SAP HANA database lifecycle manager (HDBLCM).
– You are logged on as the system administrator user <sid>adm.

Perform one of the following procedures to update your system replication landscape to SAP HANA 2.0 SPS01:

Near-Zero Downtime Update (NZDU)

1. Update the secondary system using the SAP HANA database lifecycle manager. The migration to a tenant database system is triggered automatically.
2. Wait until the update has finished and all systems are in sync again. The replication will be possible in this situation although the primary is still a single-container system.
3. Perform a takeover to the updated secondary system. Only now the migration to a tenant database system is finalized for the secondary.
4. Update the primary system using the SAP HANA database lifecycle manager. The migration to a tenant database system is done automatically.
5. Wait until the update has finished and the primary system is up and running again.
6. Register this former primary system as the new secondary to the new primary (former secondary).


1999880 – FAQ: SAP HANA System Replication
Can I set up system replication between systems with different topologies?

The topology of primary and secondary site of a system replication scenario must be identical. As a consequence it isn’t possible to replicate from non-MDC to MDC (SAP Note 2101244) and vice versa, and it is also not possible to replicate from single-node to scale-out and vice versa.

2101244 – FAQ: SAP HANA Multitenant Database Containers (MDC)

Is it possible to convert SAP HANA 1.0 single container system to SAP HANA 1.0 MDC system with HANA System Replication?

No, conversion from single container to MDC with HANA System Replication is not supported. You would need to disable replication before starting the conversion else the conversion on secondary would fail with the below error.

SAP HANA Lifecycle Management – SAP HANA


10:03:43.088 – INFO: Start Date: 2018-10-26 – hdblcm

10:03:43.104 – INFO: Performing secondary system check

10:03:43.104 – ERR : The SAP HANA System cannot be converted to multitenant database containers, because it is a system replication site

10:03:43.105 – INFO: Summary of critical errors

10:03:43.104 – ERR : The SAP HANA System cannot be converted to multitenant database containers, because it is a system replication site

You would need to disable replication and need to perform the conversion on primary and all connected secondaries in case you have multitier replication.

Ok so there is some information that have to be sorted:
– it is not possible to sync from SDC to MDC
– it is possible to sync from MDC to MDC
– it is possible to sync HANA 1.0 revisions with HSR and upgrade the secondary to HANA 2.0 and sync back



In one of my projects we had a very special case. The old HANA 1.0 SDC instances should not be touched anymore and the target was on the IBM Power platform (PowerPC). This means SLES12/15 or RHEL >=7.2 on Little Endian and only HANA 2.0.

HANA 1.0 122.x SDC ====> HANA 2.0 >= SPS03 MDC

Do you see any direct supported scenario which is working and could solve this issue?



This is not supported by SAP. There is no direct way which is officially supported. So, why SAP creates such fundamental features like MDC which you have to use, and they are not compatible at all?

There are 3 possible solutions for this case:

1) HSR: HANA 1.0 SDC <=> HANA 2.0 SPS00 SDC

The easiest way which won’t touch the old source instance is to install a HANA 2.0 SPS00. Because SPS00 was the last official support package where you can choose between SDC and MDC. Just install it as SDC (interactive mode) und sync the HANA 1.0 with system replication.

But there is snag in it. You can only sync in a HANA which has the same revision or is newer. This means the last SPS00 revision was 2.02 and is not downloadable anymore (only with an OSS ticket). This means this solution is working from 122.04 through 122.10. If your source revision is above, you have to find another solution. So, if you follow the recommendation of SAP and upgrade your source revision to the latest one, you definitively can’t use it.

The most HANA 1.0 systems which I have seen are still on 122.05 or 122.08. Here the solution would be working.

2) HSR: HANA 1.0 MDC <=> HANA 2.0 MDC

This would be the easiest way, but you are touching the old source instance, because you have to convert it to MDC. This means an additional downtime. If your HANA 1.0 revision is newer than the latest HANA 2.0 one this solution won’t work.

For instance, the latest HANA 1.0 SPS12 revision is 122.22. The latest HANA 2.0 SPS02 is 24.07 and SPS03 Rev. 35. Currently it is not possible to upgrade or using HSR although your topology would allow it.

3) HSR: HANA 1.0 SDC <=> HANA 2.0 SPS01/02 SDC

HANA 2.0 SPS01/02 with SDC? Yes, this is not a typo. SAP integrated a backdoor if something won’t work with MDC. So, there is a hidden option/parameter:

./hdblcm --db_mode=single_container

This “dirty” option is still working though all revisions of SPS02. Since SPS03 they deactivated this one:

HANA 2.0 SPS02 Rev. 24.06

./hdblcm --action=install --ignore=check_signature_file --db_mode=single_container
SAP HANA Lifecycle Management - SAP HANA Database
Scanning software locations...
Detected components:
    SAP HANA Database ( in /int/software/sapcd/db/hana/hana_rev20_024_6/SAP_HANA_DATABASE/server
    SAP HANA AFL (incl.PAL,BFL,OFL,HIE) ( in /int/software/sapcd/db/hana/hana_rev20_024_6/SAP_HANA_AFL/packages
    SAP HANA LCAPPS ( in /int/software/sapcd/db/hana/hana_rev20_024_6/SAP_HANA_LCAPPS/packages
    SAP HANA Database Client ( in /int/software/sapcd/db/hana/hana_rev20_024_6/SAP_HANA_CLIENT_LINUX/client
    SAP HANA Smart Data Access ( in /int/software/sapcd/db/hana/hana_rev20_024_6/SAP_HANA_SDA/packages

SAP HANA Database version '' will be installed.


HANA 2.0 SPS03 Rev. 35

./hdblcm --action=install --ignore=check_signature_file --db_mode=single_container
SAP HANA Lifecycle Management - SAP HANA Database
Scanning software locations...
Detected components:
    SAP HANA Database ( in /int/software/sapcd/db/hana/hana_rev20_035_0/SAP_HANA_DATABASE/server
    SAP HANA AFL (incl.PAL,BFL,OFL) ( in /int/software/sapcd/db/hana/hana_rev20_035_0/SAP_HANA_AFL/packages
    SAP HANA LCAPPS ( in /int/software/sapcd/db/hana/hana_rev20_035_0/SAP_HANA_LCAPPS/packages
    SAP HANA Database Client ( in /int/software/sapcd/db/hana/hana_rev20_035_0/SAP_HANA_CLIENT/client
    SAP HANA Smart Data Access ( in /int/software/sapcd/db/hana/hana_rev20_035_0/SAP_HANA_SDA/packages

Configuration error:
  Checking command line parameter '--db_mode' failed.
    Value 'single_container' is invalid. Please use one of: multiple_containers

This means you can create an SDC instance and be able to use HSR. I would prefer this option because you can avoid a lot of known issue regarding HANA 2.0 SPS00 (option 1) during HSR and don’t have to touch the source instance like in option 2.

After your instances are in sync you can upgrade to the latest HANA 2.0 SPS03/04 revision incl. MDC conversion during the upgrade. The only disadvantage of this scenario => it is not officially supported by SAP. I have successfully tested it with some revisions of HANA 1.0 SPS12 and as target HANA 2.0 Rev. 24.06.

Upgrade HANA 2.0 SPS02 Rev. 24.06 SDC  to SPS03 Rev. 35 MDC:

Summary before execution:
SAP HANA Database
   Update Parameters
      SAP HANA System ID: AN1
      Remote Execution: ssh
      Update Execution Mode: optimized
      Database User Name: SYSTEM
   Software Components
         Do not install
         Do not install
      SAP HANA Database
         Update from version to
         Location: /int/software/sapcd/db/hana/hana_rev20_035_0/SAP_HANA_DATABASE/server
      SAP HANA Database Client
         Update from version to
         Location: /int/software/sapcd/db/hana/hana_rev20_035_0/SAP_HANA_CLIENT/client
      SAP HANA Smart Data Access
         Do not install
Note: The upgrade of SAP HANA Database to this version will convert your system to multi-tenant database containers. This is a mandatory step. For more information, see SAP Note 2423367.

Do you want to continue? (y/n): y


For all customers and all upcoming migration and transition scenarios it would be great if SAP can create a supported solution, because if you have to convert the old system you have to adjust your concept and test an old HANA revision which you want to deactivate. I would appreciate any direct solution for this issue. In the next years a lot of customers will face such a situation. May be Ralf Czekalla or Craig Cmehil can address this topic.


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

    Thanks for the well written blog, as always!

    Is this blog focusing on the NZDU with HSR?

    Just for sharing, otherwise the other option is using backup/restore. A source HANA 1 with SDC can be restored to a HANA 2.0 and the conversion will take place automatically. We've tested this solution with target >= HANA 2.0 SPS2 and it worked fine. And there's a note that said this solution is supported as well.



    Nicholas Chang

    • Hi,

      I assume the goal is to achieve a minimized downtime. Especially for big systems or transitions Backup/Restore is only the second best solution 😉


      But even for small systems HANA 1.0 to 2.0 replication would be great as you could use your 'normal' takeover/maintenance concept, especially when you operate many HANAs.




    • Hi Nicholas,

      you are completely right. The way using backup/restore directly into HANA 2.0 is working independly of MDC/SDC. The focus of the blog was the transition with HSR, but I will add your follow up info to finalize the options.



      • Hello Jens

        Thanks for the nice Blog.

        So whatever it takes: I will never be able to preserve my SDC once I want to go to HANA 2.0 SP03 and higher, right?

        Best regards Roland

        • Hi Roland,

          correct, there is currently no (official) way to keep your SDC system with SPS03 up and running. So you have to say goodbye to SDC in HANA 2.0, because for SPS02 only some months are left for maintenance. But chin up, HANA 1.0 is in support till 2021 🙂






    • hi Nicholas,


      May I kindly ask yo uwhich sap note explicetly mentions that going from  HANA 1.0 SDC to 2.0 MDC via backup/restore is supported.

      SAP note  1642148. does not say that, it just says going from a lower version to a higher version, like going from 1.20 to 1.22. nothing about tenants.

      Actually, sap note 2141670 - Backup & Restore from a single tenant database into one tenant of a multitenant database fails  states the oppsite.

      MDC conversion WILL NOT take place during the recovery, you need to do it manually before the recovery.



  • Hi Jens,

    Thanks for the great article. We're planning to upgrade our Production HANA DB from to HANA 2.0 SPS 3 Rev 36.

    Currently the HANA replication is configured as A-> B (sync), B-> C (async). Site C being the DR site. We have taken some time as a planned downtime window and wish to upgrade the DB as per below so that we need not perform a takeover.

    1. Lock users
    2. Stop SAP
    3. Upgrade Site C - DR DB
    4. Stop Failover between A and B, (put cluster in maintenance mode)
    5. Upgrade Site B
    6. Upgrade Site A
    7. Re-Enable failover between Site A and Site B
    8. Start SAP
    9. Unlock users


    Could you please let me know if the above steps are ok from upgrade perspective. ?Do we need to change anything with respect to replication among these DB servers.?

    We'll be locking the users and stopping the SAP applications, so that before we start upgrading the DR, almost everything is in sync. and once we upgade HANA on all the Sites we can start the SAP applications again.

    Thanks again.



    • Hi Shitiz,


      is it planned to change something on OS level? Please check linux parameter and the needed workarounds with the new revision. Therefor you can use the known issue collection notes and the hot news of SPS03.

      Regarding the steps: if you stop the application you don't have any side effects regarding logs. But please follow the steps mentioned in the official HSR document for HANA 2.0. You have to take attention to some addons or Delivery Units.

      HANA 1.0

      HANA 2.0

      Please add a consistency check for catalog and tables before you start your application again. Execute the parameter check and the mini checks in SQL collection (note 1969700). Also execute the installation check with hdblcm to verify the DB software.




  • Hi Jens Gleichmann,

    Thank you so much for writing this blog! This is really useful.


    However, have you ever upgraded HANA1.0 to 2.0 with MCOS scenario ?
    (Multiple Components on One System).

    Our DR-site is based on cost-optimized model. So on DR-site, we have 3 Hana 1.0 DB instances installed in the same host. (DEV, QAS and PRD_seondary)


    Since there's no any information about upgrading HANA to 2.0 on MCOS scenario, we really wonder that if we firstly upgraded at DEV. DEV will be convert automatically from SDC to MDC.

    At this point, what will happen to QAS and PRD_rep ? Are they still able to operate as normal?

    Cause now, we will have multiple instance with different version (HANA 1.0 & HANA2.0) in the same host. And the SYSTEMDB will be created.


    As my understanding, only 1 SYSTEMDB is allowed to be installed per 1 host. Thus, the next upgrade on QAS and PRD_rep seems not possible...


    Any ideas on this? Could you please help advise?


    Thank you so much.


    Best Regards,


    • Hi RC,

      yes, I also upgraded and worked with MCOS systems. Your scenario is possible without any issues. You can run 3 DB instances (=SystemDBs) on one host. There is no limitiation that you can only run one of it. The only limitiation is that you can’t use the same SID or instance ID:

      If your upgrade your DEV system the other instances won’t be touched. You only should have an eye on the resource consumption. You also should think about to merge DEV and QAS into one DB instance with 2 tenants. Just think about maintenance.

      Where those concerns come from?





      • Hi Jens,

        Thank you very much. We tested upgrading in our lab. And as you said, The systemDBs completely separate to each as long as the SIDs are different.

        Seem like we misunderstood at some point on SYSTEMDB limitation. Sorry about that.

        Next, we're finding out the best approach to merge DEV and QAS altogether into one DB instance as your suggestion.  Creating a new tenant, then restored QAS to it seem to be the easiest way to do so.

        Thanks again for your help! 🙂