AI generated image of a frustrated man surrounded by clouds and on-premise servers

This week I saw an interesting data point in a ComputerWeekly article (CW) from the opening keynote at the start of the UK and Ireland SAP User Group’s Connect23 annual conference:

Our latest member survey shows 79% of those that have moved to S/4HANA have an on-premise or hosted deployment. Of those that are planning to move to S/4HANA, 70% plan to move to on premise or hosted versions.

This resonated with me after my experiences in Copenhagen at SAPinsider a few weeks ago, which I also debated internally.

Given my focus on cybersecurity and cloud compliance, my view is limited. Others are better qualified to discuss the relative functional and commercial merits of moving to RISE or stay on-premise and there can be a variety of factors at play I know nothing about. However, I try to understand from customers what their motivations are from a security perspective and what challenges they are working through. I also listen to customer-facing colleagues and our partners in the ecosystem.

What is remarkable is that the reasons given by customers to decide one way or the other are often the same.

Both customers moving to RISE and those planning to stay on premise both tell me they do so for security and compliance reasons. That obviously leads to follow-up questions about how they came to their conclusions. Let’s go over several common reasons I hear.

SAP Systems Are Critical to Business Operations

Common across all customers are calling their SAP systems critical to Business Operations. It is for this reason that I love to collect “failure mode” stories from our customers. That is, what would happen if the SAP systems didn’t work. Severe outages or security incidents have dramatic cascading cyber-physical impact that can affect supply chains, logistics and distribution, manufacturing, retail businesses and government services we rely on.

Availability is critical. A marquee customer in the Aerospace & Defense industry early this year told us that they had a major outage last year that “made us realize we rely even more on SAP than we thought we did”. It was one of the drivers for them to move to RISE.

Others maintain that they want to control the availability of their systems themselves, because of the criticality to their business.

We Are a Small Team That Can Only Do So Much

Security teams are rarely large enough for the risks that they need to manage. Customer security teams for SAP systems are even smaller, and many security and compliance tasks may be performed by SAP system administrators rather than security specialists. Teams must focus where they have the most impact and provide the biggest value to the business. Therefore, tasks like change management, SAP and operating system upgrades, secure configuration, IAM and role-based access control (RBAC), networking, custom code security, threat detection and incident response all need to be prioritized.

Availability is at the core of the reason why customers historically have struggled to keep systems up to date, especially for Security Notes or upgrades that require downtime. With often only few opportunities in a year for scheduled downtime, carefully negotiated with business owners, systems can fall years behind. We see this with RISE customers where we go through several cycles of upgrades and updates when we bring systems in.

Some customers choose RISE or GROW to have SAP manage updates and Security Notes for them, as well as the underlying infrastructure, network configuration, threat detection, incident response and recovery. Others choose to do that themselves or engage a third party service- or hosting provider.

We Have a Large Estate of ECC6 Systems, Still

Through natural growth and acquisitions, many customers ended up with dozens of SAP systems at a variety of versions and patch levels. A move to S/4HANA is often an opportunity for consolidation to bring the number of systems down and remove legacy and technical debt from the landscape. Some customers have already made the move but still run a number of legacy systems. Others are still in planning mode. We see that also reflected in the UKISUG survey in the CW article quoted above.

We have customers who do that consolidation through RISE with the direct help of the vendor. Others are doing it themselves or again with a third party. I have heard customers mention their existing ECC6 estate and the looming 2027 deadline as a reason to move to the cloud with RISE, to revitalize their systems, move faster and take advantage of innovation. Other customers have given it as a reason why they are not yet ready for cloud.

We Need Data Residency

Our cloud customers have told us for years that they need to ensure data remains within certain jurisdictions. The most common concern is around data transfers between the European Union (EU) and the United States (U.S.), despite agreements such as Safe Harbor, Privacy Shield and Privacy Shield 2. SAP and many of our customers have long ago started to side-step the problem and consolidation of SAP systems on S/4HANA are typically done by data residency jurisdiction.

In supporting RISE sales deals with customers for whom security and compliance are of critical importance, data residency inevitably comes up. Figuring out the deployment strategy, including NS2, EU-only and Sovereign Cloud options, between the customer and the SAP team centers around juggling the various data residency and regulatory requirements. SAP’s experience in navigating the laws and regulations in different jurisdictions for ourselves and with customers’ industry peers is often appreciated in these discussions.

Other customers decide that the solution to data residency compliance is to run their systems in geographical locations of their choice and control the problem themselves.

We Must Meet Complex Regulatory Compliance Requirements

Virtually all customers I meet are in regulated industries, public sector, or considered critical infrastructure. They all need to meet complex regulatory compliance requirements. By extension, so does SAP. With the increasing rise in cybersecurity threats, governments around the world are sharpening requirements, adding to the challenge, especially for those with multinational business operations. We work with standard bodies, advisory boards and government institutions to provide input and feedback, and implement programs internally to support customers by the time new legislation goes into effect.

Our security policies are abstractions based on a multitude of ISO and NIST standards, regional requirements such as KRITIS or ISMAP, and recognized security best practices. That gives us one policy set that instructs the organization what we expect of them, while meeting all the various compliance requirements for different regions and industries. There are entire teams dedicated to make that work. Its importance is reflected in the new name for SAP’s security organization: SAP Global Security & Cloud Compliance.

Not all customers can bring the same resources to bear as SAP can. Many customers, therefore, cite their need to meet various cybersecurity and compliance regulations as a reason for moving to RISE. This includes customers in Aerospace & Defense, Energy and Utilities, Manufacturing, Mining, Finance, Life Sciences, Food and Beverage, and Agribusiness.

Yet other customers in the same industries tell us that they cannot move to the cloud for security and compliance reasons.

If those customers who chose RISE said one thing and committed on-premise customers said another, that would be easy to understand. I could imagine one set of customers stressing the need for agility in their business operations while expanding into new markets. Another set could mention a more conservative business culture or risk acceptance levels, or a need for greater control. But hearing the same arguments for a move to RISE used by other customers to stay on-premise is curious.

The CW article provides a possible, uncomfortable explanation. It is in regard to a different topic, but we have to take customer trust into account. When some customers prefer to engage with a third-party service- or hosting provider that suggests that there is a segment that trusts our software to run their core business operations but doesn’t trust SAP to run it for them.

In lieu of a better explanation, we must assume that customer trust is a factor. That, then, is something we must work on. Increasing transparency about how SAP operates secure and compliant cloud services is a key pillar in SAP’s security strategy. We have been working for several months now to help facilitate that and I am excited for what we planned for 2024.