Comparing SAP Deployment Models: Licensing, Responsibilities, and Risk

Comparing SAP Deployment Models: Licensing, Responsibilities, and Risk

Executive Summary

CIOs and IT leaders face critical decisions when choosing how to deploy SAP systems – on-premise or in various cloud models – each with distinct licensing implications, shifts in responsibilities, and risk exposures.

This report, written from the perspective of an independent SAP licensing expert, examines how on-premise, SAP HANA Enterprise Cloud (HEC), private cloud (managed by third parties), and public cloud (IaaS on AWS, Azure, or GCP) deployments differ.

It compares who owns or subscribes to the licenses, how support and infrastructure responsibilities are divided, and what hidden risks (like indirect access and database licensing constraints) CIOs must manage.

The goal is to help leaders align deployment strategy with cost control and compliance.

Key takeaways include:

• On-Premises: Customer purchases and owns SAP licenses (perpetual), manages all infrastructure and support, and bears full compliance risk (including user licensing and indirect access). Upfront costs are high, but long-term control and flexibility can lead to lower total cost of ownership (TCO) if well-managed.
• SAP HANA Enterprise Cloud (HEC): A SAP-managed private cloud service where customers can either bring their licenses or subscribe to SAP software as a service. Infrastructure and basic technical management are handled by SAP, shifting the operational burden away from the customer. Subscription models turn costs into recurring OPEX and include SAP support, but lock the customer into SAP’s environment. Compliance auditing still occurs, though SAP helps monitor usage.
• Managed Private Cloud (Third-Party MSP): The customer retains ownership of licenses (typically a BYOL model) but outsources hosting and technical management to a managed service provider. This offloads infrastructure duties while keeping licensing and compliance responsibilities largely with the customer. It provides more flexibility than SAP’s HEC, as the customer can switch providers or modify infrastructure, but requires coordination between the customer, the MSP, and SAP for support.
• Public Cloud IaaS (Hyperscalers): Deploying SAP on public cloud infrastructure (e.g., AWS, Azure, GCP) using a bring-your-own-license approach. The customer, or a partner, manages the SAP software on rented cloud servers. Infrastructure provision is outsourced to the cloud provider (no hardware ownership), but application management and license compliance remain the customer’s responsibility. Costs shift to a pay-as-you-go model for hardware, while SAP licensing costs (either perpetual or subscription-based) remain in effect. This model offers high flexibility and scalability but requires strong governance to avoid sprawl or compliance issues.
• Indirect Access and User Licensing: Regardless of deployment, indirect access (through third-party systems or external users interfacing with SAP) and proper user licensing remain critical. On-premises environments have historically faced “indirect use” audits for unlicensed connections. In cloud or HEC subscriptions, SAP still enforces digital access charges or user counts if contract limits are exceeded. Named-user licenses (for on-prem and BYOL scenarios) must be monitored carefully, while subscription models may simplify user metrics into subscription units but still charge for overages.
• HANA Database Licensing (Runtime vs. Full Use): The SAP HANA database can be licensed in two forms. Runtime licenses (cheaper, restricted) are only for use in SAP applications, whereas full-use licenses (costlier, measured by memory) allow broader use, including custom apps and analytics on HANA. On-prem and BYOL customers must choose wisely – many have incurred unplanned costs for using HANA beyond runtime restrictions. In SAP-managed subscriptions (HEC or SaaS), HANA is included (effectively as a runtime license for the SAP software); additional flexibility would require separate agreements, such as SAP BTP for custom extensions.

The following sections provide a detailed analysis of each deployment model, a comparative summary table of licensing and operational ownership, illustrative migration examples, and recommendations for CIOs on choosing the optimal deployment strategy while maintaining cost efficiency and compliance.

On-Premises (Customer-Managed SAP Deployment)

In a traditional on-premise model, the customer fully owns and operates the SAP environment.

This “classic” approach has distinct characteristics in licensing, cost structure, and risk profile:

