May 6th 2014 was a rather memorable day for the SAP department at the University of Amsterdam. At least that is how I see it. After 7 months of hard work we went live with ECC on HANA (known as Suite on HANA or SoH), just 4 months after going live with BW on HANA (BWoH). As first company in the Netherlands and also first Higher Education institution in the world.
After my presentation about these two projects at the HERUG 2014 @Emanuel_Milioto asked if I would consider writing a blog about our experiences, which sounded like a great suggestion, so here it is. You can watch the recorded presentation here.
The Business Case
So the first question is, why did we do it? There was at least on clear driver: the hardware used by our SAP systems was old and already in (expensive) extended maintenance support and replacement was necessary. As a result, the performance of the ECC and BW systems was dreadful. This was the second driver: the new system environment needed to perform a whole lot better.
Looking at our infrastructure we decided to things a lot different. To clarify beforehand, we manage and host our SAP systems ‘in-house’, meaning in a private section of a datacenter managed by our own employees. We typically purchase the hardware ourselves .
In the old environment we ran multiple SAP instances on the same physical hardware including the Oracle database, which limits scaling up and also causes interoperability problems. So we decided to virtualize the application servers. But we struggled with the database question: should we use Oracle RAC, separate physical Oracle hosts, separate virtual Oracle cluster, or….?
At that time, early 2013, SAP HANA was already GA for BW and we started investigating if we could solve the BW performance problems with BW on HANA. Actually, the performance problems we had for BW applied mostly to our Web Application Designer reports, not so much to BW itself so our expectations were that HANA would not help us that much. But our HANA advisory & implementation partner ánd SAP guaranteed that it would, especially in combination with Business Objects (which we had already licensed for some time but never even installed).…..
When comparing licensing costs between Oracle and HANA, for us there is only one winner as Oracle licenses are very attractive for (higher) education institutions. However, we strongly believed in the HANA potential and after SAP announced that also the Suite on HANA was GA we were convinced that taking the HANA road would be something that most customers will do at one point, so why wait? SAP was clearly betting its future on it and waiting would mean at least a 5-year delay.
One disappointing comment I’d like to make is that SAP was not able to help us build the business case from a functional/business perspective at all. Also the customer specific report with the Business Scenario Recommendations (available at https://www.suiteonhana.com) did not help. It seemed like Suite on HANA would not gain us much if we would keep using the system the same way, however we also believed that future HANA developments would be more applicable, as well as utilizing HANA power in new and yet undiscovered ways.
One of those just announced future developments was HANA Live. Potentially this could give business analysts and controllers to build reports on live SAP data, which was music to their ears. This became the final push needed for approval (but keep this motivation in mind, as I will come back to it in the end….)
Before doing the actual migration we had to do some preparation of course. First and foremost was the negotiation with SAP regarding the licensing, obviously. As we have rather small SAP systems, no high-availability demands and relatively simple SAP landscape, HANA looked feasible. With the scale up features that HANA offers we think we have a landscape that will last for 10 years.
Use https://cookbook.experiencesaphana.com to prepare the migration and build the project plan. We followed the steps in the cookbook which proofed to be very helpful.
Key component of the exercise is to size your systems adequately. SAP provides useful reports that will give an estimation on the required & estimated HANA size. The sizes of the databases, especially BW, will drop significantly. Our 1.8 TB productive database dropped to 300 GB which easily fits in a Medium HANA system. Our 550 GB ECC database dropped to 250 GB. It’s too early to say if the sizing of our systems was accurate over the long run and since we already added more modules to ECC (such as Payroll), we might never know.
Simply put: out organization are not ready for SAP-in-the-cloud yet. At the time, neither was SAP actually. And as we are used to hosting and maintaining our own servers we bought real HANA boxes rather than using a cloud offering.
For BW two HP Proliant DL980 G7 systems, both Medium+ (512GB). 1 for PRD, 1 for DEV and ACC.
For ECC two HP Proliant DL980 G7 systems. 1 Medium+ (512GB) for PRD and 1 Large (1TB) system for DEV, ACC and SBX.
Tip 2: wait until the very last minute with buying hardware. Ask multiple suppliers as we noticed that prices dropped drastically in just a few weeks.
Well, since we did shut down and moved out the old hardware, execution is not such a bad title We followed a rather simple principle. First upgrade, then migrate. It is possible (they say) to both in one go, known as Data Migration Option of SAP Upgrade Manager (DMO of SUM), but we chose to split the two actions for safety reasons.
To implement HANA on BW, release 7.4 is the recommended release. Unfortunately we were not able to do this as 7.4 was barely GA in summer 2013 but more importantly, there was no guarantee that our 3.x Web Application Designer reports would still work. As we (still) have quite a few of them and no time to migrate them all to at least 7.x, we decided to upgrade our 7.01 release (BW portal and BW backend) to 7.31.
Duration: 3 weeks
For ECC the only HANA option was to run EhP7 on 7.40 so we upgraded from Ehp5 on 7.02. We kept our ESS/MSS portal running on NW 7.02 (with the Java XSS components) as an upgrade to NW7.40 would introduce additional work trying to restore XSS.
Duration: 6 weeks
Tip 1: upgrade to the latest release possible and pay close attention to the HANA revision level. HANA innovations still come at a rapid speed and we are already 1 year behind on the SAP release because we can only do system upgrades once a year.
Actually, the migration to HANA is not much different from any OS/DB migration. The process is simple; export all data from the source system and install the new system using the data export. In principal, the migration path is: Sandbox 1st, Development 2nd, Acceptance 3rd and Production last.
Note: The sandbox migration is a migration for trial purposes only, a very essential step as it gives great insight regarding the entire migration with regard to duration and complexity for instance. In our case, we used a copy of our Acceptance systems for the sandbox. This is a different sandbox than the sandbox we actually use to try software out!
For BW we followed a rather unorthodox migration path: after the Sandbox we migrated Acceptance first, before Development and then Production. We considered our Development system not representative enough and by doing Acceptance first we had more time to really test the system, as this was our first HANA system.
The consequence of this path was a 4 month development freeze on BW, starting from the upgrade in August 2013.
Duration: 8 weeks
For ECC we followed the proper migration path, as we expected some urgent repairs / notes requiring an open transport lane. But as it turned out, the ECC migration didn’t require any notes ❗ in contrast to the BW migration. This is for a great deal related to the NetWeaver version difference; 7.40 vs 7.31. 7.40 is HANA ready by design.
Duration: 12 weeks
After the migration we already noticed a significant performance increase without changing any code ourselves. Part of the HANA core is that SAP developed new versions of transactions that utilize HANA as much as possible. On top of this, SAP provides reports that will analyze both SAP and custom code which will give suggestions on how to change the code to optimize speed.
We don’t have much custom code. We’ve always been very keen on avoiding it or at least make sure it gets replaces with SAP standard as soon as possbile afterwards. Although not relevant for the migration itself, it is important to realize that some custom code might perform quite poorly after a HANA migration.
We didn’t run into significant issues to be honest. Because of improper housekeeping on our development system the migration of the DEV ECC system failed. Apparently, the SAP report that analyzes the large tables (for row-to-column migration purposes) doesn’t take any SAP Basis tables into account and in our case this was a 100GB ❗ BALDAT table. This also applied to our EDI40 table (70GB) BW. Both tables were too large to migrate. We decided to truncate the tables and rerun the export.
Now that we are 4 months on the HANA road with ECC and already 8 months with BW we can confidently say that both migrations have been a great success. The performance of BW and ECC has improved significantly and there have been no problems with the databases or HANA platform.
We can see that users are using the system better than before, meaning running much larger (ad-hoc) queries for instance in fractions of operation time. However, not all transactions are performing better! Some even a lot worse. We’ve asked SAP to assist us with these transactions and we are narrowing it down to just a few.
No problems at all?
Actually, we did have a full system stop, unplanned. This was caused by a hardware failure in the ESX host (VMWare) where we run all our SAP virtual application servers. But this did not hurt the HANA’s in any way.
We even experimented with just ‘pulling the plug’ to simulate a unexpected immediate shutdown of HANA. After booting up, we didn’t notice any loss in data or data corruption.
HANA Live and HANA Revision levels…..Watch it!
A word on HANA Live. In the beginning I mentioned that I would come back to this. Remember that HANA Live was one of the drivers for us to go with HANA. We went live with HANA Rev. 68 (SP6) although Rev. 72 (SP7) was already out. This release, however had some known problems and we were advised not to use it.
Now, as it seems, HANA Live is very much HANA Rev. release dependent. SP6 for HANA Live was not to be implemented with HANA SP6, an upgrade to HANA SP7 is required. This meant that after all the work we couldn’t even use the functionality that convinced our decision makers to buy it in the first place….Ouch!
Thankfully, a HANA SP upgrade is a rather smooth one. In our case, done in just a few hours per system. And on the upside: every SP adds interesting features to the HANA platform.
Now that we have the HANA platform, we are only now just discovering the possibilities. Building predictive dashboards, offering R for very large datasets to assist our researchers, developing new real-time scheduling applications to name a few.