Cloud-ERP vs. On-Premise: Die Entscheidungsmatrix

Die Frage Cloud oder On-Premise gehört zu den zentralen Weichenstellungen jedes ERP-Projekts. Sie bestimmt nicht nur den Investitionsverlauf, sondern auch die Update-Strategie, die Architektur, die Datenhaltung und den langfristigen Vendor-Lock-in. Die Antwort fällt selten eindeutig aus: In der Praxis dominieren heute drei Bereitstellungsmodelle – Public-Cloud-SaaS, Private-Cloud-Hosting und klassisches On-Premise. Hybridszenarien sind die Regel, nicht die Ausnahme. Wer pauschal Cloud oder pauschal On-Premise wählt, ohne die spezifischen Anforderungen seines Unternehmens, seiner Branche und seiner IT-Strategie zu berücksichtigen, riskiert eine Fehlinvestition mit langfristigen Konsequenzen.

Dieser Leitfaden stellt die Modelle systematisch gegenüber und liefert eine pragmatische Entscheidungsmatrix anhand von zehn Kriterien. Er richtet sich an IT-Verantwortliche, Geschäftsführer und Auswahlteams, die zwischen einem klassischen Mittelstand-ERP und einer modernen Cloud-nativen Lösung abwägen. Auch wer bereits eine Tendenz hat, profitiert von einer methodischen Gegenüberstellung – sie schützt vor blinden Flecken und liefert Argumente für die Kommunikation in Lenkungskreis und Geschäftsleitung. Der Leitfaden behandelt zudem typische Mischmodelle, regulatorische Rahmenbedingungen und Branchenpräferenzen, die in der Praxis oft den Ausschlag geben.

Die drei Bereitstellungsmodelle im Klartext

Bevor wir vergleichen, lohnt sich eine saubere Begriffsabgrenzung. Die Marketing-Sprache der Anbieter verwischt diese Grenzen oft.

Public-Cloud-SaaS

Beim SaaS-ERP betreibt der Hersteller die Software in einer mandantenfähigen Multi-Tenant-Umgebung in eigenen oder hyperscaler-basierten Rechenzentren. Updates erfolgen automatisch und für alle Kunden gleichzeitig. Beispiele: Microsoft Dynamics 365 Business Central, NetSuite, Odoo Online, SAP S/4HANA Cloud Public Edition.

Private-Cloud-Hosting

Hier läuft die ERP-Instanz dediziert für einen Kunden in der Cloud-Infrastruktur eines Hostingdienstleisters oder Hyperscalers. Die Software entspricht oft der On-Premise-Version, der Betrieb wird ausgelagert. Updates erfolgen kundenindividuell. Verzeichnis-Übersichten finden Sie unter ERP-Hosting-Dienstleister.

On-Premise

Klassischer Eigenbetrieb auf eigenen Servern im eigenen Rechenzentrum. Volle Kontrolle, volle Verantwortung – inklusive Backup, Disaster Recovery, Patchmanagement. Beispiele in dieser Aufstellung sind SAP Business One in der On-Premise-Variante oder Odoo Community.

Die zehn Kriterien der Entscheidungsmatrix

Nutzen Sie folgende zehn Kriterien als Bewertungsraster. Gewichten Sie nach Ihrer Unternehmenssituation – was für einen Maschinenbauer mit Werkstattfertigung Pflicht ist, kann für ein Dienstleistungsunternehmen irrelevant sein.

Wann Public-Cloud-SaaS die richtige Wahl ist

SaaS-ERP eignet sich besonders, wenn Sie schlanke Standardprozesse, hohe Update-Affinität und begrenzten Customizing-Bedarf haben. Typische Profile sind dienstleistungsorientierte Unternehmen, schnell wachsende Startups, Tochtergesellschaften im Two-Tier-Modell oder international verteilte Teams. Auch E-Commerce-Unternehmen profitieren stark von der Skalierbarkeit und den nativen API-Anbindungen an Shop-Systeme.