• License Ownership & Model: The company purchases perpetual SAP software licenses upfront. These licenses are an asset owned by the customer, allowing indefinite use of the software. Typically, an initial license purchase (CapEx) is followed by annual maintenance fees, which are approximately 20–22% of the license price, paid to SAP for support and updates. The customer owns the rights to use the software version forever, even if maintenance is discontinued (although without support or upgrades in that case). This model demands a large upfront investment but provides long-term usage rights and control.
• Infrastructure & Responsibility: All infrastructure is managed by the customer (or a chosen data centre outsourcer under the customer’s direction). The company procures and maintains servers, storage, networking, and data center facilities. Internal IT (or hired consultants) handle installation, basic administration, applying patches, upgrades, backups, and disaster recovery. The customer’s team is responsible for meeting performance and uptime requirements. SAP’s involvement is limited to standard support for the software, including helpdesk assistance for issues and patches through the support portal, as per the maintenance contract. Essentially, the customer shoulders full responsibility end-to-end – from hardware to application management – in an on-prem deployment.
• Support & Maintenance: With perpetual licensing, customers typically maintain an active support agreement with SAP (Enterprise Support or a similar offering). This grants access to SAP’s helpdesk, patches, and new versions. However, day-to-day operational support, such as user administration and job monitoring, is handled by the customer’s IT staff. Some customers choose to drop SAP maintenance after the initial purchase to save costs, often using third-party support providers for break-fix help. Still, they forego updates and must manage any fixes themselves. All compliance with support prerequisites, such as staying on supported versions and applying security updates, falls to the customer’s team.
• Cost Implications: Upfront costs are high, not only for licenses but also for hardware, data centre space, and implementation services. These capital expenditures can be significant, but afterwards, the ongoing costs level out to maintenance fees, infrastructure operating costs (such as power, cooling, and staff), and periodic hardware refresh cycles. Over a long horizon (5+ years), on-prem can be cost-effective if the system is utilized fully and growth is predictable. There is no recurring subscription fee for SAP beyond support. If the business uses the system for a decade, the amortized license cost per year can be relatively low. The trade-off is that customers bear unpredictable costs for infrastructure expansions or upgrades and must invest in skilled personnel. The purchased hardware fixes capacity, so scaling for spikes requires upfront planning.
• Compliance & License Management: The burden of license compliance rests entirely on the customer. SAP will audit on-premise customers periodically to ensure usage aligns with entitlements. User Licensing: Each named user accessing SAP must have an appropriate license type (e.g., Professional, Limited, Employee Self-Service, etc.) purchased and assigned. The company must keep track of user counts and roles. If audits reveal more users or higher-level usage than licensed, the company must either purchase additional licenses or pay penalties. Indirect Access: Indirect use (e.g., when a non-SAP application, such as a web portal or shop floor system, connects to SAP and triggers transactions) has been a major risk area on-premises. Historically, SAP required a named-user license for any individual or system that indirectly created or viewed data in SAP. If hundreds of customers interact via a non-SAP web portal that feeds SAP, that could be interpreted as hundreds of “indirect users” requiring licenses. SAP now offers a Digital Access license (based on document counts instead of users) to address this. Still, it is optional – if the customer has not adopted it, traditional rules apply. The customer must analyze all interfaces and ensure that either sufficient named user licenses are available for indirect users or a digital access package is purchased to cover documents created via third-party integrations. HANA Database Licensing: For those running SAP on the HANA database on-prem, a separate HANA license is needed. If using SAP Business Suite or S/4HANA on-prem, one can opt for a runtime HANA license (usually priced at 15% of the SAP application value), which is cheaper but restricts the use of the database strictly to SAP applications. Suppose the business wishes to use HANA as a general-purpose database (e.g., building custom analytics or non-SAP applications on the same HANA instance). In that case, a full-use HANA license must be purchased (typically much more expensive, often measured by memory capacity). Choosing between runtime and full-use is a crucial decision – many customers have been caught in compliance issues by unintentionally using HANA beyond the scope allowed by their runtime license, resulting in significant unplanned costs.
• Risk & Flexibility: On-premises deployments offer maximum control and autonomy, but also carry the highest level of customer responsibility. The company can optimize and negotiate each aspect independently – for example, hosting on its hardware or moving to a different data center or cloud, choosing when to upgrade, and even negotiating support, including the option to switch to third-party support providers. This flexibility can be leveraged to control costs; for instance, if SAP raises maintenance fees, the customer could consider alternatives. However, with control comes operational risk – the organization must keep systems running, secure, and compliant with regulations. There is also a financial risk if the initial capacity or licenses are over-provisioned (shelfware licenses that sit unused are sunk costs) or under-provisioned (leading to urgent purchases later at possibly higher prices). Audit risk is significant if license management processes are weak – an on-premises customer can be found to be out of compliance with user counts or indirect usage and be hit with a hefty true-up bill. In summary, on-prem provides independence and potentially lower TCO in a steady state, but demands strong internal governance to avoid compliance and cost pitfalls.

SAP HANA Enterprise Cloud (HEC – SAP-Managed Private Cloud)

SAP HANA Enterprise Cloud is a cloud service where SAP itself hosts and manages your SAP applications in a private cloud environment.

It is essentially outsourcing your SAP system to SAP’s data centres (or SAP’s rented hyperscaler space) with a high level of SAP involvement in operations.

This model alters licensing and responsibility in the following ways:

