How to Choose the Right Cloud and Managed Services Provider for SAP S/4HANA

Organizations that select the right cloud hyperscaler and managed service provider for their SAP workloads can reduce unplanned downtime, improve operational efficiency, and ultimately achieve positive business outcomes. This research provides heads of infrastructure and operations with key dimensions to consider when evaluating these providers.

Selecting the appropriate cloud hyperscaler and managed service provider (MSP) for hosting and operating SAP S/4HANA is critical to your organization’s ability to achieve long-term digital transformation objectives.

Key Insights:

• Leading cloud hyperscalers are officially certified by SAP as “cloud IaaS providers” to host SAP software. Their differentiated value lies in offering an extensive portfolio of services that go beyond standard IaaS functionality.
• SAP community clouds are unsupported by SAP. They offer lower-cost solutions but may increase risk and lack access to hyperscaler-native services.
• Most organizations rely on a managed service provider (MSP) or system integrator (SI) to reduce the risks of building and maintaining an SAP environment hosted on hyperscalers and the operations burden of such projects.

Actions:

• Prioritize cloud providers that are officially supported by SAP for critical SAP estates. Select your cloud provider by evaluating platform resiliency, disaster recovery capabilities, integration with value-added services, the breadth of the local partner ecosystem, and technical compatibility with both SAP and non-SAP systems.
• Use SAP community cloud providers for low-risk SAP estates, such as read-only environments to be kept for legal or compliance purposes.
• Reduce risk and increase operational excellence by engaging an MSP that is able to master SAP on the public cloud. Prepare an exit strategy from the chosen MSP by contrasting the benefits of its tooling with the complexity of reconfiguration and downtime needed to move to another provider.

Organizations planning to deploy SAP S/4HANA and other SAP NetWeaver or SAP ABAP platform-based solutions in a public cloud hyperscaler are often confronted with an overwhelming array of options from both global and local cloud service providers.

Customers choosing their cloud provider for SAP cloud services and software must extend their evaluation criteria beyond pricing and migration incentives.

Customers should choose cloud providers by assessing five main capabilities: cloud resiliency, disaster recovery, value-added PaaS and SaaS services, partner ecosystem, and technicalities. All of these capabilities should have a tangible effect on your organization’s business outcomes and goals.

Additionally, organizations moving their SAP estate to the public cloud often realize that their internal team — or their current MSP — may lack the specialized skills required to fully leverage the benefits of cloud computing.

Customers should prioritize providers who demonstrate a willingness to listen while delivering services that benefit each organization’s needs, have a proven track record of delivery excellence, and are willing to define upfront tasks and the cost of exiting from that MSP.

• Differentiate between two primary categories of providers: cloud IaaS providers — officially supported by SAP — who deliver a comprehensive portfolio of services extending beyond basic IaaS capabilities; and SAP community cloud providers, who typically offer lower-cost solutions at an increased level of risk.
• Choose your cloud hyperscaler focusing on cloud resiliency, disaster recovery, value-added PaaS and SaaS services, partner ecosystem, and technicalities, all in support of your organization’s business goals.
• Reduce risk and increase operational excellence by engaging an MSP that is able to master SAP on the public cloud by measuring MSP’s willingness to co-design capabilities to tailor the offering to your organization’s specific requirements, MSP’s ability to support the application layer, industry-specific knowledge, and availability of credible customer references.
• Prepare an exit strategy from the chosen MSP by contrasting the benefits of its tooling with the complexity of reconfiguration, extra costs and downtime needed to move to another provider.

• Prioritize cloud providers that are officially supported by SAP for critical estates. Use SAP community cloud providers only for low-risk SAP estates, such as read-only environments to be kept for legal or compliance purposes.
• Request a timeline from SAP and/or MSPs detailing each expected enhancement postmigration and tie these to your specific business’s goals.
• Avoid making cloud provider selection based solely on price or migration incentives. Treat this choice as a long-term strategic decision, with a 10 to 15 years outlook.
• Exercise caution with MSPs that lack credible customer references or demonstrate an unwillingness to tailor their services to your organization’s specific requirements. Such limitations can result in project delays, delivery challenges, and ultimately pose risks to your business.

