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.
Cloud vs. On-Premise — Entscheidungsmatrix mit konkreten Bewertungs-Kriterien · Quelle: erp-software.org Redaktion
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.
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.
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
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.
Sicherheitsaspekt
Public Cloud
Private Cloud
On-Premise
Physische Sicherheit
sehr hoch (Hyperscaler)
hoch
variabel
Patch-Geschwindigkeit
Stunden
Tage
Wochen-Monate
24/7-Monitoring
standardmäßig
im Vertrag
oft fehlend
Konfigurationsfehler
häufigster Risikofaktor
moderates Risiko
moderates Risiko
Insider-Bedrohung
Anbieter + Kunde
Anbieter + Kunde
nur Kunde
Datenresidenz-Kontrolle
eingeschränkt
hoch
maximal
Disaster Recovery
standardmäßig
im Vertrag
kundenspezifisch
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.
Ist Cloud-ERP grundsätzlich sicherer als On-Premise?
Eine pauschale Antwort greift zu kurz, weil Sicherheit nach dem Modell der geteilten Verantwortung (Shared Responsibility) aufgeteilt ist: Der Cloud-Anbieter verantwortet physische Infrastruktur und Plattform, der Kunde bleibt für Berechtigungen, Identity-Management und Datenklassifikation zuständig. Große Hyperscaler beschäftigen mehrere Hundert Sicherheitsspezialisten, betreiben nach Standards wie ISO 27001, SOC 2 und dem BSI-Katalog C5 testierte Rechenzentren und patchen Schwachstellen oft sehr schnell, was eine kleine interne IT-Abteilung selten erreicht. Die häufigste Ursache für Cloud-Sicherheitsvorfälle sind allerdings nicht Lücken beim Anbieter, sondern Konfigurationsfehler des Kunden wie übermäßige Berechtigungen oder ungesicherte API-Endpoints, deren Vermeidung laut Gartner überwiegend in der Verantwortung des Kunden liegt. Entscheidend ist deshalb weniger das Bereitstellungsmodell als eine konsequente Sicherheitsarchitektur mit Zero-Trust-Prinzipien und getesteter Disaster-Recovery-Strategie.
Welche Branche sollte eher On-Premise oder Private Cloud wählen?
Tendenziell Unternehmen mit tiefer OT-Integration wie Maschinenbau, Metallverarbeitung oder Prozessindustrie, deren ERP eng mit MES-, SCADA- oder PLM-Systemen verzahnt ist, sowie regulierte Branchen wie Pharma, Medizintechnik oder Verteidigung mit strengen Datenresidenz- und Auditierbarkeitsanforderungen. Auch Organisationen mit sehr tiefem Customizing oder Eigenentwicklungen, die sich in standardisierten Public-Cloud-Versionen nicht abbilden lassen, fahren mit Private Cloud oder On-Premise oft besser. Dienstleister, E-Commerce-Unternehmen und Handwerksbetriebe mit überwiegend standardisierbaren Prozessen profitieren dagegen meist von Public-Cloud-SaaS. In der Praxis ist die Private Cloud häufig der pragmatische Mittelweg, weil sie Customizing-Tiefe mit ausgelagertem Betrieb und EU-Datenhaltung kombiniert.
Wann ist On-Premise wirtschaftlich günstiger als Cloud-ERP?
Über sehr lange Investitionszyklen kann sich klassisch lizenziertes On-Premise rechnen, weil die laufenden Subskriptionskosten der Cloud auf zehn bis fünfzehn Jahre summiert die einmaligen Kapitalkosten übersteigen können. Voraussetzung ist allerdings, dass ein weitgehend abgeschriebenes Rechenzentrum vorhanden ist und ein erfahrenes internes IT-Team Sicherheit, Hochverfügbarkeit und Patchmanagement dauerhaft trägt. Hinzu kommen bei On-Premise jährliche Wartungs- und Softwarepflegegebühren von typischerweise rund 18 bis 22 Prozent der Lizenzsumme, die in jede TCO-Rechnung gehören. Belastbar wird der Vergleich nur über eine TCO-Modellierung über fünf bis sieben Jahre, die Lizenzen, Implementierung, interne Aufwände, Hosting und Releasewechsel vollständig berücksichtigt.
Was kostet ein Wechsel vom On-Premise zum Cloud-ERP?
Die Kosten hängen stark vom Customizing-Stand und vom gewählten Migrationspfad ab und können einen erheblichen Teil der ursprünglichen Implementierungskosten erreichen. Eine Greenfield-Migration, also die saubere Neuimplementierung in der Cloud, verursacht zwar höheren Initialaufwand als ein Brownfield-Ansatz, der bestehende Strukturen weitgehend übernimmt, entrümpelt dafür aber veraltete Anpassungen und fokussiert auf den Standard, was langfristig oft günstiger und stabiler ist. Brownfield-Ansätze sind kurzfristig kostengünstiger und weniger disruptiv, übernehmen aber technische Altlasten in die neue Umgebung. Eine belastbare Zahl lässt sich nur projektspezifisch nach einer Bestandsaufnahme von Schnittstellen, Workflows und Sonderlogiken ermitteln, weshalb ein Proof-of-Concept auf zwei bis drei kritischen Prozessen vor der Budgetfreigabe empfehlenswert ist.
Welche DSGVO- und CLOUD-Act-Risiken bestehen bei US-Cloud-Anbietern?
Public-Cloud-Anbieter mit US-Mutterkonzern unterliegen dem US-CLOUD-Act, der amerikanischen Behörden unter Umständen Zugriff auf Daten einräumt, selbst wenn diese in europäischen Rechenzentren liegen. Das EU-US Data Privacy Framework, dessen Angemessenheitsbeschluss im Juli 2023 erging, regelt zwar die Adäquanz kommerzieller Datentransfers, hebt die behördlichen Zugriffsrechte aus CLOUD Act und FISA 702 jedoch nicht auf, und nach dem Schrems-II-Urteil von 2020 bleibt die Rechtslage durch eine anhängige Klage gegen das Framework vor dem EuGH weiter in Bewegung. Für besonders sensitive Datenkategorien wie Personal-, Gesundheits- oder Geschäftsgeheimnisdaten empfehlen sich daher EU-Sovereign-Cloud-Optionen oder europäische Anbieter sowie technische Maßnahmen wie kundenverwaltete Verschlüsselungsschlüssel, bei denen der Anbieter selbst die Daten nicht entschlüsseln kann. Eine systematische Datenklassifikation und ein sauberer Auftragsverarbeitungsvertrag inklusive Prüfung der Sub-Auftragsverarbeiter sind dafür die Grundlage.
Wie verhindern wir Vendor-Lock-in im Cloud-ERP?
Der wichtigste Hebel ist eine bereits im Vertrag verankerte Exit-Strategie mit klaren Klauseln zu Datenexport, Schnittstellenoffenheit und Übergangsunterstützung im Kündigungsfall. Achten Sie darauf, Daten in standardisierten Formaten wie CSV, JSON oder XML exportieren zu können, Standard-APIs zu nutzen und Customizing möglichst auf separaten Layern oder Microservices statt im Core-System zu verankern. Eine Mindestlaufzeit für Übergangsunterstützung von zwölf bis achtzehn Monaten nach Kündigung verschafft realistischen Spielraum für eine geordnete Migration, und eine anbieterunabhängige Dokumentation von Konfigurationen, Workflows und Berechtigungen ist die Basis für die Re-Implementierung in einem alternativen System. Ein jährlich durchgeführter Test-Export stellt sicher, dass die exportierten Daten im Ernstfall tatsächlich vollständig und interpretierbar sind, denn ein nie getesteter Exit-Plan hilft im Krisenfall nicht.