• Licensing Options (Owned vs. Subscription): HEC offers two primary models for licensing the SAP software: Bring Your License (BYOL) or Subscription-based licensing. In the BYOL scenario, the customer uses the perpetual licenses they already own (or purchases new ones separately) and simply ports them into the HEC environment. The customer continues to pay SAP maintenance on those licenses as usual. In the Subscription scenario, the customer does not own the licenses outright; instead, they pay a recurring subscription fee to SAP, which includes the right to use the software. This subscription is often comprehensive – it bundles the SAP software license, the infrastructure, and base support services into one monthly or annual fee. Essentially, SAP becomes a one-stop shop, providing software as a service. Many existing customers moving to HEC initially leverage BYOL (to get value from their past investments). Still, new implementations or those seeking a simplified billing model may opt for the subscription model. It’s important to note that under the subscription approach, if the subscription lapses, the customer loses the right to use the SAP software (just like any SaaS offering), whereas under BYOL, the customer retains their license rights and could theoretically deploy elsewhere if they leave HEC.
• Infrastructure and SAP Responsibilities: In HEC, SAP, through its Enterprise Cloud Services organization, is responsible for provisioning and managing the infrastructure required for the SAP systems. This includes hardware (servers and storage), data center facilities, network, and the base software stack (operating system, database, and SAP application installation). SAP handles various basic administration tasks, including system installation, patching, upgrades (according to the agreed-upon schedule), backups, and monitoring, as part of the service. Essentially, a substantial portion of technical responsibility shifts from the customer to SAP’s managed services team. The division of tasks is usually outlined in a Roles and Responsibilities document – SAP handles standard activities, such as routine patches or ensuring high availability. In contrast, the customer may still be responsible for business-specific tasks, such as configuring SAP application settings, managing custom ABAP code, or handling user administration, unless these tasks are delegated. The customer’s IT team focuses more on functional oversight, integration, and any custom development rather than low-level infrastructure management.
• Support & Updates: Under HEC, SAP provides end-to-end support as part of the service. In a subscription model, SAP’s support (equivalent to Enterprise Support) is built into the subscription fees – customers don’t pay a separate maintenance fee per license, as support for the software is included. Suppose the customer is bringing their licenses (BYOL) to HEC. In that case, they typically must continue to pay maintenance on those licenses to SAP to remain supported and pay SAP for the hosting and management services. So, there are two components in BYOL: ongoing maintenance for licenses and the HEC service fees for operations. In both cases, the user will interface with SAP as a single point of contact for issues. Suppose an SAP application error occurs or the system is down. In that case, SAP is responsible for resolving it, since they handle the infrastructure, and you have either a support contract or a subscription with them. This can simplify support escalation— a “one throat to choke” scenario. Upgrades to new versions of SAP software can be coordinated through SAP in HEC. SAP will typically perform the technical upgrade tasks as part of the service, especially for subscription customers, where staying up to date may be part of the contractual obligation. The customer, however, still needs to validate the system, adjust custom code, and perform testing around those upgrades.
• Cost Structure: HEC turns many upfront costs into ongoing operational expenses. For subscription HEC customers, instead of buying hardware and software outright, they pay a regular fee that covers the SAP software usage, infrastructure, and standard management. This often simplifies budgeting, with predictable monthly costs, and accelerates time to value, eliminating the need to wait for hardware procurement or large capital approvals. The trade-off is potentially higher cost over a multi-year period – subscription fees cumulate and can exceed the cost of a one-time purchase plus maintenance after a certain number of years. SAP often prices HEC subscriptions at a premium, positioning it as a value-added service (with convenience and lower risk). For BYOL customers, the cost model involves HEC service fees (for hosting and management), which are recurring. Software license costs, however, are sunk or amortized from prior purchases, plus annual maintenance fees. BYOL to HEC might be slightly cheaper per year than a full subscription since you’re not paying “rent” on the software itself, only for infrastructure and management. However, you then carry the inefficiencies of owning licenses that might not be fully utilized if your user count drops. In either case, HEC is generally more expensive on a pure cost basis than self-managing on generic cloud infrastructure, because SAP charges for the convenience and guarantees dedicated resources and support. CIOs should weigh whether the risk reduction and staffing relief justify the premium.
• License Compliance & Audits: One might assume that moving to an SAP-managed cloud reduces license compliance worries, but it only partially does so. If BYOL, the customer is still responsible for staying in compliance with their license counts. SAP’s audit rights remain in force – SAP can audit user counts and usage just as it would in an on-premises scenario. The difference is that SAP itself is operating the system, so they have more direct visibility. In practice, SAP’s HEC contract may include provisions for regular usage reviews. It’s harder for a customer to “fly under the radar” with unlicensed usage when SAP runs the system because SAP can monitor the environment. If Subscription: the contract will specify what usage is allowed (for example, the number of users or metric terms in the subscription). The customer must ensure that they do not exceed the contracted quantities or violate usage terms (e.g., using a module to which they have not subscribed). SAP will periodically measure usage. If, for example, the user count exceeds the subscription limit or extra digital access documents are generated beyond a threshold, the customer will be required to purchase additional capacity or will be billed for overages. Indirect access is still a consideration – in subscription contracts, SAP often offers the digital access model. Still, if the customer’s usage of documents (such as sales orders and invoices) created via non-SAP systems exceeds what’s included in the subscription, it becomes a compliance issue. The good news is that since SAP manages the environment, it can proactively inform the customer of compliance issues (or even prevent some types of overuse). Still, the risk of unexpected charges remains if the contract terms aren’t carefully monitored. HEC customers should not become complacent about license governance – they need internal processes to review SAP usage reports that SAP provides and ensure they stay within their entitlements or, if necessary, formally expand them.
• HANA and Database Licensing: In HEC, the HANA database (or the database used by SAP software) is typically provided as part of the service. For S/4HANA systems in HEC, SAP typically includes a HANA runtime license in the package (if a subscription) or requires that the customer has the appropriate HANA license (if BYOL). The customer cannot arbitrarily use the HANA database for unrelated purposes in HEC – the use is contractually limited to supporting the SAP applications in scope. If a customer in HEC BYOL had a full-use HANA license, they could theoretically deploy custom schemas or apps on the HANA instance. Still, SAP’s cloud management might restrict such activities or require additional agreement. Generally, HEC is intended for running SAP workloads, not as an open-ended platform, so HANA is treated as an embedded component of the service. This effectively means most HEC customers operate with runtime-equivalent rights by default. Those needing additional data mart or non-SAP usage might be directed to purchase SAP’s Business Technology Platform (SAP BTP) services or separate cloud solutions rather than repurpose the HEC-provided database.
• Responsibility Split & Risk: HEC significantly shifts operational risk to SAP. SAP is responsible for system availability, performance (as defined in SLAs), infrastructure security, and routine maintenance. This can greatly reduce the strain on the customer’s IT department and mitigate risks around hardware failures or a lack of in-house expertise. However, new risks emerge: one is vendor lock-in. Once in HEC, the customer relies on SAP for everything – it’s not easy to migrate out to another environment because SAP’s landscape and processes might be unique. If SAP’s service is not satisfactory or if costs escalate, switching providers is a project nearly as complex as the initial migration. The customer also loses some flexibility – for example, they cannot choose a different database or apply an unconventional configuration without SAP’s agreement. Customizing the system beyond SAP’s standard allowances may incur additional fees or be disallowed to preserve service integrity. Another risk to consider is cost escalation: subscription fees can rise at renewal or if usage grows. Unlike owning infrastructure, where increased usage might mean a higher load on existing servers, in HEC, any scale-up typically means a higher tier of fees. SAP often requires multi-year commitments for better pricing, which can make it costly to change course later. On the compliance side, while SAP’s oversight may catch issues early, it also means the customer can’t hide any excess usage – any indirect usage, extra users, or use of unlicensed functionality will be known and charged for. In summary, HEC offers a trade-off: reduced operational burden and a single accountable provider at the cost of higher ongoing fees and tighter coupling to SAP. Organizations with limited IT capacity or high uptime requirements may value SAP’s direct management, whereas those seeking cost leadership or maximum flexibility might chafe under HEC’s constraints.

Managed Private Cloud (Third-Party Hosting)

Apart from SAP’s own HEC, many customers choose to run SAP in a private cloud hosted by third-party Managed Service Providers (MSPs) or outsourcing partners.

These providers (e.g., IBM, T-Systems, NTT, Accenture, or regional data center specialists) offer to host and manage SAP systems for customers on dedicated or virtual private infrastructure.

This model sits between on-prem and public cloud in terms of control and responsibility,y and has its licensing implications:

