Skip to Content

Why did SAP whisper this announcement at SapphireNow?

Ever since SAP announced the arrival of “Suite on HANA” I have been on the look-out for information. I was lucky enough to be invited last year to test some of the new apps that run on the new solution and I was suitably impressed. I was also lucky to be invited by SAP to the press launch of the product back in January and I am aware that around 100 customers were selected into their Beta program.

To me SapphireNow was the time to bring a customer on stage during the keynote to describe what took place over the past few months and the benefits they gained by moving to “Suite on HANA”. There was a video clip from John Deere but I think a trick was missed by SAP here.

However the big piece of news in my eyes was not really drawn out. Customers could migrate to Suite on HANA via a simple Enhancement Package upgrade. Now I have heard this from SAP before, but I always assumed the customer would need some extra “kit” (Hardware) to make it work. From the conversations I had this is not the case. A Customer who is on say Enhancement Pack 5 – could “upgrade” to Enhancement Package 6H and replace their current database with a HANA database.

I am not a technical expert, so if this is wrong please correct me, but I heard this from different SAP employees on a few occasions so I am taking it as the gospel. I am unclear if there is a minimum specification the database needs to run on or if there needs to be any extra RAM. (This is an invitation to SAP to correct and update me PLEASE).

So what does this actually mean?

Firstly there should be no extra cost to move to Suite on HANA apart from the Enhancement Package upgrade. Some stats that I have heard bounded around are as follows. SAP has around 60,000 ERP instances across the world. Roughly 80% of these are on ERP 6 (so 48,000). From this figure roughly 75% have made use of the Enhancement Package functionality. It is worth pointing out that ERP 6 was released back in 2005, so non Enhancement Package versions are roughly 8 years old now. So we have 36,000 SAP instances (not customers) that could perform an Enhancement Package upgrade and move to Enhancement Package 6H. They would need to replace their existing database with a SAP HANA database and therefore the actual Enhancement Package migration is slightly more complicated. SAP have thought of this and offer an RDS for this – so fixed price, fixed scope and fixed time to migrate you from your current version to Enhancement Package 6H.

What are the benefits?

As far as I can see they come in three areas

1 – Performance. Firstly the simple migration to the SAP HANA database without any specific tuning of transactions will provide a factor of 3 improvements to standard transactions and reports. Not bad for a non-tuned system. Invest a bit more and you can look to tune Business Suite transactions and expect to gain more dramatic improvements on performance.

2 – New functionality. SAP have said they will continue to innovate on the non-HANA database solution, however the volume of new functionality will be released on Suite on HANA. As I mentioned earlier I spent time working with the product team on some of these apps such as Receivables Manager and
Working Capital Management. There are a number more of these apps that are only available on Suite on HANA and I believe there is no extra cost for the apps in isolation.

3 – Future proof. I think customers are getting their head round the fact that the future is HANA. They might not understand what HANA is as so many different products, platforms, solutions and databases seem to use SAP HANA. Personally it is a new SAP brand. When I hear the words SAP HANA I
replace it with “in-memory computing” and I feel much safer in the conversation. Anyway SAP HANA is the future and moving your system of record on to SAP HANA (database) could be a good entry point. The cost is minimal especially if you are planning an Enhancement Package upgrade and you are setting yourself up to be able to consume new Suite on HANA solutions.


If you attended SapphireNow did you get the same messaging that I did?

If you are a customer would you be tempted to move to the dark side and experiment with SAP HANA on a small scale?

My view point is simple – what is stopping you from moving to Suite on HANA?

Update – 21st May 13:00 CET

So it seems the comments provided to me were not fully accurate. Suite on HANA can ONLY be run on HANA kit which means for most clients looking at the migration to Suite on HANA investing in new kit.

Words like expensive are just an opinion, customers need to make decisions on facts – so the actual cost of the new hardware and it would be good for SAP to provide some example figures to become more open and dispel the rumour mill and negativity.

