Skip to Content
Technical Articles

SAP Fiori Deployment Options and Recommendations

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  (updated version April 2020) 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, the general recommendation is an embedded SAP Front-end server deployment. This means that every SAP S/4HANA system has its own SAP Fiori launchpad. Dependent on the existing system landscape and usage scenario a dedicated 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.

In future a central entry point on SAP Cloud Platform is planned to act as UX integrator for all SAP and non-SAP products (on-premise and cloud).

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

For further information, see also:

You must be Logged on to comment or reply to a post.
  • 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






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

    • Hello,

      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



        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

  • Hello,

    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.

    • 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:

  • 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?



    • Hi,

      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



      • 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?

        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.
        • 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



  • 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?.
  • 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.



  • 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


  • 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.

    • Hi,

      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


      • 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?


        • Hi,

          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.


  • 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,


    • Hi Saurav,

      the new concept of a central entry point on SAP Cloud Platform means, that the Fiori UIs and FLP are part of the product, which is a self-contained entity (as e.g. SAP S/4HANA 1809 on-premise system).

      The central entry point is the UX integrator of all these different products and and renders the UIs of the integrated products in an iframe. With that it will be possible to integrate apps from different systems with different UI5 versions.

      Kind regards


    • Hi,

      having S/4H Fiori UIs and backend components on the same platform and on one server (embedded FES is recommended)  -  simplifies the setup (Rapid activation) and the software lifecycle process (version dependencies) of SAP Fiori.

      Kind regards.


      • Carol,@carola.steinmaier   we are going live on a hub deployment 800 million dollar company with maybe 400 users with hec .. They originally started in 2017 and have taken a while..  They have not room to change now,  but is there any reason if they are  99% s/4 1 backend,  they should not move to the embedded gate way?


        They are also connecting SAC ..   even if they have the hub,  should they connect SAC to the odata model of the embedded and use both gateways until they can get off the hub model for everything.... Is there any reason you can think of to keep hub for a company of this size?



  • Hi Carola,

    Appreciate your time to write this post, helps clarify a lot.

    Couple of questions:

    1. Is there a tentative roadmap of SCP Single Entry Point? I could not find anything specific to this product on
    2. For a hybrid deployment option(backend onpremises and FES on the cloud) the document states that SAP will not deliver content packages after 1709 in alignment with the UX integration initiative, Single Entry Point. With this in mind, for new implementations with target date 2020 does it make sense to invest any time exploring this option? Is there a BETA version of SCP Single Entry Point to do some early testing?

    Thank you!



    • Hi,

      1. Regarding the roadmap for the central entry point on SCP, please refer to the SAP Cloud Portal Roadmap., as the central entry point on SCP is based on the Cloud Portal Service.
      2. SAP will not deliver further S/4HANA content packages on SAP Cloud Platform (Neo). As a technical deployment option (UIs on SCP and Backend onPremise ) it's still a valid option, e.g. for custom apps. Looking forward, the investment goes to SCP Multi-Cloud, where a hybrid deployment is also a valid scenario. Nevertheless the S/4H content is delivered onPremise or with SAP S/4HANA Cloud as cloud solution.

      Kind regards.




  • Hi Carola,

    We are having SAP CAR as one of the system in the landscape. Is it recommended to have SAP fiori setup in HUB or the embedded in such senario for SAP CAR?


    Also is there limitation with embedded approach for business suite.




  • Dear Carola,

    Appreciate your time to write this post, helps clarify a lot.

    As per your quote " Having S/4H Fiori UIs and backend components on the same platform and on one server (embedded FES is recommended)  -  simplifies the setup (Rapid activation) and the software lifecycle process (version dependencies) of SAP Fiori."

    if incase we are Upgrade/moving to Fiori 2020 embedded concept  from standalone FES 6.2.

    1. Can we copy data source(1709) or content of Fiori Central HUB FLP UI /FLP Content  to Fiori 2020 embedded on S/4 HANA 2020 and how if already S/4 HANA 2020 Product on cloud.
    2. For Embedded Fiori 2020 Add-on product , Hope we can maintain the same System ID as S/4HANA 2020. (for example S4H)
    3. Is there any other dependencies and precaution to be considered before Upgrade.



  • Dear Carola,


    Would like to upgrade the FES 5.0 to FES 2020 as the we are upgrading S4 from 1809 to 2020 ,

    We are looking what will be the impact in existing configuration of Fiori apps which were configured in FES 5.0 ,


    Thank you ,



    • Hi Vikas,

      please refer to official upgrade guide and the related notes.

      For  expected changes on app level please refer the Fiori apps reference library.

      After the upgrade the SAP Fiori launchpad content manager is recommended to analyze the FLP content in the systems (e.g. catalogs, activation status of OData and SICF services,...)

      Kind regards