• Licensing Model: In a typical MSP-hosted private cloud, customers retain ownership of their SAP licenses (i.e., BYOL is the norm). The MSP provides the infrastructure and operational services, but does not own the SAP software – they are simply running the customer’s licensed copies. The customer must either use existing licenses or purchase new ones from SAP to meet any additional needs. Sometimes, an MSP may act as a reseller to facilitate license procurement, but ultimately, the license contract is between the customer and SAP. (In some cases, especially for smaller enterprises, an MSP might offer a “SAP-as-a-service” bundle where they include SAP licenses for a single fee – this is usually done via special agreements like SAP Partner Managed Cloud licenses. However, those arrangements are less common for large enterprises and more for mid-market solutions.) For the scope of this comparison, we assume the customer holds the licenses. The customer also maintains the SAP support agreement (maintenance) for those licenses unless they choose otherwise.
• Infrastructure & MSP Responsibilities: The MSP provides data center resources or cloud infrastructure (which can be their own data center or a virtual private environment on a public cloud, dedicated to the customer) and handles technical management. This typically includes server provisioning, storage management, network connectivity, OS administration, database administration, and SAP Basis tasks (such as installation, patching, system monitoring, and backups) as specified in the service contract. Essentially, much of the day-to-day running of SAP is outsourced to the provider’s team. The division of responsibilities is defined in a contract (similar to HEC’s roles document, but involving a third party) – the MSP is responsible for keeping the systems up and running and technically healthy. At the same time, the customer still oversees functional aspects. The customer’s IT and business teams would be responsible for tasks such as inputting business data, managing user access rights (although the MSP can create users if instructed), configuring business processes in SAP, and developing or modifying custom code. The MSP can support basic-level changes and may assist with transports or system copies as needed. Importantly, the customer needs to work closely with the MSP to schedule changes, upgrades, and maintenance windows, minimizing business disruption.
• Support & Coordination: Since the customer’s SAP licenses are covered under maintenance, SAP (the vendor) will still provide software support for any bugs or issues. However, the interaction is triadic: the customer or MSP can open SAP support tickets when something goes wrong with the software. Many MSPs offer to handle SAP support interactions on the customer’s behalf, troubleshooting and only escalating to SAP if it’s a product issue. The customer continues to pay SAP for annual maintenance support and also pays the MSP separately for their services. In effect, the MSP supplements but does not replace SAP’s support. The MSP likely also provides additional support services at the application level (such as a user helpdesk and performance tuning), depending on their offering. From the customer’s perspective, the internal staff can be smaller; the MSP’s team covers 24/7 monitoring and technical fixes. However, governance is key – the customer must manage the MSP through SLA reviews and ensure the MSP is meeting performance standards, since accountability is now split: the MSP is accountable for operations, and SAP is accountable for product quality.
• Cost Implications: Managed private cloud turns infrastructure and technical labour into a contractual expense. Typically, a monthly or annual fee is paid to the MSP for the environment and services. Upfront costs for hardware are either eliminated or greatly reduced – the MSP either owns the hardware or leases it, and this is factored into the service fee. There might be one-time migration or setup fees, but not the large capital outlay of on-prem. The license costs remain either as sunk costs (if reusing existing licenses) or as a separate purchase from SAP. So, compared to on-premises, the customer saves capital expenses on infrastructure and possibly reduces internal headcount costs, but they incur a vendor fee. Compared to HEC, an MSP may offer more competitive pricing or flexible pricing models, as it’s a competitive market. The customer can often negotiate rates based on the resources used (VM sizes, storage consumption, etc.) and adjust as needs grow or shrink. This model can be cost-effective if the MSP achieves economies of scale and passes some savings on. On the other hand, over the long term, you are continuously paying for assets that you could have purchased, so one must evaluate the total cost of ownership (TCO) of a multi-year MSP deal versus buying hardware. Many MSP contracts allow for the adjustment of capacity (scaling up or down), which provides cost flexibility that pure on-premises solutions lack. This can prevent over-provisioning costs (you can request more capacity only when needed). However, reducing capacity might not linearly reduce cost if contractual commitments or minimums are in place, so negotiate the ability to optimize resources.
• Compliance & License Management: The presence of an MSP does not absolve the customer from SAP license compliance – it remains the customer’s responsibility to ensure proper licensing. The MSP generally will not track how many users are using the system or whether a certain interface triggers indirect usage – that is outside their scope unless explicitly contracted as a license management service. The customer needs to maintain the same diligence as on-premises: tracking named users, ensuring the license types assigned in SAP align with the purchased ones, and monitoring indirect access. The customer should inform the MSP of any restrictions (for example, “do not create any dialogue users of type Professional beyond X number”). At audit time, SAP will still approach the customer (licensee) to run measurement programs, such as USMM and LAW reports, on the systems. The MSP can help run these reports, but the findings are tied back to the customer’s entitlements. There could be an advantage in compliance from using an MSP: they may have tools or best practices to help optimize license usage (some MSPs offer software asset management for SAP as a value-added service). But ultimately, if an audit reveals shortfalls, the customer must purchase additional licenses from SAP – the MSP has no liability in this case. For indirect access, unless the customer has transitioned to a digital access document model, the risk is the same as on-premises – any third-party applications interfacing with SAP must be properly licensed. The MSP might assist in implementing technical controls or monitoring logs for indirect usage. Still, it’s up to the customer to ensure they have sufficient licensing (or adopt SAP’s digital access licenses to cover it).
• HANA and Databases: In a private cloud with Bring Your Own License (BYOL), database licensing is handled similarly to on-premises deployments. If the customer is running S/4HANA or Suite on HANA, they must have the appropriate HANA license (runtime or full-use) from SAP. The MSP’s role is to manage the database technology; they don’t provide the license for the database. The customer should decide whether the runtime edition is sufficient (cheaper, only for SAP usage) or if a full-use license is needed to allow more extensive use of HANA. One nuance: some MSPs might bundle a database license if they have an arrangement (for example, some cloud providers can bundle Microsoft SQL Server licenses in the hosting fee under SPLA agreements). However, SAP HANA is not commonly available in this way; it typically remains a SAP-licensed product. Most often, customers must bring their license (BYOL) for SAP software and the underlying SAP HANA database or any other database, such as Oracle or DB2. If MSPs provide Oracle under their agreements, it may be used. However, for SAP products like HANA, the license is typically obtained directly from SAP.
• Risk & Flexibility: Using a third-party private cloud introduces vendor risk (reliability of the MSP) but also provides flexibility. The customer is not tied to SAP’s hosting, so there’s competition – if the MSP underperforms or overcharges, the customer can potentially move to another provider at the end of the contract or even bring systems back in-house or to a public cloud. The customer retains ownership of licenses and data, which is an important safety net. If the contract ends, they still retain the SAP software rights to deploy elsewhere (unlike a pure subscription, where rights are lost if payment stops). Operational risk is mitigated by the MSP’s expertise and service-level commitments; however, the customer should still maintain oversight. There is a shared responsibility model: the MSP handles infrastructure and technical uptime, while the customer must still ensure the system is used correctly and that business requirements, such as specific reports or configurations, are met – the MSP won’t know your business needs unless you communicate them. One potential risk is a lack of direct control – the customer may sometimes need urgent changes or access and have to go through the MSP’s processes, which could be slower than if the issue were resolved directly by an internal team. Proper governance and an aligned partnership are key to success in this case. From a cost perspective, there is a risk of long-term cost creep: if the scope of services isn’t tightly managed, things like additional projects or extra storage can incur fees. But there’s also an opportunity to optimize – you can bid out the service or re-negotiate regularly. In terms of compliance risk, as noted, it stays mostly the same as on-prem; the customer must be vigilant. Some CIOs appreciate that a good MSP will keep the technical environment clean and well-documented, which can make audits easier (e.g., ensuring no unauthorized use is occurring). However, this depends on the provider’s capabilities and any additional services contracted, such as license management advisory. In summary, a managed private cloud can strike a balance: you offload heavy lifting and convert infrastructure to service while still retaining ownership of your SAP assets. It offers more flexibility than SAP’s cloud because you’re not locked into SAP as the sole provider, but it requires managing an additional vendor relationship.