This research note outlines best practices relevant to running SAP applications on multiple cloud hyperscalers and managed service providers. The SAP-recommended solution, SAP Cloud ERP Private is managed and operated by SAP on its reference architecture. This research note highlights key differences associated with this solution when relevant for the reader.

Organizations evaluating the deployment of SAP solutions built on SAP NetWeaver — including SAP Business Suite, SAP BW, and SAP Process Orchestration — or seeking to leverage SAP software based on the ABAP platform, such as SAP S/4HANA, within a cloud provider, are often overwhelmed by the offerings of global and local providers. Many providers market their services as delivering a “cloud experience” or offer cloud-like billing models. Customers need to differentiate between two principal categories of providers: cloud IaaS providers and SAP community clouds.

Cloud IaaS providers. These providers are among the largest public cloud hyperscalers. They are officially recognized by SAP,1 which supports the deployment of SAP-based products on their IaaS environments:

Alibaba Cloud, Amazon Web Services (AWS), Google Cloud, Huawei Cloud, IBM Cloud, IBM PowerVS, Microsoft Azure and Oracle Cloud Infrastructure (OCI). On each cloud provider, SAP prescribes the prerequisites, supported SAP and database products, and infrastructure components validated by SAP.

Cloud hyperscalers offer seamless integration between SAP systems and their portfolio of value-added services, including AI such as machine learning and GenAI, as well as big data solutions and additional capabilities. By leveraging these advanced capabilities, organizations can enhance business KPIs by enriching and augmenting data stored within SAP systems. Achieve SAP S/4HANA Reliability and Extensibility in the Public Cloud provides further details about SAP architectures in public cloud and extensibility options.

The alignment between these services and the digital ambitions of an organization often drives the cloud provider choice. This creates a compelling business case for migrating and rehosting SAP environments on hyperscaler cloud platforms. Also, cloud hyperscalers provide a set of specialized tools and reference architectures specifically designed to optimize the experience for SAP workloads. Numerous MSPs deliver implementation and management services for SAP on cloud IaaS providers.

SAP community clouds. Some MSPs and certain speciality cloud providers offer managed or unmanaged shared infrastructure designed for running SAP-based software in a cloud-like model. While most of these providers use SAP-certified hardware and software stacks, not all providers can deliver end-to-end quality of service to different customers across all components. Customers selecting this deployment model gain access to the same SAP software, customization capabilities, and industry-specific solutions as they would when running their systems on an SAP-certified Cloud IaaS provider.

SAP does not certify a shared community cloud stacks as cloud IaaS providers, and may require issue reproduction in a supported, dedicated tenant, prior to providing product support.

Customers choosing this model often benefit from a lower price per compute and storage resource compared to public cloud hyperscalers but cannot consume any value-added hyperscaler-native PaaS or SaaS services at low latency and egress cost, as they are unique to hyperscalers. Additionally, customers should understand during negotiations what and how SAP community cloud providers will support them in the event of any objections from SAP related to performance issues.

SAP Cloud ERP Private is a first-party solution in which SAP provides managed outsourcing services and end-to-end software support on top of various cloud infrastructures. Within this offering, SAP supports a different set of providers. While SAP delivers multiple service variants, as outlined in Choosing a Suitable S/4HANA Cloud, Private Edition Service Variant, hosting options for the SAP Cloud ERP Private offering family can be broadly categorized into two primary types:²

• SAP private cloud on hyperscaler: SAP offers SAP Cloud ERP Private services3 on Amazon Web Services (AWS), Google Cloud, IBM Cloud,⁵ IBM PowerVS,⁵ and Microsoft Azure.
• SAP sovereign cloud: SAP delivers SAP Cloud ERP Private services within a range of sovereign cloud environments, specifically designed to address the regulatory compliance and data residency requirements of individual countries or geopolitical regions. These environments encompass first-party solutions, such as SAP Cloud Infrastructure for EU customers, as well as third-party offerings, including AWS European Sovereign Cloud (Europe), AWS GovCloud (U.S.) and Microsoft Azure Government (U.S.). Additional options, such as Delos Cloud, a partnership with Microsoft Azure to provide sovereign cloud services for the German public sector, have been announced but are not yet generally available.

