Simplify Migration to SAP HANA and S/4HANA

Traditional Data Volume Management for SAP®

Data volume management in SAP with SAP data archiving has been a best practice for SAP customers since the days of SAP R/3 and throughout the lifecycle of the SAP Business Suite.

The reason for this is clear and the value of data archiving well understood, With each transaction, data is stored in the database and the volume of transactional data is ever growing. As your productive SAP database grows, resource consumption and administration effort go up while system performance deteriorates and response time for the end user goes down. This is true when using the traditional databases for the SAP Business Suite. But is this still valid going forward?

The New World of Big Data with SAP HANA

When SAP released SAP® HANA®, a new in-memory database, and customers moved to SAP Business Suite on HANA and SAP S/4HANA, some of the pain points become a thing of the past. High system performance and good response times are a given with SAP HANA. Also the resource consumption seems to have been reduced as HANA has a compression factor of 50%.

BUT: SAP HANA as an in-memory database that requires a robust hardware platform. By nature, an in-memory database requires computing power and a substantial amount of main memory. If your database today has a size of 2 Terabyte, it will be 1 Terabyte with HANA and the memory requirements somewhat higher at about 1.25 TB (Formula: DB size (traditional DB) / 2 + 20% + 50 GB) according to the SAP QuickSizer for HANA SAP note 1793345)

Where resource consumption in the past mostly meant expensive high performance disks, it today means an expensive, robust HANA appliance.

Best Practice 1: Data Volume Management before Migration to HANA

Consequently, when moving to HANA as a database, be it to SAP Suite on HANA or SAP S/4HANA, it is best practice to clean up the SAP database before doing the migration to HANA and archive older transactional data. The archived data will still be accessible in Suite on HANA and S/4HANA via the standard SAP tools and interfaces, such as the SAP Archive Information System.

If you have not established a data archiving practice yet, this is the time to get started if your database is of a relevant size, for example 1 Terabyte and larger.

Best Practice 2: Use a Compliant Archiving Platform

And as you do so, make sure to store the resulting data files via the ArchiveLink interface on a secure and compliant storage platform. Such a platform is provided with OpenText™ Archiving for SAP® Solutions and OpenText™ Document Access for SAP® Solutions. The underlying OpenText Archive Center securely stores the SAP data files on leading storage vendor platforms, which have an immutability feature and are thus compliant storage platforms.

Archive Center provides a hardware abstraction layer and in addition automatically creates backup copies of the files. This is different from storing data files in the file system, where files are not protected and you need to take care of backup and migration when the file server changes.

Best Practice 3: Remove Unstructured Content from the Database

And as you do the clean-up, there is one area you may want to check, that is unstructured content in your SAP database. If you haven’t configured the storage location of GOS attachments (GOS = Generic Object Services), all unstructured content that your users have added via GOS has ended up in the database and adds to the overall volume.

You can check the size of table SOFFCONT1, and may want to control table DRAO for SAP DMS (Document Management System) documents as well.

GOS attachments as well as DMS documents can be stored on OpenText Archive Center with OpenText Archiving and OpenText Document Access for SAP Solutions.

You simply define a new storage category to reside on the OpenText Archive Center. With simple configuration you can switch from the old category to the new category (TA SKPR08). And for the migration of existing documents there is the SAP report RSIRPIRL. As a result, the unstructured content is stored on the OpenText Archive Center and your database is relieved from the burden of the unstructured content.

Summary: Establish Data Volume Management and Reduce TCO

Our recommendation is to establish data volume management. Data archiving helps you to reduce and control the size of the database. This reduces administration and hardware costs and can significantly reduce your TCO for the SAP landscape, and if you plan to migrate to SAP HANA as a database, you can realize significant savings by reducing the memory footprint of the HANA database, and with that the hardware footprint of the HANA appliance.

For more information about SAP data and business document archiving with OpenText view the following:

And have a look at customer success stories on SAP data archiving here.

Claudia Traving

Claudia is a Program Manager for OpenText Enterprise Content Management for SAP, with an additional focus on Public Sector, Enterprise Asset Management and IT Excellence. She is based in Germany and has worked in the SAP Solution Group at OpenText for 25 years, bringing over twenty years of experience in SAP-related solutions and business scenarios.

Related Articles

1 thought on “Simplify Migration to SAP HANA and S/4HANA”

  1. As the name suggests, SAP S/4HANA only runs on the SAP HANA platform in order to further leverage SAP’s in-memory compute model. Not only does SAP S/4HANA deliver within SAP’s in-memory compute model, it also delivers applications rewritten to further optimize performance and to simplify implementation. This version further builds upon the business value capable of in-memory compute database performance with a simpler, faster, and more efficient application code base.

Leave a Reply

Your email address will not be published. Required fields are marked *