Public Cloud Infrastructure (Hyperscaler IaaS – Customer or Partner Managed)

This model involves running SAP systems on public cloud infrastructure-as-a-service (IaaS) platforms such as Amazon Web Services (AWS), Microsoft Azure, or Google Cloud Platform (GCP).

Instead of owning hardware or using a private hoster, the customer rents compute, storage, and network resources on demand from a hyperscaler. SAP software is then installed on these cloud servers, similar to on-prem, either by the customer’s team or with the help of a systems integrator.

Key implications for licensing, responsibilities, and risk in this scenario include:

• Licensing (BYOL is Standard): Public cloud IaaS is essentially an alternative to on-prem hardware – it does not inherently change the SAP licensing model. Customers must bring their own SAP software licenses to deploy on AWS, Azure, or GCP. The major cloud providers are not resellers of SAP ERP; they provide the computing platform. (One exception is certain SAP SaaS offerings delivered on the public cloud under SAP’s umbrella – e.g., RISE with SAP or SAP S/4HANA Cloud are deployed on hyperscalers, but those are SAP subscriptions. Here we are discussing the scenario where a customer directly uses IaaS to run their SAP instance.) Therefore, if a customer moves an existing SAP ECC or S/4HANA system to AWS, they continue to use their perpetual licenses and pay maintenance to SAP as before. If the project is a new implementation on the public cloud, the customer will need to purchase new SAP licenses (or subscribe via SAP directly) – but in most IaaS cases, companies opt to purchase perpetual licenses from SAP and deploy them on the cloud, or use existing licenses freed up from a retired on-prem system. SAP’s license agreement allows deployment “on any infrastructure” as long as usage is within bounds, so legally, there is no obstacle to using licensed SAP software on AWS or Azure. It’s essentially the same as if you moved your servers from your data centre to a rented data centre; from SAP’s point of view, nothing changes about the license requirement.
• Infrastructure & Management Responsibilities: The public cloud provider (AWS, Azure, or GCP) is responsible for the physical data center, hardware availability, and the base virtualization or cloud management layer. They ensure that you have on-demand access to computing resources, with built-in redundancy options. However, unlike a managed service or HEC, the cloud provider does not manage the SAP system – that responsibility remains with either the customer’s IT team or an implementation partner or MSP that the customer hires to manage SAP on the cloud. In essence, using IaaS shifts the location and ownership of hardware to a third party, but the day-to-day operation of SAP remains a customer concern. The customer must handle installing SAP software on cloud virtual machines, configuring operating systems, setting up HANA or other databases, and performing all basic tasks. Some tasks can be automated or simplified using cloud tools, such as pre-built machine images or leveraging infrastructure-as-code to quickly spin up systems. However, it’s still the customer’s responsibility to orchestrate those. There are SAP-specific reference architectures provided by cloud vendors and SAP, offering best practices such as using multiple Availability Zones for high availability and utilizing cloud storage for backups. Still, the execution is in the customer’s hands. Many companies hire specialized SAP cloud migration partners to assist with the initial move and, optionally, to provide ongoing managed services on top of AWS or Azure, which effectively turns this scenario into a variant of the Managed Private Cloud model. Still, the difference is that the infrastructure is a shared public cloud, not dedicated hardware. Suppose the customer’s staff manages it. In that case, this model is closest to the on-premises scenario in terms of operations, except that hardware provisioning is much faster (spinning up a new VM vs. buying a new server), and some infrastructure maintenance, such as replacing failed disks or upgrading the hypervisor, is handled by the cloud provider.
• Support and Integration with SAP: The support model in IaaS deployments mirrors that of on-premises deployments. The customer remains responsible for SAP software support via an active maintenance contract with SAP. If an issue arises with the SAP application, the customer (or their support partner) will contact SAP support. The cloud provider is not involved in SAP application issues – they will only ensure the underlying VM or cloud services are running properly. For example, if an AWS EC2 instance running SAP crashes due to a hardware fault, AWS would intervene to fix the hardware or migrate the instance. Still, if the SAP application crashes due to a code dump, the customer can troubleshoot the issue or escalate it to SAP. Public cloud vendors typically provide enterprise support for their platforms (which is often an additional cost) to help with issues such as network connectivity and VM performance, but they are not SAP specialists. Therefore, the customer might maintain two support channels: one with SAP for the software and one with the cloud provider for infrastructure. In practice, most issues can be handled by the customer’s basis team. Still, it’s essential to have cloud expertise available for tuning cloud resources, such as resizing instances and adjusting storage IOPS. One area to plan for is integration: connecting cloud-based SAP systems with other systems (which may be on-premises or also in the cloud) requires network and security configuration, such as VPNs or express routes. The cloud provider offers connectivity options, but the customer must design and architect them properly.
• Cost Model: Public cloud turns infrastructure spending into a pure pay-as-you-go OPEX model. Instead of buying servers, the customer rents computing by the hour or month. This provides agility – for example, systems can be scaled up during heavy workloads (such as end-of-quarter processing) and scaled down afterward, or even shut down non-production systems on weekends to save money. However, this variable cost model needs governance; it’s easy to overspend if systems are oversized or left running without optimization. Many companies initially lift and shift SAP to the cloud, expecting savings. However, if they don’t adjust architecture or usage patterns, cloud costs can rival or exceed previous data centre costs. Savings are usually found in rightsizing (using only the capacity needed, no more) and in avoiding overprovisioning for future growth (you scale up when needed). Another aspect is that while infrastructure becomes OPEX, the SAP license remains either an upfront cost (if already owned) or could itself be OPEX if the company chose a subscription license from SAP even on IaaS (it’s possible to have a subscription S/4HANA license but deploy it on your own chosen cloud – this might happen under the product called “S/4HANA Cloud, private edition” which is essentially RISE with SAP; however, in a purely self-managed scenario, typically one stick with perpetual licenses). The customer still pays SAP maintenance annually for support. One hidden cost area is data transfer and storage in the cloud. Large SAP databases require a lot of storage, which is charged per GB per month, and heavy integration traffic may incur bandwidth charges. These are costs that were perhaps less visible on-prem. Overall, the cloud model can shift SAP infrastructure from fixed costs to flexible costs, which is great for adaptability but requires careful cost management discipline to ensure budgets don’t spiral out of control. Tools and monitoring should be implemented to track cloud usage specifically for SAP environments.
• License Compliance: From SAP’s perspective, a system running on AWS is no different than one in the company’s own data centre – the same license rules and audit processes apply. The customer is fully accountable for the proper licensing of users, engines, and indirect access. SAP has been known to audit customers after a move to the cloud as part of routine checks or if there is a suspicion that usage might have changed during the transition. User Licensing: The customer must continue to track named users in each SAP system. One nuance when using the cloud is the ease of cloning systems – for instance, creating additional test instances or parallel environments is easy in AWS or Azure. Each of those instances, if active with user access, also needs to be licensed properly. Suppose you copy production data to a test system. In that case, technically, all those user accounts exist in the test system, too – SAP’s license rules often require that if a user is named in multiple systems, they are only counted once if it’s the same user. You have a proper license assigned, but careful reconciliation is needed when running many environment copies. Indirect access must also be monitored: moving to the cloud may encourage more digital integration, such as APIs and cloud-native apps connecting to SAP. Each of those interactions still needs to be licensed. The customer might decide at this point to adopt SAP’s digital access document licensing to mitigate indirect user counting. If not, the classic risk remains – SAP could audit and request licenses for, say, every external system user who creates an order. The cloud provider does not get involved in any of this; they neither know nor care about SAP license usage. Therefore, the customer’s SAM (Software Asset Management) function must seamlessly extend to cloud deployments.
• HANA on Public Cloud: Running SAP on a public cloud often means running HANA on virtual machines for S/4HANA or BW. SAP has certified large VM types on AWS, Azure, and GCP that can handle HANA’s in-memory requirements. The license for HANA must be obtained from SAP, unless the customer uses a different database, such as ASE or Oracle for Business Suite, which still requires a database license, either owned or rented. Most S/4HANA on-cloud deployments use the HANA runtime license included with S/4HANA. If they purchased S/4HANA in a perpetual license, it comes with runtime HANA usage rights. If the customer wants to use a full-featured HANA license, they would purchase it and deploy it. The cloud itself doesn’t change runtime vs full-use considerations, except perhaps making scaling easier. For instance, with a full-use license, the cost is often based on memory tier. If you want to allocate more memory to your HANA instance on the cloud, you not only pay the cloud provider for more RAM, but you might also have to upgrade your HANA license to a higher tier. Customers need to plan their capacity to avoid unintentionally exceeding what their license allows. SAP HANA full-use licenses can be expensive if you suddenly need to double the memory. On the cloud, it’s technically possible to spin up a large instance in minutes – one must ensure license keys from SAP are in place for any larger size before doing that in production. This again underscores that while the cloud gives technical flexibility, license constraints remain a gating factor.
• Flexibility & Risk: Public cloud IaaS offers maximum flexibility among all models. The customer can choose any cloud provider or even span multiple, move workloads around, and only pay for what they use. There’s no long-term lock-in to SAP for infrastructure, although there can be a form of lock-in to the cloud vendor if you heavily rely on their specific services. Many organizations adopt a multi-cloud or cloud-agnostic architecture for SAP to maintain that flexibility. Although in practice, moving a running SAP system from one hyperscaler to another is a significant project, at least you have the technical possibility and contract freedom to do so since you own the software. The risk exposure in this model is twofold: operational and financial. Operationally, if the customer’s team (or chosen partner) is not experienced with the cloud or SAP basics, they could misconfigure something – the safety nets of HEC or an MSP managing everything are not in place by default. Outages could occur if, for example, someone forgets to allocate enough storage or mismanages security groups. Mitigating this requires hiring or contracting the right expertise and following proven architectures. Cloud providers do offer reliability zones and robust infrastructure, so in many cases, the infrastructure risk (such as hardware failure) is lower than in a single on-premises data center if configured correctly. Financially, the risk is that costs scale up with usage in an unplanned way – for example, leaving a large test system running over a long holiday can result in a surprise bill. Strong governance and possibly cloud cost management tools are advised. Compliance risk remains as discussed – nothing inherently reduces audit risk here, except that customers often take the opportunity during migration to clean up users and licenses. One slight risk to be aware of: because scaling up is easy, there might be a temptation to deploy additional SAP modules or products (which are technically available to install but might not be licensed). For example, a team might spin up an SAP Solution Manager system in the cloud for convenience. While SolMan (for managing the SAP environment) is usually included in support agreements at no extra license cost, other components might not be. Informal deployments should be tracked to ensure your license agreements cover them. In summary, running SAP on the public cloud gives CIOs a way to modernize infrastructure and potentially save costs or increase agility. Still, it retains most of the complexities of SAP licensing and adds the need for cloud management discipline.

