Skip to Content

Introducing SAP Fiori, including the SAP Fiori launchpad as the entry point for end users, there are several deployment options available. Which deployment options fits best, depends on several aspects, like the usage scenarios, the system landscape setup and the general strategic direction regarding a cloud or on-premise environment.

The document SAP Fiori Deployment Options and System Landscape Recommendations  describes the main SAP Fiori scenarios, the recommended system landscape setup, and the SAP Front-end server deployment options. It also includes insights into the SAP Front-end server hub and embedded deployment and what aspects to consider. An FAQ section provides answers to common questions regarding the SAP Fiori deployment options and finally you will get an idea on the strategic direction regarding the central entry point of the future.

Please notice that with SAP S/4HANA, there is an important update on the recommended SAP Fiori Front-end server deployment: The general recommendation for SAP S/4HANA systems is an embedded SAP Front-end server deployment instead of a hub deployment. This means that every SAP S/4HANA system has its own SAP Fiori launchpad. Nevertheless, dependent on the existing system landscape and usage scenario a hub deployment in some cases might be preferable. For more details please refer to the above mentioned document.

To offer a single entry point to multiple SAP S/4HANA systems and to central services, as the My Inbox app, you still can define one ‘leading’ SAP Fiori launchpad on a dedicated SAP Fiori Front-end server. From there you can access other system-local launchpads or apps within a new browser tab/window.

This setup simplifies lifecycle and version compatibility aspects and allows a clear separation of FLP content responsibility between business areas.

Please check out the document for details and SAP Fiori scenarios: SAP Fiori Deployment Options and System Landscape Recommendations

For further information, see also:

