Deployment Models: On-Prem, Hosted, Private Cloud, Public SaaS

The deployment model decides what you are allowed to change, which is the single most important constraint on your job.

The spectrum 

On-premise ──▶ Hosted/IaaS ──▶ Private cloud ──▶ Public SaaS multi-tenant
   ▲                                                          ▲
 Max control                                            Max upgrade speed
 Max responsibility                                     Min control
 Any customisation                                      Extensions only

1. On-premise

The customer owns the servers, the licence is perpetual, the DBA is down the hall.

  • You can: modify anything, including core source code (in SAP: modifications with access keys; in others: full source access).
  • You must: manage the DB, OS patching, backups, DR, capacity, and every upgrade yourself.
  • Upgrade cadence: every 3–7 years, as a project, often painful.
  • Still common in: defence, government, pharma, companies with data-residency constraints, and anyone with 20 years of accumulated custom code.

2. Hosted / lift-and-shift IaaS

Same software, running on AWS/Azure/GCP instead of a rack. Nothing about the application changes.

  • Solves hardware refresh and DR; solves nothing about upgrades or customisation debt.
  • Often a stepping stone before a true cloud migration.
  • SAP calls this “SAP on Azure/AWS”; you’ll also hear “RISE with SAP” for the managed private-cloud variant.

3. Private cloud / single-tenant SaaS

Vendor-managed, but your own instance of the application and database.

  • Examples: SAP S/4HANA Cloud Private Edition (RISE), Oracle EBS on OCI, Dynamics 365 F&O sandbox+prod tiers.
  • You can: still customise fairly deeply, keep your own release schedule within limits.
  • You must: accept vendor-imposed maintenance windows and minimum version floors.
  • The pragmatic landing spot for large enterprises that cannot fit into a public SaaS mould.

4. Public multi-tenant SaaS

One codebase, one (logically partitioned) database, thousands of customers, everyone on the same version.

  • Examples: NetSuite, Workday, Business Central SaaS, S/4HANA Cloud Public Edition, Acumatica SaaS.
  • You can: configure, and extend only through the vendor’s sanctioned extensibility model.
  • You cannot: change core code, add arbitrary DB indexes, run unbounded queries, or block an upgrade.
  • Upgrade cadence: forced, 2–4 times a year, whether you’re ready or not.

The extensibility consequence table

Model Change core code Add DB tables Custom fields Custom UI Background jobs Upgrade control
On-prem ✅ ✅ ✅ ✅ ✅ Full
Hosted IaaS ✅ ✅ ✅ ✅ ✅ Full
Private cloud ⚠️ discouraged ✅ ✅ ✅ ✅ Windowed
Public SaaS ❌ ⚠️ via platform ✅ ✅ sanctioned ⚠️ quota’d None

The “clean core” doctrine

Every vendor now pushes the same message, in their own words:

Do not modify the core. Extend beside it.

Practically this means:

  1. Configure first — 70% of requirements are a config table entry.
  2. In-app extension second — custom fields, sanctioned business events, low-code rules.
  3. Side-by-side extension last — your logic runs on a separate platform (SAP BTP, Azure Power Platform, Oracle OIC, NetSuite SuiteCloud) and talks to the ERP via APIs.
  4. Core modification never — and if never is impossible, document it as debt with an owner and an exit plan.

Why: the moment you modify core, you own a merge conflict at every upgrade, forever. Clean-core customers upgrade in weeks; heavily-modified customers upgrade in years, or never, and end up on unsupported versions.

Data residency and sovereignty

Increasingly decisive:

  • EU GDPR, India’s DPDP Act, China’s PIPL/CSL, Russia’s data localisation, Saudi/UAE cloud rules, Bangladesh Bank circulars for financial data.
  • Many public SaaS ERPs simply are not available in a given jurisdiction’s region → forces private cloud or on-prem.
  • Payroll and HR data attract the strictest rules; this is why payroll is so often a local system integrated to a global ERP.

Sizing and environments

Regardless of model you will normally have this landscape:

Environment Purpose Data
DEV Development, unit config Small synthetic or masked
QA / TEST Functional and integration test Masked copy of prod
UAT Business sign-off Recent masked copy
TRAINING End-user training Curated, stable dataset
PRE-PROD / STAGING Dress rehearsal, performance, cutover practice Full masked copy
PROD The real thing Real

See Environments and Release Management.

Cost model differences

  On-prem SaaS
Licence Perpetual + 18–22%/yr maintenance Per-user or per-tier subscription
Infra CapEx, yours Included
Upgrade Project cost every N years Included, but forced
Implementation 1–3× licence cost Often 1–2× annual subscription
Accounting CapEx, depreciated OpEx

That last row is not trivia — CFOs pick deployment models partly for the balance-sheet treatment.

What to ask on day one of a project

  1. Which model are we on, and can that change?
  2. What is the upgrade cadence and who controls it?
  3. What is the sanctioned extensibility path, and what’s already been violated?
  4. Where does data physically live, and what regulation applies?
  5. How many environments do we get, and how does code move between them?

Next