Comparative Summary: Licensing and Operational Ownership by Deployment Type

The following table summarizes key differences across on-premises, SAP HEC, third-party private cloud, and public cloud IaaS deployment models in terms of license ownership, cost model, responsibility splits, and risk factors:

(Table Legend: BYOL = Bring Your Own License; SLA = Service Level Agreement; HA = High Availability. Note: “Public Cloud IaaS” here refers to customer-managed deployments on hyperscalers, not SAP’s SaaS offerings like S/4HANA Cloud.)

Illustrative Examples of Deployment Transitions

To further clarify how these models differ in practice, consider the following scenarios that many SAP customers face:

• Example 1: Moving from On-Premises to SAP HEC:
  Company A has run SAP ECC on-premises for years, owning 1,000 user licenses and a suite of SAP modules. They face ageing hardware and limited IT staff, so they are considering SAP HANA Enterprise Cloud to host their planned S/4HANA system. In the migration, they have a choice: BYOL to HEC or Subscription in HEC. Initially, they opt for BYOL to leverage their existing licenses – SAP reassigns their licenses to run in HEC and continues to charge annual maintenance. SAP’s HEC team installs the system on SAP’s infrastructure, relieving Company A of managing servers and basic operations. The company notices improved system reliability and faster issue resolution, as SAP handles everything from hardware to application issues. However, costs are higher than before: in addition to maintenance fees, they pay SAP’s monthly HEC hosting charge. Two years in, they decide to convert to a full subscription to simplify billing and take advantage of SAP’s latest cloud contract – they trade in their perpetual licenses for credit toward the subscription. Now, SAP charges a single annual fee for everything. The licensing shifted from an owned asset to a rented model – when an audit found they had 50 more users than contracted, SAP adjusted the subscription (with an increased fee) rather than requiring a separate license purchase. Company A appreciates not worrying about infrastructure, but they realize they are now very dependent on SAP. When they wanted to implement a new third-party add-on, they needed SAP’s approval to install it in HEC, and any additional components meant extra subscription costs. This example highlights the trade-off: moving to HEC solved operational headaches and kept SAP accountable for running the system, but it required careful management of the contract scope. Indirect access didn’t disappear as a concern either – Company A eventually adopted SAP’s digital access license as part of its subscription to cover its busy B2B portal, ensuring those document interactions were prepaid. The move to HEC also meant relinquishing some flexibility: when they considered a different cloud analytics solution requiring direct database access, they found the HANA runtime in HEC couldn’t be used for that – they needed to spin up a separate instance on SAP BTP (with extra cost). In summary, Company A’s journey from on-prem to HEC brought predictable OPEX costs and SAP-managed support at the expense of higher long-term costs and tighter control by SAP over changes.