Vorteile sind die schnelle Inbetriebnahme, planbare Subskriptionskosten, automatische Updates, geringer interner IT-Aufwand und meist eine moderne Benutzeroberfläche. Schwächen liegen in der begrenzten Customizing-Tiefe, möglicher Datenresidenz-Themen außerhalb der EU sowie der Abhängigkeit von der Update-Roadmap des Anbieters. Ein erzwungenes Major-Update kann ungeplante Anpassungen in Schnittstellen oder Reports nach sich ziehen.

Wann Private Cloud das beste Mittelfeld bietet

Private-Cloud-Hosting ist in vielen Fällen der pragmatische Mittelweg. Sie behalten die Customizing-Möglichkeiten der On-Premise-Version, lagern aber den Betrieb an einen Dienstleister aus, der Hochverfügbarkeit, Backup und Patchmanagement garantiert. Besonders beliebt ist dieses Modell bei Branchenlösungen, wo Hersteller- oder Partnernähe wichtiger ist als die Standardisierung der Public-Cloud.

Typische Profile: Mittelständler mit gewachsenem Customizing, regulierte Branchen wie Pharma oder Lebensmittelindustrie mit hohen Compliance-Anforderungen, sowie Unternehmen, die Daten innerhalb der EU oder gar nur in Deutschland halten müssen. Die laufenden Kosten liegen zwischen Public-Cloud-SaaS und On-Premise.

Wann On-Premise weiterhin Sinn ergibt

Trotz aller Cloud-Trends bleiben gute Gründe für On-Premise. Erstens: maximale Kontrolle über Daten und Architektur, etwa bei Behörden, Verteidigungslieferanten oder bestimmten Forschungsorganisationen. Zweitens: Sehr tiefes Customizing oder Eigenentwicklungen, die sich in Public-Cloud-Versionen nicht abbilden lassen. Drittens: Branchen mit OT-Integration, etwa schwere Maschinenbauer oder Prozessindustrien, deren ERP eng mit lokalen MES-, SCADA- oder PLM-Systemen verzahnt ist. Viertens: Sehr lange Investitionszyklen, in denen die Subskriptionskosten auf zehn oder fünfzehn Jahre summiert die Kapitalkosten von On-Premise deutlich übersteigen.

Auch wirtschaftlich kann On-Premise vorteilhaft sein, wenn ein abgeschriebenes Rechenzentrum vorhanden ist und das interne IT-Team über tiefes Know-how verfügt. Auf lange Sicht – ab Jahr fünf bis sieben – ist klassisch lizenziertes Open-Source-ERP oder On-Premise oft günstiger als laufende Subskriptionen. Allerdings sollten Sie ehrlich kalkulieren, ob Ihre interne IT die Anforderungen an Sicherheit, Hochverfügbarkeit und Patchmanagement dauerhaft tragen kann. Eine professionelle 24/7-Betreuung erfordert mindestens drei bis fünf qualifizierte Mitarbeitende mit unterschiedlichen Spezialisierungen – das übersteigt in vielen Mittelstandsunternehmen die Möglichkeiten.

Hybridmodelle und Two-Tier-Strategien

In der Realität dominieren Mischformen. Konzerne setzen oft eine On-Premise- oder Private-Cloud-Lösung in der Muttergesellschaft ein und führen Tochtergesellschaften in einem Two-Tier-Modell auf SaaS-Basis. Das spart Lizenzen, beschleunigt Roll-outs und entlastet die zentrale IT.

Ein typisches Beispiel ist eine SAP-Konzernzentrale mit angeschlossenen Tochtergesellschaften auf Microsoft Dynamics 365 Business Central oder Odoo. Wer zwischen klassischen Optionen schwankt, findet im direkten Vergleich SAP Business One vs. Microsoft Dynamics 365 Business Central einen guten Einstieg.

Datenschutz, DSGVO und Datenresidenz

Die DSGVO ist im Cloud-Kontext besonders relevant. Achten Sie auf den konkreten Speicherort, den Auftragsverarbeitungsvertrag, Sub-Auftragsverarbeiter und das anwendbare Recht. Public-Cloud-Anbieter mit US-Mutterkonzern unterliegen unter Umständen US-Gesetzen wie dem CLOUD Act, was bei sensitiven Daten ein Compliance-Thema sein kann. Hyperscaler bieten inzwischen EU-Datenresidenz und teilweise sogenannte EU-Sovereign-Cloud-Optionen an.

