SAP S/4HANA Cloud Public Edition is operated as software as a service. SAP manages the technical platform and delivers scheduled product changes. The customer consumes the service but remains accountable for business processes, data, access, integrations, testing, adoption, and support.
The operating model therefore replaces much of infrastructure ownership with continuous product governance. It does not replace the customer's IT and business responsibilities.
| Area | SAP responsibility | Customer responsibility |
|---|---|---|
| Infrastructure and platform | Operate networks, platform, database, backups, and technical service | Govern business continuity needs and contractual service requirements |
| Security | Infrastructure controls, technical patching, secure product capabilities | Identity provider, users, roles, segregation of duties, data protection, integration security |
| Product lifecycle | Schedule and execute software upgrades and maintenance | Assess changes, test end-to-end processes, remediate, communicate, and adopt |
| Business solution | Deliver standard scope and supported configuration mechanisms | Select scope, configure processes, govern data and controls |
| Extensions and integrations | Publish released interfaces and extension mechanisms | Design, secure, monitor, test, and maintain customer-specific use |
| Support | Operate SAP support within contracted terms | Run user support, triage, partner coordination, and business ownership |
The contract and current SAP service descriptions remain authoritative for the exact division.
Current SAP guidance describes two major upgrades each year, in February and August. SAP notifies customers and upgrades the test system before development and production, creating a validation window. Dates and detailed policies are time-sensitive, so planning must use the current SAP Upgrade & Maintenance Schedule.
Customers cannot remain indefinitely on an old SaaS release. Their control lies in readiness:
A scheduled SAP upgrade is not the same as automatic business adoption. New capabilities deliver value only when process owners understand and implement them.
SAP tests the product; the customer validates its own end-to-end operation. Critical scenarios may cross SAP applications, non-SAP services, extensions, identity platforms, banks, tax services, warehouses, and output channels. Only the customer and its partners know which combinations are business-critical.
Maintain reusable test packs tied to the process and scope register. Automate stable, high-value scenarios where practical, but retain business validation for controls, usability, and exceptions.
SAP manages infrastructure-level areas such as network security, platform operation, backups, and technical security patching. Customers remain responsible for business decisions such as user lifecycle, authorizations, segregation of duties, connected-system security, retention, and monitoring.
Security governance should include named owners, periodic access review, integration inventories, incident procedures, data-protection controls, and release impact assessment.
A sustainable model normally includes:
These responsibilities can be distributed across internal teams and partners, but accountability should remain explicit. Service metrics should measure business process outcomes, incident resolution, release readiness, adoption, and technical health.
Traditional ERP programs often concentrate change into large projects. Public Edition introduces a predictable stream of smaller product changes. The organization must therefore move from "implement and stabilize" to "operate, improve, and adopt continuously."
That is the core SaaS tradeoff: less customer-managed technical infrastructure in exchange for stronger standardization, disciplined release governance, and the ability to absorb change over time.