Cloud ERP vs On-Premisess — A Decision Matrix

The choice between cloud ERP and on-premises ERP is no longer a simple question of preference — it shapes data sovereignty, IT operating model, customisation latitude and five-year cost structure all at once. Almost every major vendor now pushes a cloud-first roadmap (SAP RISE, Microsoft Dynamics 365, Sage X3, Oracle NetSuite, Infor CloudSuite), yet the German Mid-Market still has solid reasons to evaluate three deployment models rather than two: public-cloud SaaS, private cloud (single-tenant hosted) and on-premises.

This decision matrix maps the ten criteria that actually drive the choice for mid-market companies in the DACH region. It is deliberately not a vendor scorecard — the same product can be a sensible cloud or an unwise cloud depending on data sensitivity, integration density, customisation depth and the in-house IT capability of the buyer. The honest answer for most German mid-market firms with 100–500 employees is “it depends on six or seven variables”, and this guide walks through each of them.

The three deployment models explained

Before any matrix becomes useful, the three deployment models need clean definitions — vendor marketing routinely blurs the lines.

Public-cloud SaaS (multi-tenant)

A single shared software stack serves many customers on a common code line; the vendor owns operations, patching and the release calendar. Examples: SAP S/4HANA Cloud Public Edition, Microsoft Dynamics 365 Business Central Cloud, Oracle NetSuite, Sage Intacct, weclapp. Customers receive features on the vendor's schedule and cannot defer upgrades. Customisation is constrained to the extension model the vendor offers (AppSource, SuiteScript, side-by-side extensions).

Private cloud (single-tenant hosted)

The same software runs on infrastructure dedicated to one customer, operated either by the vendor, a hosting partner or a managed-services firm. Examples: SAP RISE Private Edition, Dynamics 365 hosted by a partner, proAlpha Cloud, abas Cloud. Upgrade timing remains negotiable, customisation depth is higher and data residency can be tightly controlled. Cost sits between SaaS and on-premises.

On-premises

The customer owns the infrastructure, the licences and the operational responsibility. The vendor sells software and support, not service levels. Customisation is unlimited, upgrade cadence is fully under buyer control, and data never leaves the customer's perimeter. The trade-off is the in-house IT competence required to run a modern ERP stack including database, application server, integration layer and disaster recovery.

Hybrid models combine elements — a typical Mid-Market pattern is a private-cloud ERP core with public-cloud satellites for CRM, expenses or HR. These are addressed separately later in this guide.

The ten decision criteria

A useful decision matrix scores each deployment option against the criteria that move the needle for mid-market buyers. The ten criteria below come up in almost every selection we observe in the DACH market.

1. Data sensitivity and regulatory posture: Schrems II concerns, BSI C5 expectations, sector-specific obligations (BaFin for finance, MaRisk, KRITIS) drive how comfortable a buyer can be with shared infrastructure outside Germany.
2. Customisation depth required: if the business model genuinely depends on non-standard processes, the constraint of a multi-tenant code line becomes real. Most Mid-Market companies overestimate this and end up with 80 % standard anyway.
3. Integration density: how many real-time interfaces exist to MES, CAD/PLM, e-commerce, EDI and warehouse-management systems? Heavy on-premises integration estate makes a pure-cloud move more painful than it looks on a slide.
4. In-house IT capability: a strong infrastructure team with database, network and security depth makes on-premises viable; a thin IT department with one generalist makes cloud almost mandatory.
5. Capex vs opex preference: private equity owners and growth-oriented CFOs often prefer the predictable subscription model; family-owned businesses with balance-sheet strength sometimes prefer the capex treatment of perpetual licences.
6. Roll-out geography and M&A path: companies planning international expansion or frequent acquisitions benefit from cloud's faster provisioning of new entities.
7. Total cost of ownership over 5–7 years: the cross-over point where cloud becomes more expensive than on-premises is typically between year five and year seven for stable user counts — see our ERP TCO calculator.
8. Upgrade discipline: mandatory cloud upgrades enforce currency but disrupt the calendar; on-premises tolerates technical debt at the cost of eventual painful catch-up migrations.
9. Exit strategy: how realistic is it to leave a vendor in five years? Data-export rights, schema portability and partner ecosystem all factor in.
10. Cultural fit and Betriebsrat (works council) concerns: German labour councils have a formal say in any system that touches HR data, and cloud rollouts that move employee data abroad need explicit alignment.