• Example 2: Migrating from On-Premises to Public Cloud (AWS) with BYOL:
  Company B runs its SAP landscape on ageing in-house servers. Instead of SAP HEC, they choose to migrate to Amazon Web Services (AWS) to gain flexibility and potentially save costs. They engage a cloud migration partner to help. All their existing SAP licenses (for ERP, SAP BW, and SAP CRM) are retained – they redeploy the software on AWS EC2 instances. Technically, the migration involves exporting the SAP databases, importing them to HANA on AWS, and building new Linux VMs to host SAP. Company B signs an Enterprise Agreement with AWS for cloud usage, but the contract is purely about infrastructure (it does not include SAP software). Post-migration, the infrastructure responsibility is split: AWS ensures the data centre and VM uptime, while Company B’s partner manages the SAP basis operations remotely. The cost pattern shifts to monthly AWS bills based on usage.In the first few months, costs spike because the migration partner over-provisions servers to match on-premises performance, plus a buffer. Company B then worked on rightsizing – they realized the production system was running at 30% CPU on-premises, so they scaled down the AWS VMs to a smaller size, immediately saving costs. They also schedule non-production SAP systems (development and test) to shut down at night and on weekends, reducing cloud hours by approximately 40% for those systems. These optimizations bring their AWS spending well below what they used to pay for data centre electricity, hardware maintenance, and amortization – the cloud move yields savings. On the licensing side, nothing changed in their contract with SAP, but the move did trigger an SAP audit the following year (possibly because SAP noticed they hadn’t purchased new licenses in a while, but had a major project underway). The audit went smoothly because Company B was prepared: they had cleaned up many old user accounts during the migration. The named user count had dropped, and they ensured each user had the correct license type. They were also careful with indirect access – they configured their middleware to use a single technical account for certain integrations. They licensed that account appropriately, preventing SAP from counting hundreds of end users behind it. In the end, the audit found no compliance gap, and SAP closed it without incurring any extra fees. Company B’s CIO took this as a validation of moving to the cloud on their terms: they kept full control of licensing and avoided being pushed into a new contract. However, they also learned the importance of cloud governance – at one point, a developer accidentally left a test system running at a large size, incurring a big AWS charge for that month. After that, they implemented cloud monitoring alerts to catch such issues. This example shows that a public cloud migration with Bring Your License (BYOL) can maintain continuity in SAP licensing and offer cost agility. Still, the customer is responsible for managing
  both the tech and the licenses diligently. Company B essentially treated AWS as just new “hardware” and retained independence from SAP in how they run their systems.

(These examples underscore that the impact on licensing and responsibilities can be significant when changing deployment models. In example 1, licensing was transformed from owned to subscription; in example 2, it remained owned, and thus the compliance processes carried over. Each approach has nuances in cost and risk that CIOs must anticipate.)

Recommendations for CIOs and IT Leaders

Selecting the right SAP deployment model is a strategic decision that strikes a balance between cost, control, and risk.

Based on the comparisons above, CIOs and IT leaders should consider the following recommendations to align their deployment strategy with effective cost management and compliance:

