SAP Deployment models

• On-premise: you own and run the hardware and software; capital expense, full control.
• Private cloud: a dedicated, single-tenant SAP system hosted and managed in the cloud (e.g. RISE with SAP); operational expense, near on-premise flexibility.
• Public cloud: multi-tenant SaaS; subscription, standardised, SAP-managed, always current.
• Hybrid: a mix, for example core ERP on-premise with line-of-business clouds (SuccessFactors, Ariba) integrated.

RISE is SAP’s packaged offering that bundles S/4HANA Cloud (private or public), infrastructure, tools and services into one subscription to move customers to the cloud. It is less a technical model than a commercial and transformation package built around the cloud deployment.

Deployment is usually explained commercially. What matters day to day is how much of the system you are allowed to touch, and that varies sharply.

On-premise. Full access. You have a development system, you write custom code, you modify where you must, you decide when to upgrade. You also run the infrastructure, patch the operating system and own every outage.

Private cloud. Close to the same configuration and extension freedom, with the infrastructure and much of the operation handled by the provider. Upgrades are on a schedule you agree rather than one you choose freely.

Public cloud. Materially different work. Configuration is through guided setup rather than the full IMG, classic modifications are not possible, and extensions go on the platform through released APIs. Releases arrive on a fixed schedule whether or not you are ready. The job shifts from building what was asked to fitting the business to the standard, and that is a genuine change in what a consultant does.

The practical implication for anyone choosing a specialisation: a public cloud project and an on-premise project want different skills from the same module consultant. See Fiori deployment for a related choice at the front end.

Useful in an interview and on a first day, because job adverts are frequently vague.

1. Ask whether there is a development system with full IMG access. If configuration is done through guided setup and a scope item list instead, it is public cloud.
2. Ask who applies upgrades and how much notice there is. A fixed release calendar you cannot move means cloud; a project you plan means on-premise or private cloud.
3. Ask whether custom ABAP runs inside the system. Classic developments in the core mean on-premise or private cloud; extensions on the platform only mean public cloud.
4. Ask who holds the operating system credentials. If the answer is the provider, infrastructure is not your problem, which is either a relief or a constraint depending on the day.

Four questions, and they tell you more about the daily work than the product name does.

Decide based on customisation needs, regulatory and data-residency constraints, in-house operational capability, and cost model preference (capex vs opex). Most large enterprises today land on private cloud for the core with public-cloud line-of-business solutions around it.

One factor that is often decided too late: where the data has to live. Data residency and sector-specific regulation can rule out options entirely, and finding that out after a commercial decision is expensive. Another is integration surface: a landscape with many on-premise systems around the ERP has more work to do in a cloud model than one that is already mostly cloud.

One more, and it is the question that most often decides it in practice: what does the organisation want to be good at. Running infrastructure well is a capability, and an organisation that does not want it should not be choosing a model that requires it, whatever the spreadsheet says.

Beyond the commercial framing, the shape of the system landscape differs, and that shape is what a project actually works in.

On-premise and private cloud keep the classic three-system landscape: development, quality assurance and production, with changes moving between them as transports. That transport path is the control that makes change management possible, and it is the reason configuration is never made directly in production.

Public cloud works differently. There is typically a smaller number of tenants, and changes move through a mechanism the provider defines rather than through transports you control. Configuration is through guided setup, and the scope of what can be changed is deliberately narrower.

Release cadence follows from this. On-premise upgrades are projects you schedule, sometimes years apart. Public cloud releases arrive on a fixed calendar, with a preview window on a test tenant and a regression test each cycle. That converts upgrade work from an occasional project into routine operational work, which is a genuinely different way to staff a team.

Who holds which credentials decides a great deal about daily life. Where the provider owns the operating system and database, some diagnostics require raising a ticket rather than looking, and that changes how long an incident takes to resolve.

The point for anyone choosing where to work: these are not just commercial models, they are different jobs. Someone who enjoys deep configuration and custom development will find public cloud constraining; someone who prefers process design and fitting to standard will find it a relief.

Deployment choice is presented as capital against operating expenditure, and the real cost differences sit elsewhere.

People. On-premise needs infrastructure, database and Basis capability, whether employed or contracted. Cloud models move much of that to the provider, and the saving is real provided the organisation actually reduces the function rather than keeping it.

Custom development. Every extension is built once and maintained forever, through every upgrade. Public cloud constrains this deliberately, which caps a cost that on-premise landscapes frequently let run.

Upgrades. On-premise upgrades are projects with testing, business disruption and consultancy. Cloud converts that into continuous regression testing each cycle, which is a smaller recurring cost rather than a large occasional one.

Integration. Often underestimated in every model. A landscape with many surrounding systems carries integration cost regardless of where the ERP runs, and cloud can add to it where network boundaries change.

Exit. Rarely discussed at the start and worth asking about: how data is retrieved and in what form if the arrangement ends.

The honest summary is that no model is cheapest in general. On-premise suits organisations with capability and a need for control; public cloud suits those willing to adopt standard processes and avoid the maintenance burden entirely.

• Treating deployment as purely technical, it is also commercial and organisational.
• Underestimating data-residency rules in cloud decisions.
• Assuming hybrid is simple, integration between models needs real design.

• Choosing public cloud and then asking for on-premise behaviour. The restriction is the product working as designed, and fighting it produces a project that fails slowly.
• Assuming cloud means no operations. Somebody still tests each release, manages integrations and owns master data.
• Reading a job advert's "S/4HANA" as one thing. See SAP against Oracle and against Salesforce for the comparisons buyers actually make.

• Deciding deployment before understanding how much the business genuinely differs from standard. That difference is the constraint, and it is discovered in fit to standard workshops rather than in a commercial negotiation.

Knowing the models is the start, and configuring within the constraints of one of them for a real client is the part you do in the course.

The question worth asking of any role or project is not which product but which deployment, because that single answer tells you how much of the system you will be allowed to change and therefore what the work actually is.