In stark regulierten Bereichen wie Gesundheitswesen oder Finanzdienstleistungen sind die Anforderungen an Auditierbarkeit, Datenort und Backup-Strategie besonders streng. Hier ist Private-Cloud-Hosting in einem deutschen Rechenzentrum oft die robusteste Wahl.

Migration und Exit-Strategie nicht vergessen

Eine oft übersehene Dimension ist die Exit-Strategie. Wie kommen Sie aus dem Vertrag wieder heraus, falls der Anbieter die Roadmap ändert, Preise massiv anhebt oder übernommen wird? Achten Sie schon im Auswahlprozess auf vertragliche Datenexportklauseln, dokumentierte API-Zugänge und Lizenz-Portabilität. Integrationspartner können bei späteren Ablöseprojekten den Datenexport effizient orchestrieren.

Wer mehr zur konkreten Migrationsplanung lesen möchte, findet im Leitfaden ERP-Implementierungs-Checkliste die ersten 90 Tage strukturiert beschrieben. Eine gute Exit-Strategie umfasst nicht nur den Datenexport in standardisierten Formaten, sondern auch die Dokumentation der Schnittstellen, Berechtigungen, Workflows und Sonderlogiken. Nur so ist ein Wechsel auf ein anderes System realistisch innerhalb von 12 bis 18 Monaten möglich – ohne diese Vorbereitung wird der Wechsel zur jahrelangen Belastung.

Performance, Verfügbarkeit und Skalierung

Performance-Anforderungen unterscheiden sich zwischen den Modellen. In der Public Cloud profitieren Sie von der nahezu unbegrenzten Skalierbarkeit der Hyperscaler-Infrastruktur. Lastspitzen werden automatisch abgefangen, Performance-Probleme treten meist nur bei mangelhafter Konfiguration auf. In Private-Cloud-Umgebungen hängt die Performance von der Dimensionierung des Hostingvertrags ab – achten Sie auf vertraglich fixierte Antwortzeiten und Kapazitätsreserven. Bei On-Premise-Modellen liegt die Verantwortung vollständig bei der internen IT, was tiefes Know-how und proaktives Monitoring erfordert.

Hochverfügbarkeit ist ein eigenes Thema. Public-Cloud-Anbieter erreichen typischerweise 99,9 bis 99,95 Prozent Verfügbarkeit, was rund 4 bis 8 Stunden Ausfall pro Jahr bedeutet. Private-Cloud-Hosting-Verträge garantieren oft 99,5 bis 99,9 Prozent. On-Premise-Verfügbarkeit hängt stark von der eigenen Infrastruktur ab – ohne redundante Auslegung sind 99 Prozent realistisch, was 87 Stunden Ausfall pro Jahr entspricht. Definieren Sie geschäftskritische Prozesse mit ihren tatsächlichen Verfügbarkeitsanforderungen und gleichen Sie diese mit den Modellen ab.

Branchenspezifische Bereitstellungspräferenzen

Verschiedene Branchen tendieren zu unterschiedlichen Modellen. Die E-Commerce-Branche setzt fast vollständig auf Cloud-ERP, weil die enge Integration mit Shop-Systemen, Marktplätzen und Payment-Providern über APIs essentiell ist. Auch Dienstleistungsunternehmen wechseln zunehmend in die Cloud, weil Standardprozesse dominieren. Maschinenbauer und Metallverarbeiter setzen häufiger auf On-Premise oder Private Cloud, weil tiefe MES- und PLM-Integration sowie Variantenkonfiguratoren spezifische Anpassungen erfordern. Handwerksbetriebe profitieren stark von schlanken Cloud-Lösungen mit mobiler Zeiterfassung und Außendienstanbindung. Ein Überblick über segmentierte Anbieter findet sich unter Branchen-ERP.

KI, Composable und die Zukunft der Bereitstellung

