Why Now is the Best Time to Move to HANA 2.0 – Part 2: The Migration

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 reviewed what can be gained from the move. Today, Part 2 covers the migration itself. 

Despite the deprecation, SAP HANA 2.0 retains support for XS Classic development objects, including use of the _SYS_REPO user and _SYS_BIC schema. This is in addition to support for XS Advanced development leveraging HDI containers and schema-based objects. The continued support for both methodologies gives companies several options when deciding whether to convert XSC content to XSA during a HANA 2.0 upgrade.  

In this blog, we describe three of those options, along with their relative levels of effort and potential benefits. First is a simple technical upgrade of the HANA database without any content migration or XSA preparation. Second, an upgrade in which the environment is prepared for XSA development and a small set of content is migrated as a proof-of-concept. And finally, a full migration of all content from XSC to XSA.  

Upgrade Only 

The simplest and quickest way to upgrade to HANA 2.0 is to perform a technical upgrade of the platform, either in place or on new hardware, and bring over content as-is without any conversion to XSA. This leverages HANA 2.0’s legacy support for XSC development objects to minimize code changes and testing.  

For example, it is possible to either upgrade HANA in-place using the built-in Lifecycle Management tools or migrate to new hardware or the cloud using a backup-restore method. Either way, once this process is complete, the content on the HANA 2.0 system should be virtually identical to that on the old 1.0 system.  

The benefits of this method are simple. This is the fastest way to upgrade a system to 2.0, and the content will be familiar to legacy developers, requiring no new skills to maintain or enhance. Development can continue with little interruption, taking advantage of the HANA 2.0 engine improvements for more optimized execution.  

However, the drawbacks are also significant. Eventually, whether due to end-of-support in 2025 or the desire to take advantage of HANA 3.0 capabilities, all development must be moved to XSA, and this upgrade-only migration does not bring the environment significantly closer to that methodology. As such, we recommend clients select one of the following two upgrade options to better prepare for the future.  

Upgrade with XSA Preparation 

The second upgrade option is one in which the business prepares for the move to XSA without transitioning the bulk of development. As with the first option, most of the effort is a technical upgrade, moving from HANA 1.0 to HANA 2.0 and bringing over development objects intact. However, here we follow that technical upgrade by preparing the environment for XSA development.  

XSA preparation involves several steps. First, we ensure the HANA environment is running the XSA and HDI components necessary for development and deployment, including Web IDE or Business Application Studio. Occasionally, these components are not installed or configured correctly and require remediation.  

Once the environment is in place, we work with the client to choose a small, independent set of content that would be a good candidate for an XSA migration proof-of-concept (POC). This POC will serve both to validate the environment with an end-to-end deployment and to demonstrate the migration path for XSC content in general. We run that content through the XSA migration tool, mitigating any issues, and then deploy it against the 2.0 HANA server.  

At completion of the work, the client has a fully functional XSA development environment ready for immediate use, plus example XSA content and migration documentation. This puts the organization in a much better position to start XSA migration in earnest than they would be with a technical upgrade by itself. It also allows them to begin XSA development in parallel with existing XSC, which for many organizations are an attractive option for easing into the new methodology.  

Upgrade and Full XSA Migration 

The final upgrade option is a complete migration to XSA. This is a natural progression from the second option, expanding from preparation and POC to a full-scale content upgrade. We begin much the same way, by performing a technical upgrade and ensuring the new environment is prepared for XSA migration and development. From there, however, we begin preparing all content for migration instead of selecting a subset for the POC.  

Preparing the content starts by ensuring all objects are compatible with the XSA migration tool. This means all analytic and attribute views must be converted to calculation views, and all scripted calculation views must be converted to graphical views or table functions. This can be done manually or with the help of the migration tool built into HANA Studio.  

Once all objects are compatible with XSA, the content needs to be divided into self-contained portions for conversion into independent XSA applications. At some companies this may not be possible, particularly those that use conformed dimensions across many packages. In those cases, the content may need to be addressed as a whole.  

We then package and run each portion of the content through the XSA migration tool, which automatically converts XSC objects into their XSA equivalents. If the tool is unable to convert an object, it returns a message indicating the failure and allowing for remediation. We proceed iteratively, fixing objects and rerunning the conversion until all objects pass successfully. At this point, we have a packaged Multi-Target Application (MTA) ready for deployment to HANA.  

The MTA can be deployed in a several ways, including the XSA command line, CTS+ and HTA, but we prefer to use the Web IDE. By using the Web IDE, we more closely mimic deployment through the standard development process and can view the code in a user-friendly interface. It also allows us to easily sync the code with a Git repository for version control. Regardless of the method used, once the MTA has been deployed, the content will be active in HANA and ready to use.  

To learn more about our SAP capabilities, contact us or visit Protiviti’s SAP consulting services.