In this two-part series, we explore the factors organizations should consider before making the decision to upgrade to SAP HANA 2.0. In Part 1, we review what can be gained from the move. Part 2 will cover the migration itself.
With a new release of SAP HANA on the horizon, many of our customers have been faced with pressure to upgrade their existing HANA 1.0 systems to a more up–to–date version. In this blog post, we will discuss the reasons for upgrading to a HANA 2.0 system, the risks of not upgrading and the benefits an upgrade can bring.
The most pressing reason to start thinking about upgrading to HANA 2.0 is the support schedule for HANA 1.0. In 2016, SAP released HANA 1.0 SPS 12, which they announced would be the final HANA 1.0 version. SAP committed to a five-year support timeline for this version of HANA and encouraged their clients to upgrade to a new version before that period expired. The five–year support timeline ends in May of 2021, which means the end of SAP maintenance on all HANA 1.0 systems. When planning the move to HANA 2.0, it is recommended to upgrade to HANA 2.0 SPS05 in order to maximize the available maintenance window. SAP has committed to supporting HANA 2.0 SPS05 up to June 2025.
With the move to a more recent version of HANA comes new features that were not previously available in HANA 1.0. Significant improvements have been made to multiple components of the HANA database. From a security perspective, HANA 2.0 allows for encryption of all volumes on the HANA server including log volumes, which was not possible before. There are also additional capabilities around encryption key management and the ability to update encryption keys using SQL and a dedicated password file. A new role, ENCRYPTION ROOT KEY ADMIN, has also been added that is responsible for administering encryption.
From a modeling perspective, HANA has moved away from the old analytic and attribute views, utilizing differing forms of calculation views to handle all modeling. Attribute views, which hold master data information, have been replaced with dimensional calculation views that allow for more logic capabilities. Similarly, analytic views have been replaced with star-join calculation views for similar reasons. Both versions of calculation views allow developers to execute more complex logic optimally compared to their legacy counterparts.
In addition, the XS engine has been redesigned, now referred to as XSA. XSA is required in future versions of HANA and will become more integral to the HANA system as versions increase. Moving to XSA now would help position the landscape for future changes and updates to HANA as well as ensure SAP software integration. Hana’s analytics capabilities have also evolved with enhancements to the search, text analysis, machine learning and graph data processing capabilities of the system. Other upgrades are worth mentioning include ease of administration through additional functionality in the SAP HANA cockpit, multi-tiered storage integration and advanced multi-tenant solutions.
The third major reason upgrading is recommended is compatibility with other software. New versions of SAP and non-SAP products are being released with more capabilities and features. In order to be able to use these new products, it is likely the HANA database will need to be upgraded to maintain compatibility and support. For example, if a client is attempting to move to SAP BI 4.3, they will be required to have a version of HANA that is at least HANA 2.0 SPS03. As SAP continues to move forward with new versions of existing products, the compatibility with the HANA 1.0 system will continue to decrease. Staying on HANA 1.0 means limiting the upgrade capability of any software or system that depends on HANA, which can result in lack of functionality or features present in newer versions of software.
Move to Cloud
As with any upgrade today, implementation leads will be tasked with deciding between on-prem or cloud solutions for the upgraded SAP HANA system. We are often seeing a cloud solution as the best option over an on-prem solution for several reasons. Cloud solutions are less expensive than buying traditional hardware as companies only pay for what is needed. A cloud deployment also offers a quicker set-up time as physical hardware does not need to be installed and configured. With that, clients can also leverage the cloud provider to manage all hardware and remove that piece of the landscape entirely. Cloud solutions also make back-up and recovery operations much simpler due to the integration of native backup and recovery solutions from the cloud provider. Utilizing these backup offerings makes it easy to configure snapshots, volume backups and retention policies. Cloud also offers multiple other advantages in the way of scale-up/scale-out, security, traffic management, high availability and monitoring that makes it ideal for most deployment scenarios.
There are, however, a few situations where an on-prem solution is preferred over a cloud solution. Companies with robust network security infrastructures may have a difficult time opening the required connections to a cloud network without significant review (if policies allow the connections to be opened at all). In this example, an on-prem solution would be preferable as there is more room for networking configurations for the server. An additional consideration for on-prem deployments would be network bandwidth. A cloud network connection can never increase network speeds, but it can decrease speeds depending on how the company’s network is structured. If a client has a 1Gbps pipe on-prem, but only a 100Mbps pipe in the Azure network, the Azure network creates a bottleneck for data to be transferred. Most cloud providers have options available for increased network bandwidth, dedicated network throughput, and direct data center to network connections, these come at a cost that will need to be factored into the deployment decision.
Later this week: Part 2 will provide details on migration options for those who are ready to plan their transition to HANA 2.0.