Mit dem Vormarsch von KI-gestützten Funktionen und Composable-ERP-Architekturen verschiebt sich das Bild. KI-Funktionen wie automatische Belegerkennung, Forecasting oder Chatbots erfordern Cloud-Architekturen mit Zugang zu Hyperscaler-Modellen. Wer rein On-Premise bleibt, verzichtet absehbar auf zentrale Innovationen, sofern der Anbieter keine On-Premise-tauglichen KI-Module liefert. Composable-Ansätze – also der Aufbau einer ERP-Landschaft aus spezialisierten Microservices statt einer monolithischen Suite – funktionieren ebenfalls am besten in Cloud-Umgebungen.

Diese Entwicklung verschiebt den Markt nachhaltig in Richtung Cloud. Nahezu alle namhaften Anbieter investieren primär in Cloud-Releases, On-Premise-Versionen werden zunehmend als Auslaufmodelle behandelt. Wer heute eine On-Premise-Entscheidung trifft, sollte explizit mit dem Anbieter klären, wie lange die On-Premise-Version weiter gepflegt wird und wann ein Wechsel in die Cloud zwingend wird. Diese Klausel gehört in jeden Vertrag.

Entscheidungsleitfaden für die Praxis

Wie kommen Sie nun zu einer fundierten Entscheidung? Folgender Leitfaden hat sich bewährt. Erstens: Fragen Sie sich, ob Ihre Kernprozesse standardisierbar sind oder ob tiefe Branchenausprägungen erforderlich sind. Standardisierbar spricht für Public Cloud, hohe Spezialisierung für Private Cloud oder On-Premise. Zweitens: Bewerten Sie den Reifegrad Ihrer internen IT. Eine schlanke IT-Mannschaft profitiert von der Cloud, ein erfahrenes Team mit eigenem Rechenzentrum kann On-Premise wirtschaftlich betreiben. Drittens: Prüfen Sie regulatorische Anforderungen detailliert. Bestimmte Datenkategorien dürfen nicht außerhalb der EU verarbeitet werden, manche Branchen verlangen Datenresidenz in Deutschland.

Viertens: Modellieren Sie die TCO über fünf bis sieben Jahre nach unserem Leitfaden TCO-Rechner. Berücksichtigen Sie nicht nur Lizenzen, sondern auch Implementierung, interne Aufwände, Hosting und Releasewechsel. Fünftens: Bewerten Sie die strategische Flexibilität. Cloud-Modelle erlauben schnelle Skalierung und einfache Erweiterung um neue Funktionen, On-Premise bietet maximale Kontrolle bei langsamerem Innovationszyklus. Sechstens: Holen Sie eine zweite Meinung ein. Eine externe ERP-Auswahlbegleitung kennt typische Fallstricke und kann die Entscheidung absichern.

Zusammenfassend lässt sich festhalten: Es gibt keine universell richtige Antwort. Die Entscheidung hängt von Branche, Unternehmensgröße, IT-Reife, regulatorischen Anforderungen, Customizing-Bedarf und strategischer Ausrichtung ab. Wer methodisch vorgeht, schafft die Voraussetzung für eine tragfähige Lösung über zehn Jahre und mehr. Wer sich von Marketing-Versprechen leiten lässt, riskiert teure Fehlinvestitionen. Investieren Sie deshalb mehrere Wochen in die Bereitstellungsentscheidung – sie zahlt sich vielfach aus.

Hybrid-Architekturen für regulierte Branchen

Regulierte Branchen wie Pharma, Lebensmittelindustrie, Medizintechnik oder Verteidigungslieferanten arbeiten zunehmend mit Hybrid-Architekturen. Der Grundgedanke: Nicht-sensitive Workloads wie CRM-Funktionen, Reporting, mobile Außendienstanwendungen und E-Commerce-Anbindung laufen in der Public Cloud, während sensitive Kerndaten und produktionsnahe ERP-Module in einer Private Cloud oder On-Premise verbleiben. Das Modell verbindet die Innovationsgeschwindigkeit der Cloud mit der Datensouveränität klassischer Architektur.

Konkrete Architekturmuster: Eine Konzernzentrale mit hoch reguliertem Geschäft betreibt das Kern-ERP On-Premise oder in der Private Cloud, Auslandsgesellschaften laufen im Two-Tier-Modell auf Public-Cloud-SaaS. Daten werden über sichere ETL-Strecken oder Master-Data-Hubs konsolidiert. Ein zweites Muster: Das ERP-Kernsystem läuft On-Premise, Microservices für Forecasting, Lieferanten-Onboarding oder Belegerkennung sind in die Public Cloud ausgelagert. Anonymisierte Daten verlassen die On-Premise-Umgebung, KI-Funktionen werden in der Cloud genutzt, ohne sensitive Daten zu exponieren.

