Skip to Content

Understanding SAP Private Cloud, Public Cloud and On Premise – Important for S/4HANA Roadmap

SAP is “The Cloud Company Powered by SAP HANA“, so it is important to understand what different options we now have with respect to cloud / on premise deployments. This is particularly important if you are trying to work out how S4HANA will impact your Business Suite investment.

So this is my understanding of the options we have ?

Public Cloud – Software is 100% managed by SAP as the “cloud provider” with updates automatically pushed to the systems on a timeline defined by SAP with tightly controlled configuration and extension frameworks. For example SuccessFactors, Concur, FieldGlass, Cloud 4 Customer, Ariba,and Hybris have public cloud delivery models. The first offerings of S4HANA will be offered as Public Cloud offerings. Also HANA Cloud Platform (HCP) is offered in the public cloud model and can be used to extend applications (instead of doing this inside) in any of the other deployment models.

Private Cloud – Software is 100% managed by SAP as the “cloud provider” but update schedules are agreed with the customer, some software modifications are allowed but these will increase the fees to run the system (as it is harder to manage). S4HANA will offer this model and Business Suite is offered this way via the HANA Enterprise Cloud for customers that run it on SAP HANA.

On Premise – This is the model that most SAP customers are familiar with, where software is installed and run by the customer (sometimes this is done by an outsources service provider or hosted by a service provider). In this model we can have as many modification as we like – but they will increase the cost of ownership as each needs to be considered each time an upgrade / patch is applied. S4HANA will be offered in this model.

One analogy that I like is that of the Mobile Phone :-

Public Cloud – This would be how my Mum consumes her SmartPhone, she comes to me and tells me what she wants, I set it up and she uses it. When she wants something difficult, I tell her that the phone can’t do that 😆

Private Cloud – This is a bit like how I use my SmartPhone, I have loads of apps and accessories but all of them have come from the phones app store and are supported by the phones manufacturer.

On Premise – With HANA – This is like my daughters SmartPhone which she has hacked to mean that she has access to the guts of the phone, writes her own apps and downloads stuff from un-official websites – all at her risk.

On Premise – Without HANA – This is like not running a SmartPhone and saying “why do I need to do anything but phone, text ?”.

The graphic below shows how I think the software under your system might change depending upon your chosen model.

Screen Shot 2015-02-04 at 07.45.16.png

Screen Shot 2015-02-04 at 07.45.16.png
You must be Logged on to comment or reply to a post.
    • I think the SoH view would either look like Classic (if you didn't do any of the Simple Modules) or On Premise S/4HANA if you did go for Simple Modules (over time).

  • Loved your comparison with the mobile phone world 😆

    And it won't take long that SAP will ask you the whether they are allowed to use your graphic. Crisp and clear representation!


  • Owen, thank you. Your presentation is great.

    Maybe I missed something, but I'd like a clarification from you.

    What about all the tons of ABAP development made around ECC 6 ?
    Where are they placed in your smartphone analogy ? I see them in the "On premise" solution, isn't it ?

    EVERY SAP customer today has hundreds or thousands of custom ABAP transactions... what about them in the transition to S/4 HANA ?

    • In my analogy, they would be either the on-premise with HANA or on-premise without HANA.

      As the simplified modules are delivered / turned on it may be necessary to re-work those custom transaction......this will depend how well they were developed in the first place.

      Developing custom requirements "on top" using services using HCP (cloud) or Process Orchestration (on-premise) will minimise rework and oil the cloud wheels.

      • I see what you mean.

        But, in my opinion, this is just a (little) part of the problem, since a great part of custom developments are not replaced by simplified modules.

        I mean all specific developments made for peculiar LoB or Industry out of the standard of the Best Practices. These developments are currently a great part of Application Maintenance, which is a basic source of revenues for our companies (SAP Partners).
        Do you think customers should accept to re-work all these ?

        It can be true, maybe, on a very long time span. So, IMHO, the great part of current SAP customers, migrating to S/4 HANA, will choose the only option they have now : On Premise.

        Well, of course, this is just my opinion, but I think to know quite well (after 25 years working in SAP consultancy and 35 in IT) the reality of the market, at least where I live and work (Italy).

        Keep up the good work and thank you for sharing your advice and thoughts.

  • Most of the S/4 HANA articles refer to Public and Managed cloud.

    So is "Managed" the same as Public (managed by SAP) or Private (managed by client).

    Many thanks

    • Managed = HEC which means On Premise software running in a HEC data centre but you can do what you like to the software.

      Public = You can't modify / config like you do with On Premise version.

  • Hi Owen,

    Would there be any implementation considerations to take into if:

    SAP Hybris (this would be private cloud) and then integrated to S/4HANA (which is in public cloud).

    Your thoughts? 🙂

  • I assume both SAP's public and private cloud options involve shared architecture, correct?  In other words, SAP has come up with their own definition of public vs private cloud which does not relate to the industry definition.

  • Hi Owen,

    Nice article . Thank you .

    My question : It is now a common practice to have HEC - private cloud for the core ERP functions and have the public cloud for the UI ( Fiori) developments . How does this work  meaning , why should a customer use public cloud for UI developments ?

    is it not a additional tasks for the customer to maintain the connection between public and private cloud  ( for the Fiori to work ?) or it is advantageous  to use at least some part of SAP public cloud ( in a HEC private implementation) for any specific reason ?

    Thank you .

    • I'm not sure I would call it common for customer to have the UI in SCP but this is an option for deployment and comes with the classic benefits of the cloud where you don't need to worry about hardware or software versions - but you are right you do have to deploy the SAP Cloud Connector to make it work.

      Even If you select to go for the On Premise deployment of Fiori on either the same app server running S/4HANA or a Front End server it is recommended to use Web-IDE to do any mods and to use this in an easy way you need the same SAP Cloud Connector (you can work round that in a couple of ways but they are clunky IMHO).

      For development of custom apps the deployment location can be guided by the services that they use (only from S/4HANA or some of the micro-services in SCP.

      Basically you have flexibility and with that flexibility you have to make choices and trade offs - security, network, developer skills etc


  • Hi Owen,

    A wonderful article that I have been searching for. Can you please clarify the below questions,

    1. I understand that the data in the public cloud will belong to various clients. If so how are they differentiated when queried. Are they logically separated or physically separated.
    2. My company is running ECC which has some in-house Web services integrated to it. If we plan to move to a Public cloud solution can we still integrate the existing web services. Will Public cloud allow this?

    Thank you.