When public-cloud SaaS is the right choice

Public-cloud SaaS is the default recommendation for German mid-market companies whose situation matches a clear profile: standard processes, lean IT department, ambitious growth or international expansion, and finance leadership that values predictable opex. In our observation this covers roughly 40–55 % of the DACH Mid-Market population between 50 and 500 employees.

Typical good-fit profiles include:

• Service businesses (consultancies, agencies, software-as-a-service vendors) whose process estate is standard and whose integration needs are modest.
• Wholesale and distribution companies without complex production, where Oracle NetSuite or Dynamics 365 Business Central cover the core workflows out of the box.
• Multi-entity groups planning to consolidate financials across countries on a common code line.
• Companies emerging from a private-equity transaction where the new owner wants standardised reporting and a predictable IT cost line.

The constraints to accept: feature roadmap belongs to the vendor, customisation has to live in the extension framework, and data residency is whatever the vendor offers in its regional data centres. For SAP S/4HANA Cloud Public Edition that means Frankfurt; for Microsoft and Oracle the European footprint is broad and Germany-resident options exist; for smaller cloud-native vendors residency can be a deal-breaker.

One pattern to avoid: starting in public-cloud SaaS to save money up front, then trying to add deep customisation later because the standard does not quite fit. That is the most expensive way to discover that the deployment model was wrong.

When private cloud offers the best middle ground

Private cloud — single-tenant hosted — is the right answer for mid-market companies that need more control than SaaS allows but do not have the in-house IT depth (or appetite) to run infrastructure themselves. Typical situations:

• Heavily customised systems migrated from on-premises: a 15-year-old Microsoft Dynamics NAV or SAP ECC estate cannot realistically lift-and-shift into public-cloud SaaS without a multi-year process redesign. Private cloud preserves the customisation while moving the operational burden.
• Industry-specific ERPs with deep verticals: proAlpha for manufacturing, abas for engineer-to-order, oxaion for project-based businesses, CSB for food. These vendors typically offer a hosted private-cloud option that keeps the vertical depth.
• Regulated industries: pharma, medical devices, food production, defence suppliers where audit trails, validated environments and tightly controlled change windows matter more than monthly feature drops.
• Companies that want German data residency with named operators: a hosting partner in Frankfurt or Munich that can name the staff with access to the database is sometimes a hard requirement.

The financial profile sits between SaaS and on-premises — usually 30–50 % more expensive than public-cloud SaaS on a per-user basis, but 20–40 % cheaper than running the same workload on-premises with a competent internal team. The hidden benefit is upgrade flexibility: the customer can defer major versions for a quarter or two when the business calendar demands it, which is rarely possible in pure SaaS.

When on-premises still makes sense

On-premises ERP is not dead in the DACH Mid-Market — it is just no longer the default. There remain four reasonably narrow situations where it is the correct answer.

Deep OT (operational technology) integration. Companies in machine tooling, process industry, automotive supply and discrete manufacturing often run ERP tightly coupled to shop-floor MES, SCADA, PLC and quality systems. Latency sensitivity and on-site failover requirements make a local ERP instance the pragmatic choice. Examples include Maschinenbau companies running proAlpha or abas on-premises with sub-50 ms response time requirements to their MES.

Data-sovereignty requirements beyond standard GDPR. Defence contractors, classified-information handlers, and some public-sector adjacent suppliers face contractual obligations that make any cross-border data flow problematic. The German Federal Office for Information Security (BSI) categories C5 and higher can in some interpretations rule out hyperscaler infrastructure entirely.

