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.
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.
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.
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.
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.
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.
Roll-out geography and M&A path: companies planning international expansion or frequent acquisitions benefit from cloud's faster provisioning of new entities.
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.
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.
Exit strategy: how realistic is it to leave a vendor in five years? Data-export rights, schema portability and partner ecosystem all factor in.
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 Mechanical Engineering 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.
Is cloud ERP fundamentally more secure than on-premises?
A blanket answer falls short, because security is split according to the shared responsibility model: the cloud provider is responsible for the physical infrastructure and platform, while the customer remains responsible for permissions, identity management and data classification. Large hyperscalers employ several hundred security specialists, operate data centres attested to standards such as ISO 27001, SOC 2 and the German BSI C5 catalogue, and often patch vulnerabilities very quickly — something a small internal IT department rarely matches. The most common cause of cloud security incidents, however, is not gaps on the provider's side but customer configuration errors such as excessive permissions or unsecured API endpoints, the avoidance of which, according to Gartner, lies predominantly with the customer. What matters is therefore less the deployment model than a consistent security architecture with zero-trust principles and a tested disaster recovery strategy.
Which industries should lean towards on-premises or private cloud?
Typically companies with deep OT integration such as machinery manufacturing, metalworking or the process industry, whose ERP is tightly interlinked with MES, SCADA or PLM systems, as well as regulated industries such as pharmaceuticals, medical technology or defence with strict data residency and auditability requirements. Organisations with very deep customisation or in-house developments that cannot be reproduced in standardised public cloud versions are also often better served by private cloud or on-premises. Service providers, e-commerce companies and skilled trades businesses with largely standardisable processes, by contrast, usually benefit from public cloud SaaS. In practice, the private cloud is frequently the pragmatic middle ground, because it combines customisation depth with outsourced operations and EU data residency.
When is on-premises more economical than cloud ERP?
Over very long investment cycles, classically licensed on-premises software can pay off, because the ongoing subscription costs of the cloud, summed over ten to fifteen years, can exceed the one-off capital costs. The prerequisite, however, is that a largely depreciated data centre is available and an experienced internal IT team sustainably carries security, high availability and patch management. In addition, on-premises incurs annual maintenance and software support fees of typically around 18 to 22 percent of the licence total, which belong in every TCO calculation. The comparison only becomes reliable through TCO modelling over five to seven years that fully accounts for licences, implementation, internal effort, hosting and release upgrades.
What does a switch from on-premises to cloud ERP cost?
The costs depend heavily on the state of customisation and the chosen migration path, and can reach a substantial share of the original implementation costs. A greenfield migration, i.e. a clean re-implementation in the cloud, causes higher initial effort than a brownfield approach, which largely carries over existing structures, but in return it clears out outdated customisations and focuses on the standard, which is often cheaper and more stable in the long run. Brownfield approaches are cheaper and less disruptive in the short term, but carry technical legacy into the new environment. A reliable figure can only be determined per project after taking stock of interfaces, workflows and special logic, which is why a proof of concept on two to three critical processes is advisable before the budget is approved.
What GDPR and CLOUD Act risks exist with US cloud providers?
Public cloud providers with a US parent company are subject to the US CLOUD Act, which under certain circumstances grants American authorities access to data even when it is stored in European data centres. The EU-US Data Privacy Framework, whose adequacy decision was issued in July 2023, does regulate the adequacy of commercial data transfers, but it does not remove the governmental access rights arising from the CLOUD Act and FISA 702, and following the Schrems II ruling of 2020, the legal situation remains in flux due to a pending challenge to the framework before the CJEU. For particularly sensitive data categories such as HR, health or trade secret data, EU sovereign cloud options or European providers are therefore recommended, along with technical measures such as customer-managed encryption keys, with which the provider itself cannot decrypt the data. A systematic data classification and a proper data processing agreement, including scrutiny of sub-processors, are the foundation for this.
How do we prevent vendor lock-in with cloud ERP?
The most important lever is an exit strategy anchored in the contract from the start, with clear clauses on data export, interface openness and transition support in the event of termination. Make sure you can export data in standardised formats such as CSV, JSON or XML, use standard APIs, and anchor customisation in separate layers or microservices rather than in the core system wherever possible. A minimum transition support period of twelve to eighteen months after termination provides realistic room for an orderly migration, and vendor-independent documentation of configurations, workflows and permissions is the basis for re-implementation in an alternative system. An annual test export ensures that the exported data is actually complete and interpretable when it counts, because an exit plan that has never been tested is of no help in a crisis.