Skip to Content

SAP ERP’s Future on HANA

I was invited as part of the SAP Mentors program to SAP’s press release in Palo Alto last week.  As has been covered in multiple news articles since then, SAP announced the availability of the Business Suite on HANA. 

I had heard of HANA many times in the past few years but it’s always been related to non-SAP applications.  More recently, BW stories have started to pop up and most everyone was predicting that it would eventually be available for other SAP applications.

I was under the impression that HANA’s main advantage was speed; fast access to data.  While there is always risk in new technology, the promised benefits of HANA seemed appropriate to an OLAP system such as BW.  But no matter how important it is to a customer’s SAP solution, BW is primarily a reporting tool.  Migrating a transactional OLTP system such as ERP to HANA that happens to be your financial system of record?  Well, that is a much more critical system to migrate, manage and support.  As such, this announcement got my attention.  At the same time, it represents a much greater benefit.

What Was Said

First some technical items.  The Business Suite (ERP, CRM, PLM, SCM, BW, et al.) is available on HANA but my focus and concern was mostly on ERP.  In order to run ERP on HANA, you have to be on ERP 6.0, EhP6.  SAP plans to have all of the industry solutions supported on HANA by year end.

The approach to switching to HANA is done in two steps.  First, a DB migration has to be done which SAP expects will only take a few weeks at most.  At this point of the process, you immediately get access to HANA analytics on your transaction data.  Transaction processing and reporting are also drastically improved. After this is completed there is some potential business re-transformation as you start to review your processes in new ways now that speed is no longer a limiting factor.

Design Time

It was at this point that SAP made a repeated reference to Design Thinking.  While HANA enables tremendous increases in reporting (read) speeds, it’s biggest benefit isn’t technical so much as it is functional.  By removing speed as a barrier, SAP customers will have to re-think their business processes.  For instance, what can be done with CO allocations now that performance and run-time are no longer a concern?  Are there certain costs that you would like to allocate but didn’t want to add more runtime to your allocation process?  The key message is that it’s not the speed of HANA that is used to justify its ROI, it’s the benefit that it provides the business to better manage it’s data and make quicker and more accurate decisions.

Who is going to deliver this new Design Thinking?  There was some discussion in Palo Alto and on Twitter about whether or not the consulting groups would have the chops to deliver this type of consulting.  Most everyone seemed to be skeptical about it in spite of the large numbers being published from SAP that have gone through their HANA certification.  I tend to agree with this viewpoint because the dominant changes to the SAP consulting market in the last 5 years have been around the topics of 1) low cost and 2) offshoring. 

What SAP is encouraging is a review of a customer’s key processes with an eye for increased efficiencies.  To design effective business processes for an SAP system, you need several items.  First and foremost, you need expertise about the process in question and the solution that will support it.  Given the high degree of integration that ERP has, you also have to carefully manage the final process across multiple groups that often have competing objectives.  These types of sessions (I usually think of them more more as negotiations than workshops) have to be done together in an intimate and collaborative manner.  You just can’t design a business process via MS Word or a project collaboration tool, much less re-design one that negatively impacts purchasing at the benefit of finance.

The SAP consulting market has been more akin to a SAP contracting market these past few years.  Maybe HANA will help reposition how customers use their consulting talent.  We will see.


SAP continually mentioned that implementing this solution for existing customers would be non-disruptive. My main concern with the ‘non-disruption’ comment is that most people think SAP has a poor track record here.  We all know how complex an ERP project is and how an upgrade can be equally challenging.  SAP has reacted to this with it’s Enhancement Package (EhP) strategy and promised both quicker roll outs of new functionality as well as more isolated functional activations onsite.  The more precise we can be in activating a single new business function, the less time has to be spent implementing it.  I agree with this and how EhPs are delivered as well as the limited time it takes to install, activate, test and rollout a new solution…  but I’m clearly in the minority.  From what I’ve seen in the market, customers view EhPs as significant undertakings even if they’re not activating a single business function. Now SAP is going to these same customers and promising that they can switch their core transaction system to a new revolutionary DB and it won’t disrupt their business processes.  This may be true but I doubt customers will view it that way.


Even though an ERP system’s DB can be migrated to HANA, the entire system does not have to actually use it.  The activation of HANA can be done at a very low level.  It’s not by client, module or even by submodule.  Instead, you can activate individual functions or BAPIS to use HANA or to not.  So, it’s not an all-or-nothing approach.  This further strengthens SAP’s argument that Suite on HANA will be non-disruptive and should make it easier for customers to try out HANA by prioritizing an individual area or function in ERP without exposing the entire system to this new technology.