Very deep, business-critical customisation. A small number of companies have built genuine competitive advantage on a customised ERP — not the imagined competitive advantage that most projects assume, but actual differentiation that the standard cannot replicate. For these, the freedom of on-premises customisation outweighs the operating cost.

Strong existing IT operations. If the company already runs a competent data centre or co-location with backup, monitoring and 24/7 on-call, the incremental cost of running ERP on the same stack is modest. The cloud TCO comparison flips for these organisations.

Outside these four cases, on-premises is usually inherited rather than chosen — a 10–20-year-old system that nobody has yet had the budget or the courage to migrate.

Hybrid and two-tier strategies

A common pattern in the DACH mid-market is a hybrid architecture rather than a pure deployment choice. The most frequent variants:

• Two-tier ERP: a heavy core ERP (often SAP, proAlpha, abas) at headquarters, with lighter cloud ERPs (Business Central, NetSuite, weclapp) at subsidiaries or recently acquired entities. Consolidation happens through financial integration and intercompany interfaces. This pattern protects the headquarters investment while letting subsidiaries move at their own pace.
• Core-plus-satellite: a private-cloud or on-premises ERP for finance, manufacturing and supply chain; SaaS satellites for CRM (Salesforce, HubSpot), HR (Personio, Workday), expense management (SAP Concur), travel and procurement.
• Edge-and-core: a cloud ERP core combined with on-premises edge components — typically a warehouse-management system or shop-floor data collection — that need local resilience and fast response times.

Hybrid architectures resolve real constraints but introduce their own complexity: master-data governance across systems, identity and access management, and clear ownership of which system is the source of truth for which entity (customer, supplier, item, employee). Many hybrid setups become unmanageable not because of the architecture itself but because no one is funded to operate the integration layer. Realistic hybrid setups budget 0.5–1.5 full-time staff equivalent for integration and master-data operations.

Data protection, GDPR and data residency

The legal landscape since the Schrems II ruling (2020) makes data transfers to third countries — particularly the United States — substantially harder to justify under GDPR. For ERP, which by definition processes customer, supplier and employee personal data, this matters more than it does for many other categories of software.

Hyperscaler vendors (Microsoft, AWS, Google) have responded with EU-resident data offerings, dedicated European regions and contractual commitments to limit data egress. The EU-US Data Privacy Framework (DPF), in force since 2023, provides a new transfer mechanism but is widely expected to face the same legal challenges as its predecessors. For German mid-market buyers the practical defaults are:

• For employee data: insist on EU residency, document the legal basis under GDPR Article 6, involve the Betriebsrat (works council) early because cloud rollouts touching HR data require formal alignment under the German Works Constitution Act (Betriebsverfassungsgesetz).
• For customer data: review the customer's own contractual obligations — some German B2B customers (especially in pharma, finance and public sector) have contractually mandated data-residency requirements that flow down to suppliers.
• For supplier data: generally lower sensitivity but the same residency expectations apply when the supplier database includes individual contractor personal data.

The German Federal Data Protection Act (Bundesdatenschutzgesetz, BDSG) layers additional requirements on top of GDPR, particularly around employee data processing. Cloud ERP vendors that have done their homework offer data-residency commitments and audit reports (typically SOC 2 Type II, ISO 27001, and BSI C5 attestations) that map cleanly to German compliance expectations. Buyers should request these reports before contract signature, not after.

Migration and exit strategy — do not forget

Two questions that buyers under-weight at selection time and bitterly regret at year four: how do we get in, and how do we get out?

Migration in: moving from an existing on-premises system into cloud ERP is a project in its own right, typically costing 60–90 % of an equivalent greenfield implementation. The lift-and-shift approach (taking the customisation with you) usually fails — either the cloud vendor will not host the bespoke code, or the cost of re-engineering it for the cloud extension model is prohibitive. Most successful migrations are essentially greenfield re-implementations with data migration, which means the project length and cost approach those of a new ERP project. See our ERP migration playbook for the structured approach.