To report this post you need to login first.


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

  1. Smriti Gupta

    Many thanks for posting a Blog on this. I came to know about it from a linkedin post posted by SAP colleague but now I am double sure about this important update for deployment in case of S4 Hana






  2. Johannes Strittmatter

    This is very bad news for all customers who want to provide a really central entry point to the SAP application world. This launchpad-of-launchpad approach is not what preaches SAP as good user experience!

    Also forcing customers to SAP Cloud Platform to solve this architecture flaw will make customers SAP solutions even more complex and significantly rise TCO.

    As the problems must be solved for SAP Cloud Platform there is no real reason to not provide the solution for on-premise systems (FAQ-No 10).

    1. Carola Steinmaier
      Post author


      following the general SAP Cloud strategy, we plan to offer a solution on cloud first. This central entry point on SAP Cloud Platform is aimed to be a central entry point for cloud and on-premise solutions/systems. The power of the divers Cloud Platform services and capabilites will help to offer a central entry point with a modern user experience, but also the integration and extensibility capabilites, which are expected beyond a SAP Fiori launchpad as it is today.

      Let’s see, what we then can offer for pure on-premise scenarios then. I believe the hybrid scenarios (cloud/on-premise mixture) will get more and more relevance in future.

      Kind regards


      1. Prasanna Kumar S


        Hello Carole ,


        I agree to Johannes Strittmatter as lauchpads of Launchpad is not a good solutions .

        Customers will not accept this kind of an user interface .

        Also the Factsheets and Analytical apps configurations of existing Central FES will not work .

        Exposing each FLP over Reverse Proxy is also time consuming and will increase ROI .

        Is there any plans that SAP will working on customer request .



        Prasanna Kumar

  3. Christian Tapia


    In the case where FES is embedded in one S/4HANA, would there be security risks if a Web Dispatcher is used? As far as I can understand Web Dispatcher would minimize the security risks. Is this right?

    Best regards,

    Christian Tapia S.

    1. Former Member

      Hi Christian,

      you are right, a WebDispatcher (Reverse Proxy) lowers the risk especially if the internal WAF is activated  – but a separate FES system acts as additional line of defense and the NW Gateway does a protocol conversion from ODATA to RFC which is another security advantage. We are hearing this issue often when it comes to mobile usage, customers using their MAM solution with dedicated access to the FES system NOT to the backends.

      See also:

  4. Chandrakanth Angannagari

    Hello, the document is actually sort of tip toeing around the limitations there are at the moment

    and also not giving a clear recommendation. The write up in the blog above states – for S/4 embedded is the recommended option. But the pdf link again decouples various cases like scenario 2,3 and 4.

    My observations are

    a) because of the dependency of Fiori for S/4HANA  and backend versions, it is clear embedded is the right approach to follow. The document also indicates this limitation multiple times – but still for various scenarios e.g. 2) where there is single S/4 with other BS systems in landscape – to use a hub which would first require Hub based on FES 3.0. but would all BS Fiori work on FES 3.0 ? What about FES 4.0 for S/4 1709? if not, this is not a valid solution correct?

    b) for cases where embedded is recommended, what is the security risk? And if there is such a risk, why is this even an option for customers. Recommendation should clearly be for a FES hub isnt’ it?



    1. Carola Steinmaier
      Post author


      Right, the PDF is the main document with details on the different options and scenarios. The blog itself should make aware, that there are some restrictions and an update on the deployment recommendations.

      Remarks on your observations

      a) FES 3.0 with S/4Hana is just an example, FES 4.0 for S/4 1709 would be another one. The point is, that the FES version has to match the relevant S/4HANA version.

      For further information on the release of Fiori products for SAP FES 4.0, refer to SAP Note 2506466, also linked in the PDF under Further Information.

      b) see Sebastian Dobbersteins comment above.

      Kind regards



      1. Chandrakanth Angannagari

        Hello Carola


        thanks for the answer. To be more precise

        1. Is there any foreseen point in time where Fiori for S/4HANA and Fiori for other applications (BS, Solman, PO etc etc) can coexist on the LATEST netweaver versions? I understand that Fiori on the cloud is being made as a integrator but is there something planned for OP also?
        2. If a customer has no mobile use case and no internet use case, can embedded model suffice (from security perspective)
        3. For a customer who wants mobile and internet usage of fiori apps, its clear security would be a major topic to consider. In this case the recommendation should always be a hub irrespective of S/4 versions etc?
      2. Roger Sainsbury


        Hi Carola,

        I agree with Chandrakanth and would go further; the advise for a single instance of S/4 HANA in particular is contradictory.

        The document is initially very clear in recommending the hub approach for this scenario:

        2) One single SAP S/4HANA system within an existing SAP Business Suite landscape
        For multi – system scenarios with only one single SAP S/4HANA system in combination with an existing SAP Business Suite landscape, a central SAP Front – end server as hub is a recommended setup.
        Later in the same document this recommendation appears to be downgraded to be just an ‘option’:
        For a single SAP S/4HANA system scenario the hub deployment is still a possible option.

        In your blog you’ve contradicted both of these statements, by saying:

        For SAP S/4HANA systems it is recommended to use an embedded deployment instead of a hub deployment.

        To minimise further confusion, why don’t you change this staement to match what the PDF actually says, which is:

        For scenarios with several SAP S/4HANA systems the embedded deployment is the recommended setup.
        1. Carola Steinmaier
          Post author

          Hi Roger,

          thanks for your valid comments. I will adapt this.

          The general recommendation for S/4HANA system is ‘Embedded’. But there are several aspects which might be valid, to use a hub deployment instead.

          E.g. if there is already a central FES in place, which connects several SAP Business Suite systems in ONE FLP, then it is less effort and from end user experience aspects better to connect the ONE S/4HANA system also to this existing FES to have one central entry point.

          What is not possible: Using a central FES hub to connect several S/4HANA backends.

          If for  e.g. for security reasons in an internet scenario you prefer a hub deployment, you need a FES for each S/4HANA system.

          Thanks and kind regards



  5. Chandrakanth Angannagari

    Dear Carola

    Also could please clarify the following


    1. if a customer decides to go with embedded for a S/4 landscape, can they later move to a hub model at some point? if yes, what are the technical steps to do so?
    2. If a customer decides to go with on-premise (hub or embedded) , can they later move to fiori on the cloud later at some point? if yes, what are the technical steps to do so?.
  6. Former Member

    I must say — the S/4 embedded option seems like a terrible recommendation. Even if this is SAP’s position (I would be curious who was engaged in that decision, because it seems to contradict many principles), I won’t be recommending it to my customers.


    “Multiple launchpads linked together through new tabs” ?


    This sounds like a technical limitation, not a user experience recommendation.


    Also, this clearly would break a Fiori Client use case.


    I don’t mean to shoot the messenger, but perhaps that recommendation should be revisited.



  7. Carola Steinmaier
    Post author

    Hi Gavin,

    it’s putting the facts on the table. With S/4HANA there are dependencies between backend and UI components, which require to keep backend and UI in sync. In addition there is the technical limitation, that on the same server it’s not possible to install several versions of the same software component.

    In addtion, S/4HANA performance is optimized with embedded deployment. There are several aspects (pros/cons) for embedded/Hub deployment to be considered, as described in the linked document.

    For Fiori Client in fact there is a problem with the handling of multiple FLPs. We have to check that more in detail.

    The Deployment Recommendation paper should help to plan the system landscape accordingly. For SAP Business Suite Sytems Hub deployment is still recommended, also if you add one sinlge additional S/4 system.

    Kind regards


  8. Ignacio Meroño Valenciano

    Hi Carola.

    First of all thank you for this blog, i think is very interesting.

    But after reading the document “SAP Fiori Deployment Options and System Landscape Recommendations ” we have a great doubt..when will be available the SAP Cloud Portal as central entry point?. This document is dated in February of 2018 and we are near to 2019…any news related to this topic?.

    I think that this integration is something that all customers will need late or soon and is really necessary to integrate multiple launchpad and notification of different systems.

    We are expecting to have some news on this topic.

    Best regards.

    1. Carola Steinmaier
      Post author


      the Deployment Recommendations document has been updated today. The recommendation in general has not changed. The central entry point on SAP Cloud Platform is in development. We plan to have a first version in 2019 (Q2).

      Please understand that we can not give more detailed information on the availability, as there are always uncertainties in development.

      Kind regards


      1. Edgar Peña

        Hi Carola, I’ve read the updated document and it’s almost identical to the original one referenced in your blog.

        I have a question though, when it’s stated that there are dependencies between backend and UI components, does it only apply to a scenario on which the fiori apps are deployed on an on premise system?

        Is it possible, for example, to have fiori apps (standard and customer made) deployed on SCP and connect such apps to multiple Hana Backends for data consumption via OData? Why would it matter if the multiple backends are Hana or business suites if all they’d be used for is serve data via standard OData protocol?

        Can you give your insight on this?


        1. Carola Steinmaier
          Post author


          it applies to both: deployment of the UI components on an on-premise ABAP system and on SAP Cloud Platform. For both scenarios, it’s not possible to connect several versions of S/4H backends and include the UIs into One single FLP.

          In future this should be solved via a central entry point on SAP Cloud Platform (Multi-Cloud). This is currently in development.

          Kind regards.


  9. Saurav Sarkar

    Hi Carola,

    Thanks for the great document on recommended options.

    Please correct if my understanding is correct.

    Having a central entry point will mean that Fiori UI itself will be deployed at one place and FLP content will be deployed at respective stacks.

    This will also reduce certain integration outbound communications which happens as of today like from S/4 FLP to CP services. Now those S/4 FLP UIs can directly connect to CP .

    Best Regards,



Leave a Reply