I’ve participated in the internal implementation of ERP on HANA for SAP IT, as well as done architecture assessments, and discussion with customers on the journey to Suite on HANA. I haven’t seen a lot of details externally on the implementation, and figured I’d go through the steps in my mind, and see how they look. This is not an SAP approved communication, these are instead the ramblings of someone expressing their experience through the process.
Analysis of Current Landscape –
I find that a systematic analysis of the current state is an important starting point for the migration. We need to determine which target components in the landscape need to be upgraded or changed in someway to facilitate a move to HANA. Here are some key things I look for when looking at the current landscape.
- Which products are available for SAP HANA, and what versions are they on. There are prerequisite versions that each piece will need to be upgraded to, and it’s important to gain an understanding of each of these. You may perform the upgrade of the given system during the move to HANA.
- The same is true for Add-ons that must be upgraded to a supported version for SAP HANA.
- Dual Stack splits if required, do we have JAVA/ABAP running together on the same system? If so, we’ll need to split these as Suite on HANA only runs in a single stack with ABAP. This isn’t a particularly difficult move, and you can do the split while leaving ABAP running.
- The system must be Unicode, and if it’s a Non-Unicode system it must be converted.
- The current database must be a supported version. Many versions are supported, and this is commonly true, however if you are on a particularly old version it may be necessary to upgrade to a newer database before the migration.
In all likelihood, a given environment is not going to be “SAP HANA Ready” due to a low software version, or certain add-ons that are not supported, or not upgraded to a proper version. This will need to be included in the migration, and is a normal expectation. Many of these steps can be included as part of the migration process, and we just need to be aware of all the details required.
Sizing Considerations –
Sizing is very important in the migration to Suite on HANA, and we’re going to want to run the standard sap sizing scripts to develop an understanding of what size HANA system we will need. In my view, it’s always best to actually migrate your data to a HANA system in test to determine sizing, but before that process begins we can utilize available tools to gain an understanding before that step.
For Business Suite Systems:
- Note 1872170 – Suite on HANA sizing report
- Note 2080648 – Suite on HANA memory Sizing report
For Business Warehouse Systems:
- Note 1736976 – Sizing Report for BW on HANA
- Note 1637145 – SAP BW on HANA Sizing SAP In-Memory Database
For Sizing reports it is always best to run them on the productive system for the best accuracy involving the size of the system required. If there is concern around disrupting production, these scripts can be run on a QA or Development system. Prior to running the sizing scripts, the targeted system’s database statistics must be up to date in order to generate a reliable sizing calculation. In addition, there is a need to increase the dialog time out profile parameter rdisp/max_wprun_time to a higher value in case the report execution results in Time Out ABAP dump.
Alternatively you can use a manual calculation to determine the size for the target SAP system, but this is less accurate.
- RAM for Business Suite: RAM = [(Data Footprint *2) / 4]*1.2
- RAM for Business Warehouse: RAM = [(Data Footprint *2) / 4]
Application Server Utilization –
The main bottleneck in application servers is usually CPU consumption. If you’re on an older Netweaver version, the upgrade to a newer version will require additional CPU capacity. Depending on the versions involved, there’s a 10%-50% factor for CPU consumption. It is also important to consider future growth when sizing the systems.
SAP Addon Analysis –
Some industry solutions may not be supported with the versions for SAP HANA. This could be SAP solutions, or third party add-ons, and we will need to contact the add-on vendor to get an appropriate update for SAP HANA.
This is dependent on your environment, so it can be difficult to talk in generalities, but an example would be DMIS 2011 which is needed with the Near Zero Downtime Approach to migrating. If you wish to use Near Zero Downtime, then we will need to install this addon.
A third party example might be supported by SAP HANA with an updated version of the product, or it may need to be moved off to another server running a database to support it. Again, this is all very specific to the add-on so an analysis needs to be done.
I think I’m going to take a break here. Next up I will talk about Custom Code Analysis, and try to give some details and things to consider. It’s possible I break that up into a part 2, or I can just continue to edit this document to add the next things to talk about. We’ll see how it goes.