Exit out: cloud-ERP exit strategies are often theoretical until they are not. The data-export commitments in standard cloud contracts vary widely — some vendors offer full database export in machine-readable form, others provide reports and CSV extracts that lack the relational structure needed to seed a new system. Buyers should request and review the actual export specification at contract time, not at exit time. Useful contractual provisions include: time-bounded transition assistance, schema documentation, and an exit-data format that preserves referential integrity.

For multi-tenant SaaS specifically, the operational dependency on the vendor's release calendar means there is no realistic stand-still option — if a vendor goes through M&A or pivots its roadmap, the customer adapts or leaves. Budgeting 5–10 % of annual subscription as a notional “exit reserve” is a reasonable hedge for critical workloads.

Performance, availability and scaling

Cloud ERPs typically commit to service-level agreements (SLAs) of 99.5–99.9 % monthly availability, with financial credits for breaches. On paper this beats most on-premises operations, which rarely measure formal availability at all. In practice the comparison is more nuanced:

• SLA scope: cloud SLAs usually cover the application's availability but not the customer's internet connection, identity provider, or third-party integrations. A 99.9 % application SLA combined with a 99 % internet connection delivers 98.9 % end-user availability.
• Performance variability: multi-tenant SaaS performance can vary based on noisy-neighbour effects, regional load and the vendor's capacity management. On-premises performance is more deterministic but sized by the customer rather than the vendor.
• Disaster recovery: cloud DR is usually built in (geo-replication, automated failover); on-premises DR is a separate project with its own budget and discipline. Many on-premises implementations have nominal DR that has never been tested.
• Scaling for peak: seasonal businesses (e-commerce, fashion retail, agricultural supply) benefit substantially from cloud elasticity. On-premises has to size for peak and pay for it year-round.

A pragmatic recommendation: write the performance and availability requirements into the RFP and have shortlisted vendors document how they meet them. Reference checks with existing customers in similar industries are more revealing than vendor SLAs themselves.

A practical decision framework

To bring the ten criteria together, a simple framework helps mid-market buyers reach a defensible recommendation. The decision flows through three filters, in order.

Filter 1: regulatory and data-sovereignty constraints. Are there mandatory requirements (BaFin, BSI C5, customer contractual obligations) that eliminate certain deployment options? If yes, the matrix is partially solved — the buyer chooses among the remaining options.

Filter 2: customisation depth. How much of the business genuinely needs non-standard process support? A frank fit-gap analysis against the standard of two or three candidate systems usually shows that 80–90 % of processes fit the standard. If real customisation needs are below 15 % of processes, public-cloud SaaS becomes viable; between 15 % and 30 %, private cloud is the right zone; above 30 %, on-premises starts to look reasonable again — or the customisation needs themselves should be challenged.

Filter 3: IT capability and finance preference. Among the remaining options, which one matches the in-house operations capability and the CFO's preference between capex and opex? This is rarely a strict elimination but it should make the choice obvious.

The decision matrix in summary:

• Public-cloud SaaS: standard processes, lean IT, opex preference, international roll-out, M&A integration. Typical fit: 40–55 % of DACH Mid-Market.
• Private cloud: moderate customisation, regulated industry, German data residency, want hosted operations but not multi-tenant constraints. Typical fit: 25–35 % of DACH Mid-Market.
• On-premises: deep OT integration, classified data, business-critical customisation, strong existing IT operations. Typical fit: 10–20 % of DACH Mid-Market and shrinking.

The matrix is descriptive, not prescriptive — every selection has context-specific factors that override the defaults. The point is to make the choice explicit rather than inherit a deployment model by accident.

Related Topics

• ERP TCO calculator
• ERP migration playbook
• ERP for 50 to 100 employees