Gimmal Blog

Read the latest thought leadership and industry news from the experts at Gimmal!

All Posts

How to Migrate Your SAP Database to SAP HANA

I have spoken before about the parallels of the transition of the SAP Application Database to SAP HANA and the gorgeous and dangerous road to Hana in Maui. The actual road to Hana is listed as last on’s list of “Five most dangerous roads in the world,” but it still made the list! The hairpin turns and the drop-offs are part of the reason, although another large part is the ability to get distracted by the views.

This is what makes it the perfect metaphor for what we at Gimmal refer to as the “Road to HANA.” Without a plan and an understanding of what lies ahead, it is possible to get distracted by the (admittedly exciting) prospect of real-time analytics and improved application responsiveness delivered by a fully in-memory database. In this post I will cover the more general case of what you need to consider before making the move to SAP HANA.

Travel Light and Take Only What You Need

The first thing to consider before setting off with your database on the “Road to HANA” is data volume. This is a concern both for the total size of the database as well as individual tables. The total size is important due to the in-memory nature of HANA. The more unnecessary transactional data you have in your database, the more “luggage” you are carrying and will have to account for in your final HANA system. This is also important for individual tables, as tables with large data volumes (i.e. over 2 billion) must be partitioned before migrating to SAP HANA. See SAP Note 1785057 for more details.

Also, in that SAP Note are details about a conversion needed for pool and cluster tables into transparent tables that will happen as a part of migration. This is important for custom code that refers to these tables, and the SAP Note 1785057 contains details about how to make the adjustment is custom ABAP code.

Make Sure to Check Your “Equipment”

When driving the road to Hana, you need to know your vehicle, and to be able to trust your brakes and tires to operate to spec. Similarly when preparing for the “Road to HANA” you need to have certified solutions for hardware and software.

For SAP HANA-Certified hardware, the easiest option is to consider is using a cloud provider. All the major cloud providers are actively building out their cloud offerings for SAP HANA, and the choice of which to go with is a significant decision dependent on too many factors to get into here. Suffice it to say, SAP HANA in the cloud has attracted the major players: Microsoft Azure, Amazon Web Services, and Google Cloud.

If your organization’s strategy is to take an on-premise approach, then SAP maintains a directory of certified hardware here: Certified and Supported SAP HANA® Hardware.

From a software perspective, it is vital to use an SAP-Certified ArchiveLink solution for data archiving, print list archiving, and archiving of unstructured content. Which solution you choose will have a lot to do with how you want to store this data. For example, for an organization using Office 365 and SharePoint Online for their Document Management, the use of a SharePoint compatible and SAP Certified ArchiveLink solution is vital.

Document Management on the Road to HANA

Another vital preparation on the “Road to HANA” is to look for the content that does not belong in your SAP Application Database to begin with: unstructured content or, as it is known more colloquially, documents. These are the supporting documents to the structured transactional data that should be pushed to ECM as part of your standard business processes. I will re-up my piece specifically on this here because it so vital to SAP Application Database health. It is also important for business process health, as storing document content in your organizational ECM allows this content to be found by users where they expect business document content to be stored. This consistency when applied across business processes helps to realize the promised efficiencies of enterprise-wide systems.

The intersection of ERP and ECM is the Shangri-La of enterprise computing, or perhaps it is the realistic earthly equivalent that is Hana. ERP powered by SAP HANA is the promise of real-time analytics and in-memory performance. ERP integrated with ECM is the key to keeping in-memory database costs down and enabling business process documentation that is visible to the right users where they expect it. Getting there will involve twists and turns but knowing what lies ahead on the “Road to HANA” is the key to navigating it.

 New Call-to-action

Nathan Hampson
Nathan Hampson
Nathan Hampson is a Principal in Gimmal's Client Success department with a unique, front-line view into concerns facing SAP users.

Related Posts

3 Tips to Ensure KORA Compliance

There has been a spotlight on the Kansas Open Records Act (KORA) in the media lately, largely due to recent violations. Under KORA, any individual can request public records from government bodies. If all requested records are not provided within in a specific timeframe, these organizations are subject to significant repercussions. This is merely one example of a ‘sunshine law’. The purpose of sunshine laws is to provide transparency into government agencies by giving the public access to local government proceedings.

Creating a Retention Schedule that Works

Creating a usable, automated, and simple file plan is an important part of ensuring records are managed in a consistent manner and that you are protected from legal risks, such as failure to disclose information during a discovery proceeding or the unauthorized leakage of information. The first step in the process is creating a retention schedule, which outlines how long records are kept in accordance with the organization’s obligations and the law.

How to Manage Your Sprawling Content

Sprawling content, the spread of content across multiple repositories, has been a thorn in the side of records managers since the dawn of document management. Consolidation of repositories, which began in the early 2000s, at first looked to be the solution. However, it ended up highlighting the problems of content sprawl due to the high costs of consolidation as well as need for records managers to manage multiple file plans. Federated records management offers a solution to these problems but doesn’t offer the same locked-down approach with regards to regulation that consolidation can. Consolidation of repositories and federated records management both have pros and cons and, depending on your organization’s content management processes and repositories, one can be more beneficial than the other in the long term.