Once an application such as ERP is on HANA and faster reporting is available directly in the source system, is BW still a necessary application for reporting purposes?  There are two thoughts on this.  On the one hand, there are many different use cases that still support BW.  If you have requirements around multiple source systems, unstructured data, data harmonization and quality, mobile data, complicated cross application reporting, etc., then the case for BW is still strong.  However, now that the source transaction reporting is so fast, why burden yourself with the additional cost, overhead, data latency, timing, and data administration of BW when you can report out of ERP directly?  This could represent some real savings to certain SAP customers that are either not heavy BW users, or those that want to scale back their usage of it.

Of the two viewpoints, I think BW could actually get stronger as part of a customer’s SAP solution.  Since the native reporting out of ERP will be so fast, the operative reporting requirements that have been forced onto the BW community will hopefully be alleviated.  By doing so, BW teams will be able to better direct their efforts around more strategic, analytical, and mobile reporting requirements instead of the column-and-row based reports that most BW projects seem to fall prey to.  BW teams have been saying for years that operative reporting should be done in the OLTP system but they have a high failure rate given BW’s high performance capabilities and easier report construction and delivery.  With HANA, some of those benefits are now on both sides of the RFC fence.

Final Thoughts

If you’ve been following SAP closely over the past year it was easy to predict that this day would one day come.  SAP has been touting the benefits of HANA aggressively and it was only a matter of time before they enabled it for their most critical applications.  SAP has delivered on their vision of a reinvigorated database and hopes to have 1,000 customers by year end with at least some small part of a Business Suite application live on HANA.

NOTE: SAP paid for some of my travel expenses to attend the press release.

