SUPERP’s SAP-BASIS experience of Transition to SAP ERP on HANA

Within SUPERP we have our own SAP system landscape for training and demo purposes. A main component of this landscape is the ERP system. It runs as ERP 6.0 Enhancement Pack 7 with MS SQL database.
Within our SUPlabs innovation projects, we decided to start a transition path to SAP S/4HANA. Before upgrading to S/4HANA. we decided to first move to ERP on HANA (System Conversion Approach). As this transition approach seems very viable and realistic for many of our clients, we chose to explore this in a hands-on scenario with our own primary ERP system.
The first phase where we migrate to the SAP HANA DB is a mainly technical migration from MS SQL database to a HANA database. The migration itself should have no impact on the core functionality of the ERP system. The HANA database release to go to is SAP HANA Platform Edition 1.0 SPS12.

This blog describes some challenges, hurdles and decisions we encountered in our migration path in several phases of the process.

Preparation

• Sizing: We used report /SDF/HDB_SIZING to get a proper sizing advice. Check OSS note 1872170 to install recent versions of this report. Our ERP system has a very limited amount of data. We did not use the Quick Sizer tool.
• Hardware: We decided to rent a virtual private cloud at our data center provider for the new database environment. It was not the cheapest option, but the application server (still running on Windows Server) was running there as well. Otherwise, we also had to move the application server to a new datacenter. That would require an additional server, migration effort and more data traffic between different data centers. Base configuration of the VPC: 8 vCPU’s, 100 GB RAM, 130 SSD Storage. This is approximately the minimum of the outcome of the sizing report. 
• HANA runs on Linux. We acquired a license for Red Hat Enterprise Linux 7.2. It took 2 attempts to Install Linux in a proper way. Attention points: sizing of the mount points, do you only want console access or also a graphic shell? Then you can choose this during the installation.
  
  

• ABAP custom code check: The ABAP Test Cockpit was being configured to run a HANA health check. The current support stack did not have all the necessary options available, which is also realistic for most customer systems. In that case, you can first upgrade the current systems or find other solutions from SAP. We were able to just copy the necessary configuration from another system with the right support stack. See also: https://help.sap.com/saphelp_nw74/helpdata/en/2b/99ce231e7e45e6a365608d63424336/content.htm

Running the upgrade

• We used SUM (Software Update Manager) to do the database migration via the DMO option. We tried to keep the migration as simple and isolated as possible. Therefore we tried to stay at the same support stack level, as we did not want to risk issues regarding new support packages. However, this was not possible. SUM just stops in the first steps if you don’t provide any new support packages.
• The DMO option is not in front of the SUM processing but appears a bit later.
  
  

• Due to syntax errors in DDL objects we were forced to abort the SUM process. We often see DDL syntax issues with SUM. We found some OSS notes to solve those issues. It was not possible to implement them during the migration process. After restoring the system – clone copy - and implementing the notes it ran fine the second time. The imported notes were not related to the HANA migration, but caused by issues in some SAP_APPL support packages.
• Available memory during the upgrade is not clear. Just before the offline phase, errors appeared. After restarting the database it was possible to continue.
• Sometimes it seems that in SUM the process has been stopped, or is not doing anything anymore. No logs were changed. We waited. And waited some more.. Should we abort? No, just let it run. We waited almost 2 hours and suddenly we saw progress again.

Afterwards

• Creating backups of the HANA database was in the beginning not possible with our Windows based solution. To access the Linux storage we had to make a mount point /hananfs. Finally we were able to back-up the database.
  
  

• Log files got bigger and bigger. We almost ran out of storage. To prevent growing log files, we changed some parameters in the global.ini file to overwrite logs. (not a nice solution, but it would be temporary).
• Again the database grew after using the ERP system a bit. Still only 3 GB free space storage left… We decided to acquire additional 35 GB storage and expanded the database size.
• Functional testing: as the system had a low volume of data, it made no sense to measure response time on large data selections. Therefore we did not identify any value-adding performance testing. We only checked if the core functions in the ERP system still worked fine and the interfaces were working correctly. We only found 2 issues in specific standard Fiori apps. But they were caused by the additional support package that was applied, which could be solved by an OSS note.

Lessons Learned

• The sizing report /SDF/HDB_SIZING gave a reliable advice. We first decided to select the minimum amount of RAM memory, but that was a bit too low.
• We didn’t know that SUM can not migrate the database only. If you don’t want to import support packages, use the classic migration tooling, not SUM.
• Prepare your back-up environment to connect to a Linux environment.

We ended up with a real fast system. Ready to look forward and discover the new HANA features. Our internal knowledge & innovation platform called SUPlabs is ready to gain more knowledge regarding ABAP on HANA, Fiori HANA apps, analytics and more features like Simple Finance and HANA Live reporting. Also, we will prepare for the next conversion phase where we will convert to the S/4HANA Enterprise Management suite.