Hybrid-Architekturen erfordern jedoch deutlich mehr Architektur-Know-how als reine Cloud- oder On-Premise-Modelle. Identity-Management, API-Sicherheit, Datenschnittstellen und konsistentes Monitoring werden zu kritischen Disziplinen. Auch die laufenden Kosten liegen meist über reinen Public-Cloud-Modellen, weil zwei Infrastrukturen parallel betrieben werden. Eine externe Integrationsbegleitung lohnt sich gerade in dieser Konstellation, weil die Architekturentscheidungen weitreichende Folgen haben und schwer rückgängig zu machen sind.

Schrems-II, Datenresidenz und CLOUD Act in der Praxis

Das Schrems-II-Urteil des EuGH von 2020 hat den Datentransfer in die USA grundlegend verändert. In Verbindung mit dem US-CLOUD-Act, der amerikanischen Behörden Zugriff auf Daten bei US-Konzernen weltweit einräumt, ergibt sich für deutsche Unternehmen eine komplexe Rechtslage. Wer Public-Cloud-ERP von Anbietern mit US-Mutterkonzern nutzt, muss prüfen, welche Datenkategorien das Unternehmen verlassen, ob die EU-Standardvertragsklauseln greifen und welche zusätzlichen technischen und organisatorischen Maßnahmen erforderlich sind.

Konkrete Konsequenzen für die ERP-Auswahl: Für besonders sensitive Daten – Personaldaten, Gesundheitsdaten, Finanzdaten mit Konzernrelevanz, Daten mit Bezug zu Geschäftsgeheimnissen – sollten Sie EU-Sovereign-Cloud-Optionen oder europäische Anbieter prüfen. Hyperscaler wie Microsoft, Google und AWS bieten inzwischen explizite EU-Datenresidenz, teils mit Verschlüsselungsoptionen, bei denen der Anbieter selbst die Daten nicht entschlüsseln kann (Confidential Computing, Customer-Managed Encryption Keys). Diese Optionen erhöhen die Compliance-Sicherheit, sind aber meist mit Aufpreisen verbunden.

• EU-Standardvertragsklauseln: erforderlich, aber nicht ausreichend ohne weitere Maßnahmen
• Datenresidenz EU/Deutschland: in Verträgen und SLAs explizit fixieren
• Confidential Computing/CMEK: für besonders sensitive Datenkategorien
• Auftragsverarbeitungsvertrag: Sub-Auftragsverarbeiter und deren Standorte prüfen
• EU-Sovereign-Cloud: für regulierte Branchen oft die robusteste Wahl
• Audit-Rechte: vertraglich fixieren, regelmäßig wahrnehmen

Eine systematische Datenklassifikation ist Voraussetzung für jede fundierte Cloud-Entscheidung. Klassifizieren Sie Ihre Datenbestände in vier Kategorien: öffentlich, intern, vertraulich, streng vertraulich. Pro Kategorie definieren Sie zulässige Speicherorte, Zugriffsbeschränkungen und Verarbeitungsregeln. Diese Klassifikation gehört in jedes Lastenheft und ist Grundlage der späteren Konfiguration.

Cloud-Exit-Strategien sauber dokumentieren

Die Wahl eines Cloud-ERP-Anbieters ist eine strategische Mehrjahresbindung. Was passiert, wenn der Anbieter seine Roadmap ändert, die Preise massiv anhebt, übernommen wird oder Insolvenz anmeldet? Eine dokumentierte Cloud-Exit-Strategie ist deshalb keine Kür, sondern Pflicht. Sie sollte Bestandteil jedes Cloud-ERP-Vertrags sein und mindestens vier Bausteine enthalten: Datenexport, Funktionsdokumentation, Übergangsunterstützung und alternative Zielsysteme.