You must be Logged on to comment or reply to a post.
  • It seems to be too simple. But without boosting your processing power would the customers be able to optimize usage of suite on HANA ? Or it could be a performance bottleneck ?

    Not an expert to answer either of these , but would love to hear on these .

    Thanks for Sharing.



    • Today you can have up to 80Cores for your database only on HANA for Suite on HANA This is a lot of processing power plus you need to consider the way that HANA manages data which is less CPU consuming vs "older" DB techiques

  • Hi Mark,

    I am not a project expert (yet 😉 ) but let me share a few thoughts of what I have learned from SAP Consulting and some of the own experience.

    The customer must be on the ECC Suite already (I believe there are still quite a few which are on 4.6). This process takes places on the existing infrastructure (HW & DB). The Upgrade to Enhancement Package 6H needs to be done and then you are ready to migrate the current DB to HANA. For HANA you need to consider that you need to change the HW with 99% of the chances. HANA requieres certified appliances which can be found on the PAM from a list of vendors.

    There are options on HW today ranging from 128GB to 4 TB, and even 6 with special permissions. The limitations on this will be overcome later this year, hopefully with the new generation of Intel Chipsets.

    I fully second your point that the time is now and that the opportunity of having Suite on HANA is huge for customers to finally have a full insight into their data. This is a tremendous value, yet I still hear from some customers that they prefer to wait, to not want to be the first. IMHO this is a mistake there is nothing they have to loose in contrary they have a lot to gain

    • Hi Carsten

      Thanks for sharing your insight - always valuable.

      Can you confirm what part of HANA requires certified appliances?

      The SAP HANA Database, as far as I understand can run on any kit as a core database. So you can migrate the DB but not activate any in-memory capabilities.

      Can you post a link to the recent PAM, in particular for SAP Business Suite Powered by HANA (Suite on HANA)

      To have tuned processes (use in-memory computing) I would expect you need the latest kit to achieve the full benefits.

      However making the first step now, or in the near future will enable a customer to start their journey with SAP HANA and move to new kit and real performance improvements over time.

      • Hi Mark,

        thanks a lot for your comment. Actually the SAP HANA Database must be running on the certified servers. I have the Link here

        But I can send you also the latest PAM by email (May Version).

        What I have found when talking to customers is that the migration moment can indeed be a very good momento to also think of migrating the DB to HANA. They are already involved in a technology project and once they are on the right EHP level the database migration itself is very straight forward.

  • The cost is minimal

    HANA hardware is far from free. Even if I could use my own kit and not have to buy a certified appliance, that much RAM doesn't come cheap. Compared to the cost of my current Oracle installation, HW cost for HANA is definitely not minimal. Don't forget to factor in DR capability. And what about DEV and QA instances? They should be on HANA too, really. I've had issues caused by DEV & PRD running different versions of the same DB - I wouldn't want to risk running them on completely different platforms. Plus, how do you test HANA upgrades/patches?

    There is HANA cloud. Can you run on-premise Suite on a HANA cloud instance? Would you want to?

    • hi Steve,

      Before Sapphire I had the same views and opinions.

      However if you can run HANA databases on existing hardware then the cost is minimal.

      However Carsten has pointed out that there are minimum hardware requirements for a HANA database.

      With regard to cloud - if you have a cloud objective or aim then putting Suite on HANA as part of say HEC would be an option.

      • If your current production hardware has the right spec, specifically it has enough RAM, to run HANA, then you have seriously over-specified it. I can't imagine anyone could drop HANA in place of Oracle, say, on existing hardware and have it work, even if it were allowed.

    • Steve,

      well the question is always how you define minimal. If you allow me to just follow your example of the "other DB vendor in Red". They are typically trying right now to drag all their customers to run the DB at least on an Exa machine. Those are quite expensive HW especially if you consider the supreme charges they put on it for additional disk space. Further down as well I would consider that the Exa Approach is much more a "more wood on the fire" than really innovative approach.

      Make a cost comparison of an Exa half rack which would be probably comparable to a 512GB Appliance of SAP HANA costs according to the Info that have is approx 800k (HW and the Exa Software Stack and Maintanance). You can get a HANA Appliance for for less than a 10th of that!

      Agree with you on the DR aspect but that has also some very interesting solution approaches (at least from my company) on which you can officially share the the DR infrastructure and use it for QA / Dev at the same time. The only thing is that when the DR situation enters then you need to shut down QA / Dev.

      So there are many things already existing and many more to come. If you want more info on this... please let me know but I really think that compared to the alternatives the word expensive is not justified.

      • A few numbers. My ERP6 prod system is quite small - just 500GB. I have ERP6 & DB running happily on a single machine with 128GB RAM, with room to spare.

        According to Sizing for SAP Business Suite powered by SAP HANA | SAP HANA I can expect 3-5 times compression for ERP6 on HANA, so lets keep to round numbers and call it 128GB. Plus I need to double that to let HANA run properly, so 256GB RAM. That's a new machine twice the size of my current production server, just for HANA. I still need my current hardware to run the ERP6 instance.

        Then I need another one for DR. Yes I can run DEV/QA on it when it is not needed for DR, but I still need another one. And currently both of these need to be HANA-certified hardware. How does the data replication work for a HANA DR appliance? Is it possible to use it for DEV/QA while it is the target of data replication from PRD?

        Yes, these are small numbers compared to an EXA system, but that's not what I run now. Compared to my current hardware they are non-trivial numbers!

        • Steve,

          if you like we can have a one on one session on this via Skype and will share with you the thoughts and options which we have today. There is still a lot to come and things are far from perfect but at least I would like to make some myth busting on "Hardware is very expensive". Since I think it is always important for all to know what is being compared.

          my skype is nitschkecm so if you like drop me a message and we find the time !

      • I heard about it but what I would be worried about is:

        - Shared Storage: how to you commit performance since it is a shared resource ?

        - Simplicity for support: That is what an appliance brings to you

        Last but not least: Is Storage really a cost matter since you point it to TCO or is it more a way to treat the reality in the DC where Compute is managed by one group and Storage by another ?

        I tend to say it is more the latter

  • Hi Mark,

    nice blog and thoughts, as Steve and others have already pointed out:

    • Hana only runs on specific Hana Appliance approved hardware and hardware specifications
    • Hana hardware is currently extremely expensive
    • Hana licenses are currently extremely expensive

    Steve Rumsby regarding the Hana Appliance for Production and Hana Appliance(s) for non-Production philosophies, there are some useful OSS Notes:

    • 1661202 - Support for multiple applications on SAP HANA
    • 1749467 - Copying SAP HANA From a Multiple- to a Single-Host System
    • 1826100 - Multiple applications SAP Business Suite powered by SAP HANA

    giving guidance about in what circumstances SAP Business Suite Applications' Hana DB's can share the same Hana Appliance.

    Very nice blog and thoughts Mark, thanks.

    Your thoughts are everybody's dream.

    Once the license and hardware prices come down, and Hana is supported on more o/s's then take up will be more and more.

    If I were a Basis Architect for a Blue Chip company I would do this:

    a) as soon as possible get one of the non-Business Critical SAP systems running Hana so that in the company, in the team, in the support organisation, in the business user base, we get the experience of running Hana, the knowledge, and in a controlled non-critical way

    b) then later, when the organisation was ready and satisfied jump in and move ECC and or BI on Hana

    by doing it this way, when the company is ready to move mission critical systems onto Hana, the Basis Team and Support Organisation and UserBase already have experience of Hana which will give the implementation of Hana on the mission critical systems the most chance of success.


    • hi Andy

      From the feedback from yourself, Carsten and Steve I am now confident that the messages from the showfloor at Sapphire was incorrect. Always dangerous taking content like that - but that was the reason for the blog to get the answer.

      However I was under the impression you do not need specifc HANA licences for Suite on HANA (apart from the DB licence cost which should be comparable to your current database licence).

      You purchase your Business Suite licence and you are off and running (after buying the new kit). This was covered in Vishal's keynote so I am pretty confident here.

      Knowing the true cost of Suite on HANA seems to be harder to obtain than first thought. I think this will be a blocker to the successful growth of Suite on HANA and I would encourage SAP to improve the content out there.

      • Mark,

        You are raising very good points here.

        1. Suite on HANA is a one time charge (if you do not have SAP already) of 15% of the maintenance value for getting the HANA License then afterwards just the standard SAP Maintenance fee. Which is very much in line with what other DB will cost you.

        2. For BW there is right now a promotion which is as well a percentage. I hope that SAP will keep this up since it makes it much easier for customers to take the move (they know what it will cost them.

        3. I agree that for HANA Standalone the pricing right now can still be challenging (IMHO) and also there I am sure that SAP will find a new model

        I have not been at SAPPHIRE but just listening to the keynotes I was a bit surprised. There are a lot of messages which seem to be half messages with lots of space of interpretation. Besides that we are right now in a BuzzWord War on Cloud, Big Data etc which will not lead to anything but confusion. Confused customers but also partners have one thing in common -----> they do not buy !!! This as a closing sentence because I honestly disliked a lot the statement of Hasso that the HW was too expensive...

        HW is build on the specs we have from SAP... not because we want to build it in a way!

    • Hi Andy,

      thanks for the great points you have raised. Fully second the implementation route you have pointed out. Still I wonder why you say "extremely expensive". Extremely expensive compared to what ? If you like we can discuss this offline but I think it is important for everybody that there are different angles of view on this and also to consider what you are getting for the money.

      I would be happy to have a discussion!

      • Carsten

        It would be good if you could go through the costs for saw Steve R so we can dispel the myths and work with facts.

        It is all very smoke and mirrors at the moment, and it seems people are put off by SAP HANA because it is DEEMED expensive - but as you point out - compared to what.

        The new apps within Suite on HANA will add some real value to clients that needs to be brought into the equation and not looked at as a kit decision in isolation.

        • Mark,

          I think this is a cool idea. Steve Rumsby if you agree we just make sure that I have all the data and I will expose a full case (in € of course) but this could serve as an example case ? Does this make sense ?

          • That sounds like a fantastic idea. Actual numbers are always better than smoke and mirrors and handwaving. What do you need Carsten?

          • Steve,

            if you can provide me with a diagram of your current landscape in SAP. With the systems you are using today (ex. Database for eCC is running on an Intel Server with 80 cores and 256GB of memory attached to a storage of 12 TB in Raid 5).

            As I was looking at the note form you I was thinking as well that maybe I will also challenge the HANA story a bit by making another simulation leaving all as is but changing the storage from Disks to Flash 😉 could be an alternative for not only 1 customer!

      • Hi Carsten,

        thank you for your feedback.

        At a Customer I am involved with, the cost of moving BI to Hana was not insignificant.

        To answer the question, in relation to what ? In relation to staying on the existing platform.

        The cost to move BI to Hana, the new hardware and licenses, was significant.

        I know the numbers, but this is not the place for me to quote them and this is between SAP and the Customer.

        I totally agree with you, the myths need to be dispelled, and I also know that SAP was offering the Customer a very attractive solution - so it's not all doom and gloom 🙂

        When the price is right, come on down, sorry freudian slip there, but humour aside,

        when the price and conditions are right, I am sure, like a herd of elephants the customer

        base will all go for Hana at the same time. SAP also need to control this. There is so much that needs to be controlled regarding the Hana roll out, and I think SAP are doing a good job so far.


        • Andy,

          Thanks 😉 I think that the pricing point was also intended to make sure that the # of customers will allow for the right and best support. I just want to extend the offer if you have a customer who is interested I would be more than happy to help you with indicative pricing (this is where you should get too) and also design of the solution. Both will be vendor independent since I have seen many offers already and especially from markets where they spell the D as in Discount with Capital and Boldface Underlined D 😉

          Happy to help and even more to see how this ship is getting into the cruise mode, that will make it almost unstoppable!

          • Hi Carsten,


            I see no reason why this ship will not get into cruise mode and indeed it will be unstoppable, when that happens is totally in SAP's control.

            In the meantime, the rest of us can be as prepared as possible by getting certification and experience 🙂

            By the way, you might be interested to read Simon Kemp 's blog over here .

            All the best,


  • Ignoring hardware issues, back in March 2013 at the CRM Insider Conference the understanding for SAP CRM on HANA was that if you weren't on EHP2 you had to make a triple move to get to SAP CRM on HANA

    Current System on any DB -> EHP2 on any DB

    EHP2 on any DB -> EHP2 for HANA on any DB

    EHP2 for HANA on any DB -> EHP2 for HANA on HANA

    I know that SAP stated goal at the time was to make it only a double move so that if you were not on EHP2 then you could instead move from Current System on any DB -> EHP2 for HANA on any DB.  Now if they finally made that concept available at SAPPHIRE(which may or may not been announced) that removes some of the complexity of the OS/DB migration project of going towards HANA.

    Take care,


  • Hi Folks,

        Full disclosure alert with my response here - I am a former Microsoft employee from the SQL Server development team - I just happened to catch the HANA bug and see the value of transferring my SQL Server experience to HANA. Feel free to check me out at Five Questions for... Bill Ramos

        I've spent quite a bit of time learning the ins and outs of using HANA for non-SAP use cases and I'm familiar with benchmarking and SAP DB licensing. I want to point out that businesses interested acquiring SAP business suite with HANA to need to carefully consider options for the DB platform and not take SAP's word at face value - this is the former DBA in me talking.

    1. Is HANA really faster and more reliable than the other DB platforms like Oracle, SQL Server, Sybase, DB2 to justify the higher price? From what I understand, then you buy the SAP suite and a DB bundled, you pay 5% of your business suite license for SQL Server, DB2 or Sybase. For Oracle, you pay 10%. For HANA, you pay 15%. Essentially HANA is three times more expensive than using SQL Server, DB2 or Sybase.
    2. What level of expertise is there out there now to help you run SAP with a specific DB vendor. There are throngs of partners and certified consultants that can support SAP with Oracle, DB2 and SQL Server today. Who can you go to for help in implementing production ready systems for HANA? Hopefully here 😉 or the dev center is a good start.
    3. How can you objectively compare SAP HANA performance to the other DB platforms when SAP has yet to publish a benchmark for the SD test? This is where you can objectively compare cost between vendors with various hardware configurations to help understand the number of "SAPS" you need to support? Of course, nothing can beat a multi-vendor POC shoot out with your own data.

    My hope is that people who have actually gone through the implementation can share there actual experiences on implementing the business suite on HANA in forums like this instead of us relying on "fuzzy" marketing and sales promises. It's fortunate that the this community has folks like Andy Silvey who takes the time to share his experiences in the trenches.



  • Hi Carsten Nitschke

    returning to this question of the cost of replacing an existing BI solution on a db with BI on Hana, as I have previously pointed out,

    At a Customer I am involved with, the cost of moving BI to Hana was not insignificant.

    To answer the question, in relation to what ? In relation to staying on the existing platform.

    The cost to move BI to Hana, the new hardware and licenses, was significant.

    Breaking News:

    This Customer is an 'IBM house', and it came to our attention yesterday that Big Blue are offering:

    Optimize your non-production [Hana] environments with VMware

    This means, SAP and IBM are supporting Customers to run Non-Production Hana on 'un-certified' hardware, I mean, hardware which does not meet the Hana Production Certified Hardware requirements.

    As SAP are supporting this use of hardware which does not meet the Hana Hardware Certification requirements for running Non-Prod Hana installations, this will significantly reduce the cost of implementing Hana.

    In my opinion this is big news, because from the Basis Architecture perspective this presents a significant cost reduction for implementing Hana.

    Obviously one would recommend that the Quality System be on the same Hardware Platform as Production.

    I think this news and the possibilities it presents deserves a blog, and not just to be left burried in this chat.  Will you blog it or shall I ?

    All the best,


    • Hi Andy,

      first of all thanks for highlighting this. On the other side I the who VMWare story has a lot of nuances which are very important to keep in mind. If you like we have a GTalk conversation first and then have a joint post could be highly interesting to shed some more light on it. I will send you my connection details in a PM


    • Hi Andy,

      Here is a thought with respect to cost reduction:

      Conceivably one can run HANA on a high spec PC e.g. one with 64GB RAM, dual CPU and SSDs. Load it with SuSE Linux and install HANA on it. This should work otherwise use a long winded approach by loading it with RedHat or CentOS, then install vanilla VMware and run HANA in the VM. You don't need a HANA-fied VMware, some folks have hacked the install scripts to make this work. Now if you want to use more than 32GB RAM, you would need to buy a licensed copy of VMware but even then I'd reckon the total cost would be lower/comparable to a low to mid range HP blade server.

      But I think the former approach should work as long as you use the Xeon processors (coz the Linux kernel for HANA has been customised to optimise the use of Vector Processing Units on the Xeon chipset - but I'm not sure if this would be truely emulated in a virtual environment so it might not be that critical after all!).



      • Hi Ramesh

        you are right if we have access to the Hana Platform Edition we can install it on a pc

        and a number of people have done and blogged it here on the SCN.

        But I am talking about Enterprises saving money and Enterprises will not be installing

        Hana on pc's.

        All the best,