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….)

The preparation

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.

Sizing

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.

Hardware

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.

The execution

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.

Upgrade

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.

Migration

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

BW HANA Migration path.png

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

ECC HANA migration path.png

HANA Optimizations

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.

Issues

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.

The Results

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.

Future plans

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.

To report this post you need to login first.

8 Comments

You must be Logged on to comment or reply to a post.

  1. Peter Chen

    Thanks for writing this great article.  Very nice to follow your journey from end to end. Thanks,

    Question: the HANA database revision updates: you made it sound very easy and fast.

    – How much regression testing do you have to do? 

    –  Do you treat them like a BW upgrade? 

    – Do you think it could take significantly longer if you have a much bigger database?

    Thanks again.  Looking forward to hearing more of your journey.

    (0) 
    1. M. Rabe Post author

      Hi Peter,

      thank you. Great questions. The article doesn’t cover enough details as it would turn into a book if it did, but I will add a section about testing as it is really relevant.

      Here are some answers:

      – for both projects the focus regarding testing was on comparing data (tables, views, export files etc) rather then executing reports and transactions. As we didn’t change the SAP release testing functionality was not the main priority. Also, as we migrated our ACC systems first (the sandbox step) and again later for real (the regular ACC step_ we we able to test everything twice pretty much during the entire period. We did have a test cooridnator and scheduled a 5 day test period as well for our key-users.

      – Are you talking about the upgrade or the migration? Or both? The pictures show the slight difference in approach but technically the BW migration is more complex. The cookbook walks you through the steps nicely but there are quite a few more than for ERP, perhaps also because of the NW release differencce (7.31 vs 7.40)

      – I wouldn’t say that size doesn’t matter 🙂 but it only affects the downtime during the export and the import time obviously. I have some numbers if your are interested. i’ll put them in the blog as well. I don’t expect the impact to be significant in the overall duration if the DB size is twice the size for instance.

      (0) 
      1. Peter Chen

        Thanks for your response.

        Actually, I am specifically interested in the HANA patching.  You talked about only taking a few hours per system.

        How long and how much testing is needed for the HANA patching ?

        HANA patching had been apparently recommended as a frequent task.  If it is treated like a BW support pack upgrade, then it would not be realistic to do a patch every so often.

        what is your experience with the HANA patching testing?  Do you need as much testing as a BW system upgrade? 

        Thanks again.

        (0) 
        1. M. Rabe Post author

          Hi Peter,

          we treat the HANA patching the same as we did with Oracle patching, meaning very little testing effort, as it should only affect the database & platform but not the data itself. This is also because, just like you said, HANA patching is mandatory twice a year and we cannot hold extensive test sessions constantly. So far this works out 😉

          We are looking into solutions that help us to speed up testing so that we can do SAP upgrades multiple times a year (including HANA patching) whilst reducing the test effort and duration.

          (0) 
  2. Andy Silvey

    this is an excellent article giving a clear overview of the steps and decisions, I will follow with something similar soon.

    You’re very lucky that,

    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

    I look back in envy at the thought of having your own datacenter, with a Team from your company managing the servers.

    Perhaps one day, the trend will revert, and datacenter and unix and network operations ie, the underlying infrastructure operations, will be bought back inhouse.

    Best regards,

    Andy.

    (0) 
  3. John Appleby

    Thanks for sharing. A customer story is worth 10 vendor stories.

    Shame that you did not get to BW 7.4, the benefits are very nice on HANA. Perhaps you are considering an update. If so make sure you consider SPS08, it has nice new features.

    We know know that the TCA of HANA is higher than a traditional database. You are running in-memory after-all. How did the TCO stack up? There is a current theory in the market that the TCO of HANA is higher than a regular RDBMS. What do you think?

    (0) 
    1. M. Rabe Post author

      Hi John,

      your welcome!

      Yes we will be doing the BW upgrade to 7.40 latest SP in the next few weeks.

      The TCO in our case currently is much higher as the Oracle licenses are much more attractive than HANA licensing and a the same goes for the hardware. We also have a RDMS maintenance team that is very skilled in Oracle and still needs to get up to speed with HANA.

      But as we hoped, these migrations triggered some key decision makers to give the green light for quite a few (for us) important projects that really benefit from the new platform. So in the long run the TCO picture should look a lot better.

      Marcel

      (0) 
  4. Ramesh Deshpande

    Dear Rabe,

    Thanx for your inputs about your implementation of SoH.
    We are on the way to implement S4 HANA in our organistaion. I am quite new to S4 HANA

    You have put cross mark at DMO of SUM. Do you mean to say during migration the tools of SUM & DMO not used at all.
    Will please elaborate on the same.
    Regards,
    Ramesh

    (0) 

Leave a Reply