• Align Deployment Model with Organizational Strengths and Priorities: Evaluate your organization’s ability to manage infrastructure and SAP operations. If you have a strong internal IT team and a capital budget, on-premises or self-managed cloud (IaaS) may yield the lowest total cost of ownership (TCO) and highest control. If your company’s strategy is to outsource commodity infrastructure and focus IT talent on higher-level tasks, a managed model (HEC or third-party) might be a good fit, despite the higher costs. The key is to ensure you’re not paying a premium for services you can efficiently handle in-house, unless those services free up your team for more value-added innovation.
• Consider Long-Term TCO vs. Short-Term Budget Impact: Perpetual licensing with on-premises infrastructure can be expensive upfront but levels out over time, whereas subscriptions or managed services spread costs annually but may accumulate to more in the long run. Perform a 5- 10-year Total Cost of Ownership analysis for each scenario. Include all components: hardware (or cloud infrastructure fees), SAP software costs, support, labour, data centre overhead, etc. Often, the break-even point between subscription and ownership is around 4-5 years. If you plan to use the system for a long time, owning licenses and infrastructure might save money after that point. On the other hand, if you need to conserve cash or expect significant changes (such as mergers or divestitures), the flexibility of not having sunk costs might be worth the premium.
• Negotiate and Right-Size Contracts: Regardless of the model you choose, negotiation is crucial. For on-prem licenses, negotiate favourable discounting and shelfware protections (avoid buying users you don’t need). For SAP HEC or RISE contracts, scrutinize what is included – ensure the user counts, database size, and throughput assumptions match your actual needs to avoid overpaying. Insist on the ability to adjust downwards in case of business contraction (many cloud contracts allow scale-up easily but not scale-down – try to include some flexibility for reducing scope at renewal if needed). With MSPs, competitively bid the service and include clear SLAs and penalties to get the best value. Public cloud costs can be optimized by committing to specific usage, such as AWS Reserved Instances or Azure Savings Plans. Work with finance to take advantage of cloud cost optimization levers once your steady-state usage is known.
• Maintain Rigor in License Compliance Monitoring: Moving to a cloud or managed model does not eliminate the need for license management. Assign a team or use tools to continuously monitor user counts, user classifications (ensuring users have the correct license type for their role), package and engine usage, and interfaces. Implement internal quarterly license audits to catch any growth in usage. Especially watch out for indirect access – if you deploy new web portals, mobile apps, or cloud integrations, evaluate their impact on SAP licensing and consider SAP’s Digital Access document licensing if it simplifies your scenario. In a subscription environment, thoroughly understand how SAP measures your usage (it could be users, Full User Equivalents, document counts, or other metrics) and review the usage reports that SAP provides. It’s easier to address compliance proactively than to react to an audit or an unexpected bill for overage.
• Plan for HANA Database Needs Explicitly: When charting your deployment strategy, include an analysis of your SAP HANA licensing. Determine if the bundled or runtime HANA in the SAP applications will suffice or if you anticipate needing direct data access, separate analytic solutions, or heavy customization that might violate the runtime terms. If so, budget for a full-use HANA license or explore alternatives, such as keeping some data on a different database or using SAP’s BTP HANA service for custom applications. In the cloud or HEC, ensure any such needs are communicated – for instance, if you want to use a read replica of the HANA database for analytics, is that allowed and licensed? Making these decisions early will prevent costly surprises, such as being forced to buy a full-use license mid-project. Many have found out too late that their use of HANA (such as creating custom reporting tables in HANA) was not allowed under runtime and had to pay the price. Avoid that trap by erring on the side of licensing flexibility if your business intelligence or integration strategy demands it.
• Beware of Vendor Lock-In and Ensure Exit Options: If you choose a SAP-managed or bundled model (HEC or RISE), negotiate clear exit clauses to ensure you can leave without penalty. Understand what happens if you want to leave – Will SAP help migrate data out? Can you convert your subscription back to a perpetual license? (Usually not directly, but be aware of the implications.) For MSP contracts, include knowledge transfer and termination assistance in the contract, so you can transition smoothly to another provider or in-house if needed. In the public cloud, avoid overusing proprietary services for SAP that could make it difficult to move later (for example, using a cloud-specific database instead of SAP HANA may complicate future moves). Keeping some level of portability (through standard OS/DB and automation scripts that could run on any cloud) is wise if you want to hedge against price increases. The more “all-in” you go with one vendor, the more power that vendor has at renewal time – so try to maintain leverage, whether that’s owning licenses, having migration plans, or at least understanding the cost of switching.
• Leverage Independent Expertise and SAM Tools: SAP licensing and deployment choices are complex – consider engaging independent advisors (who are not selling you the cloud or software) to validate your strategy and contract terms. They can identify hidden costs or risky terms (for example, some HEC contracts may charge extra for certain administrative tasks, or some cloud contracts may not include key performance SLAs). Additionally, invest in Software Asset Management (SAM) tools that are SAP-aware. These tools can automate user license classification optimization and track indirect usage, providing early warnings if you’re nearing your license limits. The cost of such governance is far lower than the cost of a true-up audit or a mid-sized contract.
• Align Deployment with Compliance Strategy: If your primary concern is minimizing compliance risk and audit exposure, you might lean toward models where SAP’s incentives align with yours. For instance, SAP’s RISE (the modern incarnation of HEC-like services) bundles digital access and user licensing in a way that SAP is less likely to audit in the traditional sense, because you’re in a pay-for-what-you-use model under their watch. This can reduce the adversarial audit scenario, but it introduces the risk of continuous metered costs. Alternatively, staying on-prem or BYOL with strong internal compliance processes can also manage audit risk while keeping costs stable. There is no one-size-fits-all answer; it’s about what your organization can manage. Some CIOs decide, for example, that they will accept a higher subscription cost in exchange for SAP taking on more of the operational and compliance burden (“we’ll pay more so we don’t have to worry about it”). Others prefer to retain control and only pay for net new licenses when needed. Make a conscious choice based on your risk appetite.
• Monitor Vendor Roadmaps and Future Licensing Changes: SAP’s deployment and licensing models are evolving (e.g., the introduction of RISE with SAP, new cloud editions, and changes in audit focus). As a leader, stay informed about these trends. SAP may offer incentives to migrate to certain models, such as conversion programs that move perpetual licenses to cloud subscriptions – evaluate them carefully for financial viability. Sometimes, there are limited-time offers (for example, SAP has occasionally offered credit for unused on-premises licenses when you migrate to the cloud). Also, be aware of support timelines (SAP ECC’s 2027 support deadline, for instance, prompts customers to migrate to S/4HANA, which may influence a cloud move). Your deployment strategy should factor in these external timelines – perhaps you’ll stay on-prem for now, but plan a move to a cloud or RISE model closer to 2027 to coincide with an S/4 upgrade. Having a roadmap ensures you’re not caught off-guard by an end-of-life or a drastic maintenance fee hike with no plan in place.

In conclusion, choosing between on-premise, HEC, private cloud, or public cloud for SAP is a decision that transcends pure IT considerations – it impacts financial models, vendor relationships, and compliance exposure.

CIOs should approach it like a portfolio management exercise: weigh cost vs. risk for each option, consider a hybrid approach if necessary (some less critical systems on cheaper infrastructure, core systems on managed cloud, etc.), and always maintain clarity on who owns what (licenses, data, responsibilities) in each scenario.

By doing due diligence and following the above recommendations, you can select a deployment strategy that not only meets your technical needs but also optimizes license use and minimizes unpleasant surprises, ensuring your SAP landscape remains both cost-effective and compliant in the long run.