Customers choosing their cloud provider for SAP workloads must extend their evaluation criteria beyond pricing. Gartner has observed that, while comparing different cloud providers offering similar capacity on cloud regions within the same geographical area, the difference is often negligible.

Furthermore, public cloud hyperscalers often offer migration incentives (such as AWS Migration Acceleration Program,⁶ Google Cloud Rapid Migration and Modernization Program,⁷ and Microsoft Azure Accelerate⁸) that decrease costs, including credits toward migration services from certified partners. These can present a very attractive TCO going forward to develop a closer relationship between the customer and a hyperscaler for strategic long-term partnerships lasting 10 years or more.

Gartner recommends engaging with a MSP as a first step, sharing your business goals and desired IT outcomes. Leveraging their expertise and experience with similar clients, the MSP can then guide you in selecting the most suitable cloud hyperscaler for your needs.

As shown in Figure 1, the five main distinguishing capabilities for cloud hyperscalers relevant to SAP workloads are: cloud resiliency, disaster recovery, value-added PaaS and SaaS services, partner ecosystem, and technicalities.

Cloud platform resiliency — Explore the effective capabilities of the chosen cloud provider to deliver a resilient cloud platform to be used as the foundation for deploying critical SAP workloads. Seek inquiry-specific public cloud architecture and resiliency features, and favor cloud providers that provide multiple zones in a region, with each zone hosted in a geographically dispersed physical location. These architectures provide more resiliency to SAP systems. Give preference to a regional-based cloud control plane architecture with critical services, such as identity and access management (IAM) and key management systems (KMSs), spread across at least three availability zones. Refer to Plan for Resilience Against Regional Cloud Failures for additional details. Also, if you are planning to deploy multiple systems without any multizone/high-availability configurations (such as nonproduction systems or sandbox systems), ensure that the SLA offered is for a single virtual machine deployment.

Disaster recovery — Assess effective cloud providers’ capability to support a disaster recovery scenario for SAP, matching your RPOs and RTOs. Focus on:

• Capacity reservations: Organizations are experiencing an increase in cloud capacity shortage issues, particularly on Microsoft Azure, which may impact your ability to implement failover strategies for your SAP estate. Verify your cloud provider’s capabilities and constraints in reserving compute, storage, and bandwidth capacity for systems that need to be deployed as part of your disaster recovery plan. Refer to Avoid Disruption by Planning for Public Cloud Capacity Shortages for additional details.
• Cloud-native disaster recovery features: Some cloud providers — notably AWS and Azure — offer cloud-native disaster-recovery-as-a-service (DRaaS) solutions. Other cloud providers offer more complex native solutions (such as DIY solutions based on custom scripts). There may be a need to acquire and maintain third-party software.

Value-added PaaS and SaaS services — Explore effective cloud providers’ capability in shifting from being your organization’s next data center, providing only technological capabilities for running SAP workloads, to being able to augment the value of data stored in SAP solutions. Major hyperscalers allow the possibility to integrate your SAP data with hyperscaler-native (non-SAP) PaaS and SaaS services (such as data lakes, big data and analytics, AI, ML, etc.) to build industry-related use cases with a direct impact on your business’s KPIs.

Data proximity between SAP systems and the most data-intensive PaaS and SaaS services should be your primary driver for selecting a specific cloud hyperscaler, as this reduces latency and egress costs.

Partner ecosystem — Evaluate the number and experience of reputable, SAP-certified MSPs in your geographical area by focusing on the breadth and depth of their capabilities in running SAP with chosen cloud providers. Set up a proof of concept (POC) for testing effective capabilities in the area of interest and explore the MSP’s experience in co-designing a public cloud transformation and operations deal tailored to your needs.