Im Bereich Datenexport vereinbaren Sie vertraglich, in welchen Formaten und in welchem Detailgrad Daten exportiert werden können. Ideal sind standardisierte Formate wie CSV, JSON, XML oder branchenübliche Standards. Vermeiden Sie proprietäre Exportformate, die ohne Anbieterhilfe nicht interpretierbar sind. Vereinbaren Sie zudem maximale Exportdauer, Verfügbarkeit historischer Daten und die Möglichkeit, mehrfach Exporte zu ziehen. Im Bereich Funktionsdokumentation halten Sie sämtliche Konfigurationen, Workflows, Berechtigungskonzepte und Customizing-Logiken in einer anbieterunabhängigen Form fest. Diese Dokumentation ist die Basis für die Re-Implementierung in einem alternativen System.

• Datenexport: Format, Frequenz, Vollständigkeit vertraglich fixieren
• Funktionsdokumentation: alle Konfigurationen anbieterunabhängig dokumentieren
• Übergangsunterstützung: Mindestlaufzeit von 12 Monaten nach Kündigung
• Alternative Zielsysteme: 2-3 mögliche Migrationsszenarien skizzieren
• Schnittstellen-Mapping: alle Drittsystem-Verbindungen dokumentieren
• Test-Exports: jährlich einen Test-Export durchführen

Im Bereich Übergangsunterstützung verhandeln Sie eine Mindestlaufzeit von 12 bis 18 Monaten nach Kündigung, in der das System weiter nutzbar bleibt und der Anbieter aktiv bei der Migration unterstützt. Eine spezialisierte Integrationsbegleitung kann den Exit später effizient orchestrieren – idealerweise mit einem Anbieter, der vom Zielsystem unabhängig ist. Schließlich: Führen Sie jährlich einen Test-Export durch und prüfen Sie, ob die exportierten Daten vollständig und interpretierbar sind. Ein Exit-Plan, der nie getestet wurde, hilft im Ernstfall nicht.

Sicherheitsvergleich Cloud vs. On-Premise

Der Sicherheitsvergleich zwischen Cloud und On-Premise ist nuancierter als oft dargestellt. Die pauschale Aussage "Cloud ist sicherer" oder "On-Premise gibt mir Kontrolle" greift zu kurz. Tatsächlich verteilen sich die Sicherheitsverantwortungen nach dem Modell der Shared Responsibility: In der Public Cloud verantwortet der Anbieter die physische Infrastruktur, das Hypervisor-Layer und Teile des Betriebssystems, während Kunden für Identity-Management, Berechtigungen, Anwendungssicherheit und Datenklassifikation zuständig bleiben. Bei On-Premise tragen Sie die volle Verantwortung – inklusive physischer Sicherheit, Patchmanagement, Disaster Recovery und 24/7-Monitoring.

Die praktische Sicherheit hängt deshalb vom Reifegrad der jeweiligen IT-Organisation ab. Hyperscaler-Cloud-Anbieter beschäftigen mehrere Hundert Sicherheitsspezialisten, betreiben zertifizierte Rechenzentren nach ISO 27001, SOC 2 und C5 und patchen Schwachstellen innerhalb von Stunden. Eine mittelständische IT-Abteilung mit drei Mitarbeitenden kann dieses Niveau kaum erreichen. Andererseits verlieren Cloud-Kunden oft die Kontrolle über Konfigurationsdetails – falsch konfigurierte Speicher, übermäßige Berechtigungen oder ungesicherte API-Endpoints sind die häufigsten Ursachen für Cloud-Sicherheitsvorfälle, nicht Schwachstellen beim Anbieter selbst.

Die robusteste Strategie ist nicht die Wahl eines Modells, sondern eine klare Sicherheitsarchitektur unabhängig vom Bereitstellungsmodell. Defense in Depth, Zero-Trust-Prinzipien, regelmäßige Penetrationstests, ein professionelles Identity-Management und eine getestete Disaster-Recovery-Strategie schützen besser als jede Modellwahl.

Verwandte Themen

• SaaS-ERP
• Cloud-native ERP
• Mittelstand-ERP
• SAP Business One
• Microsoft Dynamics 365 Business Central
• Odoo
• ERP-Hosting
• ERP für Pharma
• SAP B1 vs. Dynamics 365 BC

← Zurück zur Startseite