You must be Logged on to comment or reply to a post.
  • NOTE: SAP paid for some of my travel expenses to attend the press release.

    Thumps up for clearly stating this – should be common, but is seldom found in the ‘blogosphere’.

    – Lars

    • Thanks Lars.

      On top of all of that technical stuff, it was a really fun event.  Not fun in a ‘conference in Las Vegas’ sort of way, but very energetic and entertaining to see so many people turn out.  Most people, myself included, don’t get to see that side of the company.  That experience was worth more to me than a plane ticket and a hotel bed.

  • Hi Nathan,

    This is an excellent review, so thank you for sharing! 

    For us, EhP are kind of a big deal – whether we are being overcautious or not.  There is a full cycle of testing that needs to be done – which of course = time+money.  So I imagine that when(if!) we implemented SAP Business Suite on HANA, there would be quite a bit of disruption. 
    And negotiating with the various business units on how to re-think our processes would not be the least of the disruptions.


    • I don’t understand that.  My current customer is ‘upgrading’ (their word, not mine) to EhP6 but not activating anything.  Yet they, like you, are going through a full round of testing.  I don’t get it!  I had another customer last year that I helped implement 2 business functions in EhP5 and we only had to do minor testing in the impacted area.  They’re still in business as far as I know!

      The non-disruption point is key because the benefits of HANA are fairly obvious. Reporting will be faster and who doesn’t want that?  Especially without a lot of indexes, aggregates, data loads, yadda yadda.  The trick will be in how it is applied so that one customer gets more value out of it then another.  I’m told that DB migrations aren’t that big of a deal but I have no direct experience with them so I feel very cautious about this.  But if SAP can convince customers that it’s non-disruptive, I think the benefits will sell HANA quickly.

      • Well, we’ve had issues caused by DB upgrades, let alone DB migrations. And issues you really can’t imagine being caused by a DB change. If I was going through a DB migration, I’d test everything.

        We’ve also had functional issues caused by kernel upgrades in the past. Again, I’d test pretty carefully after a kernel upgrade.

        Given that the application of an EHP often requires either a kernel or DB upgrade, I’d be very wary of doing minimal testing. The party line is that EHPs are non-disruptive. Past experience tells me to err of the side of caution. You can’t do too much testing!


  • Well written and I learned a lot.

    This message is key:

    SAP plans to have all of the industry solutions supported on HANA by year end.

    Thank you for taking the time to write this up.  I have a different view on Ehp’s – to me they are similar to support packages, especially if you don’t switch a single function.


    • I thought that was important as well.  IS-U, and IS-Oil have huge performance issues.  With IS-Oil’s JVA and PRA, I would expect HANA to make significant improvements on their month end programs.  I’m actually surprised that SAP thinks it can get those out that quickly.

  • Hello Nathan,

    your blog contains some aspects which were not mentioned in ERP-on-HANA blogs so far, definitely worth reading!

    I am a big fan of evolutional approaches. On the disruption, well I believe it is even more fundamental than what you wrote. SAP should provide a “safety parachute” for migrations to ERP on HANA:



    • Attempting this migration for an ERP system is very significant to me.  I’m not entirely sure how smooth the first one goes but I was curious what would happen if the first few don’t go well…  not a good thought.

  • Thanks for such a nice introduction to SAP ERP on HANA. Can you tell us how SAP will help its implementation partners to prepare their team on migrating customer’s current ERP system to run on HANA. Does SAP has any kind of training program geared for implementation partners?

    • I know there is a HANA certification but I assume it is a technical course geared around the setup and mgiration of the DB. 

      There are a series of optimized reports and tcodes in ERP but there is no functional configuration that I’m aware of.  So I’m not sure what kind of training would be necessary for the functional community.

  • Nathan,

    Excellent blog.

      I didn’t know this.

    So, it’s not an all-or-nothing approach.

    Does this mean ERP could potentially use two databases at the same time, traditional & HANA? This is interesting.



      • Interesting. I didn’t remember seeing that. Here is my understanding:

        1) SAP would try to support other databases by providing support for Stored Procedures and

        2) All future development within SAP would be completely on SAP-HANA. This is very important because in case they plan on supporting two databases at the same time, they need to worry about two phase commits at a minimum; if they’re planning to use only one database — that is HANA– for the development, how would SAP test two DB scenario?

        In case you learn more on this, please share…

        Best regards,


        Note: Steve Rumsby appears to have answered this after I posted this comment.

    • I doubt there’s be two databases involved, but rather one – HANA – and two versions of affected functions – one traditional and one with HANA-specific optimisations. But that’s just a guess – I have no idea:-)

    • Apparently… and we weren’t shown the solution at the PR…  you can go into the IMG and select which items you want to activate.  I’m not sure if these are new config steps or a way to mark existing IMG activities as HANA relevant.  Either way, it is done at a very low level.  I could see a customer choosing to just activate settlement and project structures in PS to see what the impact is.

      • You mentioned EHP6H. I assume that’s different from EHP6? I hadn’t seen that made clear before. The existing EHP 6 isn’t good enough – you need to apply EHP6H. Does that also mean there will be HANA-optimised versions of all EHPs from now on, and you have to apply the right one? Is there any news on the release schedule of these? Will EHP7 and EHP7H be released at the same time, or might the HANA version be later (or earlier, I guess, although that seems unlikely)?

        • Thanks Steve,

          if you look at the release notes, they are  called “version for SAP HANA”.

          My understanding is that future release schedules will be announced later this year.

          thank you


          • I did notice that, but I don’t remember it being mentioned in the announcements of subsequent discussion until you mentioned it up above. I wonder if other people are currently thinking – “we’re on EHP6, we can do HANA”.

            Is there any info on what a EHP6 -> EHP6H upgrade might be like? I’m assuming pretty straightforward, but you can never tell!



  • Hi Nathan,

    This is a good summary and brings another unique angle. I think you covered some interesting detail that others didn’t cover, such as the granularity at which services and function modules SAP on HANA can be activated for. I also think that you highlight some important points around the need for BW for single-instance ERP customers. I know SAP will try to build business cases to prove why it is needed additionally, but if you’re ERP has more processing power than your BW system then what’s the point?

    Best regards,


    • But given how common place data warehousing has become, it would probably still be done.  If I’m a BW person (and I was but I’m not anymore), I might have initially been worried by this announcement.  But after thinking it over, I think it makes their job a bit easier because it takes away some of their requirements that their solution isn’t well suited for.  That didn’t stop folks from trying to develop solutions for operative reporting in the past, but now you can tell them that it makes more sense to write an ABAP instead.  As I see it, the math for the BW guys is (fewer ill-fitting requirements = higher success).

    • With regards to your comment Luke,

      the point might be not so much if you need BW after a Suite to HANA migration, but if you still need an Enterprise Data Warehouse. Personally I would argue that the OLAP capabilities in the Suite on HANA make any Operational Data Store obsolete, if in BW or wherever else. EDW capabilities are something else, as it would be hard to imagine, that in a case of a M&A (Mergers and Acquisition) for example, a company would load historic legacy data into (any – not just SAP) ERP system for reporting purposes.

      Also the idea of OLAP reporting in the SAP Business suite powered by SAP HANA is, that any reporting performed in HANA views on the existing source tables, means no redundant data storage in additional tables, like for example in SAP LIS (Logistics Information System) or SAP SIS (Sales Information System).

      Virtual views of course have the challenge, that the result set is not “sealed, signed and delivered”.  So, something like a BW system will also need to be part of an Enterprise Architecture in order to store, maintain and govern the snapshots of report/query result sets.



  • Excellent job with this blog and really enjoyed the angle on design thinking and consulting market as it will be easier said than done.

    I take a stronger stance on the innovation without disruption as my track record with Enhancement Packages from an IT and Customer standpoint has been it has caused “some” disruption given some of the technical prerequistes and testing.  HR customers for example have become conditioned to test EhP’s and HRSP because with the changes have come bugs/defects which can cause issues. I wish SAP would retire the “innovation without disruption” marketing message and replace it with telling customers the reason why offering X (ie HANA/EhP’s) will be worth a “little’ potential disruption. For some customers disruption will be a good thing as well as if they have a custom process with a lot of custom ABAP code speeding it up on HANA might not give them the benefits of what they are looking for.

    • I agree “innovation without disruption” is not true. At the same time, SAP appears to be less disruptive for what they deliver. So may be that is SAP’s justification for “Innovation without disruption”! I mean they deliver very complex s/w solutions and yet it works elegantly – with disruption – provided it’s operated by experienced professionals. 


      • My experience with the EhP is that they’re as small, manageable, and non-disruptive as can reasonably be expected.  Yes, you have to do some testing but my one experience with an EhP project was very positive.  10 weeks and we only worked on it part time (maybe 20% effort). 

        Is it zero disruption?  No.  You can’t do anything in an enterprise app that changes functionality without disruption.  Heck, even an OSS note with a program correction is disruptive if you interpret it a certain way.

        In the end, I think it comes down to how you interpret the word.

  • Hi there Nathan – I am not surprised by your statement “…….BW could actually get stronger as part of a customer’s SAP solution. ..better direct their efforts around more strategic, analytical, and mobile reporting requirements”.

    The more time I spend getting to know HANA, and apply the years doing reporting in ERP, then BW to this – the more I feel BW itself might actually become stronger because of this. The reason being – the way ERP was designed and built. in the end, you still have relevant data for a given data flow track sitting in 30+ different tables. Add to that, as also eluded to by Steven Lucas and John Appleby on other blogs – why give up the value on content SAP spent so much time creating.

    Scenarios will differ – and you need to take into account current status, and the vision. I can think of a few –


    1. Currently on BW, use Database Edition for BW for ALL
      reporting needs.
      1. Transform and optimize landscape for all existing
      2. For all new solutions, use BW content, optimized.                     
    2. Currently on BW, use Database Edition for BW for SOME
      reporting needs.
      1. Transform and optimize my landscape for those models
      2. For all new solutions, or e.g. Student Life Cycle
        data, with 5+ system sources, use HANA Enterprise. [separate instance
        à virtual route]
    3. Currently on BW, use HANA Enterprise for ALL
      reporting needs.
      1. Migration of existing BW models into HANA Enterprise
        as Native HANA models, clean-up.
      2. Start custom building views in HANA, in parallel with
        existing BW
      3. Wait for SAP Accelerators
    4. Have an established non-BW EDW, only want
      some ERP data – move this data into that EDW using DXC.



    • Yep.  It wasn’t immediately clear to me but I don’t think it’s reasonable to expect for your BW projects to get easier in this regard.

  • Its a big achivement and a mile stone to have all the industry solutions supported on HANA by year end.  The big challenge here is to make all industries to upgrade to ERP 6.0, EhP6 in order to run ERP on HANA.  Any thoughts on this ?

    • It will take a while, but this is a long game. I don’t imagine SAP are in a big hurry. There will be a flurry of big names jumping to ERP on HANA over the next 12 months, I guess, but the tail will be very long indeed.

      We’re just upgrading from 4.7 to ERP6 (EHP5) now, at the last possible moment! For us EHP6 is at least 12 months away. Probably longer. And I guess it makes sense to do a DB migration at the same time as the EHP, so as to have one round of testing and production downtime, rather than two, but that makes it a bigger project and so likely to be put off further.

    • Given some of the other commentary on EhP in this blog, I think it will take some time for customers to meet that prerequisite for HANA.  It’s not difficult but it will add to the project timeline for sure.

      Regarding the timing…  it is SAP’s intent to have IS on HANA by year end but that comes with the usual disclaimers of ‘current planning, subject to change, etc.’.  Personally, I’d be impressed if they hit that date and I’d be satisfied if they at least get the top half of the industry solutions available for HANA by year end.

  • Great Blog Nathan – you raise some good points that have come out in the comments.

    The key message is that it’s not the speed of HANA that is used to justify its ROI, it’s the benefit that it provides the business to better manage it’s data and make quicker and more accurate decisions.

    I could not agree more strongly with your quote above.

  • Nathan,

    you mention that the first step is the DB migration.

    First, a DB migration has to be done which SAP expects will only take a few weeks at most.

    There you state that this should be a fairly simple and quick step but what about customers that are not yet Unicode enabled? From what I heard HANA only knows Unicode is that also what you heard? If that is true there are quite a few customers where this will become a more disruptive effort.

    What are your thoughts?


    • Yes, I believe that Unicode is a requirement but this is a good example of why customers should be more proactive in adopting certain changes rather than waiting until they are forced to do so.

  • Based on my experience with BW on HANA, I think ERP on HANA will still be a few years away.

    First thing first, a DB migration that takes a few weeks. Is it acceptable to the business? Nowadays in most organizations ERP are usually tightly integrated with other SAP and non-SAP systems. How these integration issues being addressed during migration is not a small task by its own.

    Secondly will ERP on HANA be really fast for OLTP operations? One of the major issues we have in current HANA revision is that select single in HANA performs quite poorly (When I say poorly I mean 2-3 times slower than other databases). I guess it is fair to say in ERP a lot of the standard codes and custom codes have select singles. Before that issue alone is addressed by SAP (which SAP promised to solve but I haven’t seen it in the latest revision) I don’t think ERP on HANA will deliver much benefits with the financial investment and efforts involved

    • Hi Chris,

      I am pretty sure there will be customers using ERP powered by HANA in Q3 this year (live systems)

      In terms of the DB Migration, I assume Nathan is referring to a few weeks project, so doing this in Dev, Test and Prod. I am not an expert in this area, but would assume a small downtime to perform this, (hours) not days or even weeks.

      • Currently migrating an ERP6 system to HANA is more than just a DB migration. You need to apply a new EHP – EHP 6 for HANA. Even if you have EHP 6 installed already. And I presume you’d treat that like any other EHP implementation project, with whatever level of testing you are comfortable with. The technical migration of a productive system – EHP application plus DB migration – will be more than a few hours of downtime I expect. A weekend activity, surely? I’m certainly no expert, and so could easily be wrong – anybody have a better feel for the duration of the technical migration to HANA?

        That said, I do expect there will be customers live very soon with ERP6 on HANA. SAP have surely got some projects lined up already, and will make sure they succeed. It will be interesting, though, to see when the first “unaided by SAP” project goes live.

    • The ‘weeks’ estimate that was routinely given to us is most likely on a system-by-system basis. 

      I would expect that reporting and processing performance in general is much faster, but writing records, which is more difficult in a ERP system than an isolated DB, is actually slower.  So I’m more curious about the pragmatic performance benefits than just purely reporting.

      • One reason for the delay in supporting ERP on HANA was that write perfomance needed to be improved. With a column-oriented DB, writes are indeed harder, and therefore generally slower. I believe the solution in ERP on HANA is to write to a temporary row-oriented store, allowing the ERP system to continue while in the background the data is transferred to the column store.

        And since the row store is also in memory, write performance is improved over a disk-based DB.

        At least, I think that’s the theory. Hard facts are still hard to find…

  • Hi Nathan,

    An excellent blog. Very Informative.

    Is there any guidelines that can be used to make a case for migration to ERP on HANA?

    Before we consider migrating to HANA should we check if we are using specific processes and if so then migrating to HANA would make sense because we can not only run that process faster but also do much more than before. Or the guideline may be based on the volume of transactions data being processed or used in reporting?

    Thanks in advance for answering these questions and your advise.