Technicalities — Although SAP HANA is the standard database for SAP S/4HANA, SAP BW/4HANA, and many other SAP products, other SAP systems based on SAP NetWeaver or SAP ABAP Platform might run on different databases (AnyDB in SAP terminology). These include Oracle RDBMS, IBM Db2, Microsoft SQL Server, and SAP ASE. If you have a AnyDB landscape, ensure that your cloud provider can support all the databases and the required operating systems you plan to use for your SAP systems. This also applies if you are planning to move to cloud historical systems kept in read-only mode to satisfy compliance/legal requirements.

Cloud providers are also able to offer different CPU/RAM ratios of SAP-certified instances; this is extremely important while deploying advanced AI/analytics use cases within your SAP systems. Verify that your cloud provider can support all the non-SAP systems connected to SAP (often called “satellite systems”) that you want to move to the cloud. They will also need to support third-party appliances (notably NetApp-based appliances) to reach the storage KPI that your solution requires.

Table 1 below summarizes the key differentiators relevant to SAP systems that each major hyperscaler. While some of these differentiators can also apply to SAP Cloud ERP Private, some of these benefits can only be leveraged by customers deploying their SAP systems on IaaS.

While engaging with an MSP to handle your SAP workloads in cloud, consider the following main dimensions:

• Engage through dynamic sourcing: Verify MSPs’ expertise in engaging on dynamic sourcing to co-create a complex SAP transformational and managed service solution tailored to organizations’ needs. This lowers the uncertainty of specifications in terms of solution architecture, automation and performance. For further information, see Use Dynamic Sourcing to Negotiate Complex Managed Services Deals.
• Evaluate support for the application layer: Check whether the potential MSPs can also provide support on the application management layer or whether it is limited up to SAP Basis. This support might include partial or complete application management, or support for cloud extensibility. Contrast the approach of adopting a single provider for managing the whole SAP stack but risking a higher lock-in and losing in control, versus using different providers for cloud and SAP Basis management and for application management.
• Organize a POC: Examine the strength of each MSP’s claimed capabilities in building, transforming and running SAP in the cloud provider of choice. Consider POCs and/or demos as a means to test these capabilities and explore important aspects like how (and if) self-service access to the capability is possible.
• Assess industry knowledge: Assess the industry knowledge of your potential MSP in order to bring to your lines of business (LOBs) value-based enhancement to your SAP platform through public cloud PaaS and SaaS services. Industry-oriented MSPs must be able to engage in generative relationships and agree on industry- or enterprise-specific outcomes that will be achieved through collaborating in co-creation or similar arrangements.
• Obtain/gather references: Request that the MSPs arrange reference calls (ideally at least three) with clients that are similar to your target profile. References should refer to activities performed in the last 12 to 18 months and delivered by the same pool of resources to be used in your engagement. Engage reference clients to gain their feedback on the provider’s strengths and weaknesses across tools, skills, and processes.

When comparing the average duration of a partnership between a customer organization and an MSP, it is shorter than the average relationship with a cloud provider and even shorter than the life span of an ERP suite such as SAP.

Thus, customers subcontracting the management of their SAP systems in the cloud to an MSP must carefully plan their exit strategy from that MSP. They also need to seek contractual protection to ensure that exit activities occur with minimal downtime and no or few extra costs.

As part of a planned exit strategy from an MSP, organizations should focus on:

• Directly acquiring cloud capacity. Procure cloud capacity directly from the hyperscaler, rather than through your MSP of choice or a third-party cloud reseller. While these alternative arrangements may appear simpler or necessitate less governance, they often require a technical migration to relocate the workload when changing cloud resellers.
• Evaluating the MSP’s tooling. Assess which capabilities are provided through cloud-native tooling and which are provided by the cloud management platform offered by the provider. Inquire about the ownership of the intellectual property of infrastructure as code (IaC) artifacts and ensure which licenses/subscriptions will be passed to your organization after the end of the contract. Contrast the advanced features offered by the intellectual property of the provider versus the portability to another provider.
• Planning an exit. Most modern, SAP-oriented MSPs allow the customer to take over cloud subscriptions to new providers after they have uninstalled any proprietary or as-a-service tools. Less sophisticated providers can require customers to undergo a migration (such as a full SAP reinstallation on another cloud subscription and a homogeneous system copy) while exiting the contract. Ensure that your provider supports the first scenario or contractually limits the maximum downtime you can afford on the production for your exit plan. For a deep discussion of this topic, see How to Create a Public Cloud Integrated IaaS and PaaS Exit Plan.

When a customer transitions to SAP Cloud ERP Private (an option often called “buying SAP RISE”), any existing perpetual licenses are terminated, and the customer adopts a subscription model in which software usage rights, cloud infrastructure, and managed services are bundled. Customers are not permitted to use software subscriptions acquired through SAP Cloud ERP Private to operate their systems outside the SAP Cloud ERP Private environment.

If a customer wishes to exit SAP Cloud ERP Private at the end of the contract term but continues to leverage SAP software such as SAP S/4HANA, they must terminate their SAP Cloud ERP Private agreement and purchase new perpetual on-premises licenses from SAP. This constitutes a new commercial transaction between the customer and SAP, subject to SAP’s pricing and policies at the time of purchase.

SAP indicates support for multiple data handover methodologies between SAP Cloud ERP Private and the customer environment, including data replication where technically feasible.

Organizations who successfully choose the right cloud provider and MSP for handling their SAP workloads will benefit from lower unplanned downtime, operational excellence and positive business impact. Success for this initiative requires heads of I&O to measure in their evaluation:

Public cloud provider:

• If your SAP landscape has stringent technical requirements that can be met by only a subset of SAP-supported cloud IaaS providers, prioritize those providers. As hyperscalers’ support for SAP workloads continues to mature, this consideration has become less significant for the majority of organizations. However, this dimension may remain relevant for enterprises with very large SAP estates.
• Prioritize cloud providers that are strategically aligned with your overall cloud strategy, as this increases the likelihood of achieving optimal data and AI proximity between your SAP workloads and external customizations. These customizations will likely be developed using value-added PaaS and SaaS offerings — such as AI/ML, data platforms, and IoT solutions — from the same provider selected to host your SAP estate.
• Consider the depth of SAP knowledge the enterprise support of your cloud provider is able to provide to your organization. Interview the potential technical account manager (TAM) as part of your cloud provider assessment prior to finalizing your selection. Additionally, include a contractual clause that grants you the right to reject a future TAM who does not meet your requirements.

• Willingness and ability to customize their services to meet your organization’s specific requirements, rather than requiring your organization to conform to inflexible, standardized offerings. Flexibility and customer-centricity will ensure that the service delivery aligns with your unique needs and operational objectives.
• Rather than prioritizing SLA achievement — which is often subject to complex contractual definitions and legal negotiations and may not accurately reflect service quality — focus on the actual delivery quality experienced by your organization. During the selection process, request that potential MSPs facilitate introductions to reference organizations of similar size and maturity; engage with these references to assess their satisfaction with the provider’s services. Postcontract, establish a structured feedback mechanism by having key stakeholders — including infrastructure leads, SAP Basis managers, application teams, and business units — evaluate the MSP’s performance on a monthly basis. Use a five-point Likert scale for scoring, with a minimum acceptable rating of 3, and target scores of 4 or 5 to indicate high-quality service delivery.
• Establish a co-investment mechanism with your MSP, whereby any cost savings realized through automation and process improvements are allocated equally: 50% as a rebate or discount to your organization, and 50% reinvested to enhance the provider’s cloud management platform for all clients, including your organization. When evaluating potential providers, inquire whether they have existing co-investment programs and request specific examples of platform improvements delivered over the past five years. Define a clear baseline for anticipated enhancements and savings attributable to automation and hold the provider accountable postcontract to deliver on these commitments or provide transparent justification if targets are not met.