Cloud vs. On-Premise ERP: Was passt wirklich zum Mittelstand?

Dies ist ein Beitrag unseres Trainers  Jannik Zinkl

Fast jeder deutsche Mittelständler, den wir beraten, steht irgendwann vor der gleichen Frage: Soll das neue ERP-System in die Cloud oder bleibt es beim klassischen On-Premise-Betrieb im eigenen Rechenzentrum? Die Antworten, die man in vielen Beiträgen liest, lassen sich schnell zusammenfassen: Cloud ist modern, flexibel und günstig. On-Premise ist sicher, kontrollierbar, aber altbacken.

Das Problem: Die meisten Unternehmen stehen gar nicht vor dieser Entweder-oder-Entscheidung. Sie haben bereits ein ERP-System — oft seit zehn, fünfzehn oder zwanzig Jahren. Es enthält Kunden-, Lieferanten-, Artikel- und Auftragsdaten, ist mit Fertigungssteuerung, Lager, Buchhaltung und teils branchenspezifischen Zusatzmodulen verwoben. Ein einfacher Wechsel auf ein Cloud-ERP ist hier weder wirtschaftlich noch betrieblich sinnvoll.

Die bessere Frage lautet deshalb: Wie modernisieren wir unser ERP schrittweise, ohne das bewährte System auf einen Schlag abzulösen? In diesem Artikel zeigen wir, warum die klassische Cloud-vs.-On-Premise-Debatte für den deutschen Mittelstand nicht mehr ausreicht — und was eine decoupled Architecture daran ändert.

Was Unternehmen tatsächlich vor der Entscheidung steht

Wenn ein Mittelständler über ERP-Neuaufstellung nachdenkt, geht es selten um die blanke Entscheidung zwischen „Cloud“ und „Server im Keller“. Meist steht dahinter eine der folgenden Situationen:

• Das bestehende ERP ist veraltet, der Hersteller stellt Support oder Entwicklung ein.
• Die Nutzeroberfläche wirkt wie aus den 2000er-Jahren, Mitarbeitende können nicht mobil oder webbasiert arbeiten.
• Kunden und Lieferanten erwarten digitale Portale, Echtzeit-Informationen, Selbstbedienung.
• Integrationen zu Online-Shops, Zeiterfassung, Lagerrobotik oder KI-gestützten Tools werden immer aufwändiger.
• Der Betrieb möchte Datensouveränität behalten, hat aber Angst vor steigenden On-Premise-Kosten und Fachkräftemangel.
• Die Wartung und Weiterentwicklung des ERP-Systems frisst Ressourcen, die für strategische Projekte fehlen.

In all diesen Fällen ist das Ziel nicht „Cloud um jeden Preis“ oder „alles beim Alten belassen“. Das Ziel ist: Ein stabiles, betriebskritisches System weiterbetreiben — und gleichzeitig moderne, flexible Services darauf aufbauen.

Schulungen & Beratungsempfehlungen

Wenn Sie Ihr ERP-System schrittweise modernisieren oder Ihr Team für den technischen Stack dahinter fit machen möchten, empfehlen wir Ihnen unsere Trainings und Beratungsangebote bei www.IT-Schulungen.com. Wir bieten sowohl offene Schulungen in unseren Schulungszentren oder online als auch maßgeschneiderte Firmenseminare mit individuell abgestimmten Inhalten und Terminen. Passende Seminare zu diesem Thema sind unter anderem:

• Next.js Anwendungsentwicklung - Kompaktkurs (5 Tage): Vermittelt App Router, Rendering, Caching, Datenbankintegration mit PostgreSQL und Drizzle sowie Authentifizierung. Ideal für Entwickler:innen, die moderne Frontends für ERP-Portale bauen möchten.
• Next.js - Docker Deployment (2 Tage): Behandelt Containerisierung, Dockerfiles, Multi-Stage Builds, Docker Compose und Deployment auf Hosts oder VPS. Essenziell für souveränes Hosting eigener ERP-Services.
• Mistral AI - Überblick, Aufbau, Besonderheiten und Unterschiede zu ChatGPT (1 Tag): Strukturierter Überblick über Mistral AI, seine Open-Source-Modelle und Einsatzszenarien für Entscheider:innen und technische Projektverantwortliche.
• Mistral AI - Entwicklung und Implementierung von KI-Lösungen (4 Tage): End-to-End-KI-Lösungen mit Mistral AI, RAG-Architekturen und Integration in bestehende Systemlandschaften für Entwickler:innen und Architekt:innen.

Für Unternehmen, die einen konkreten Modernisierungsplan für ihr ERP-System benötigen, bieten wir zudem Architektur-Reviews und Workshops an, in denen wir gemeinsam die passende Strategie für Ihre Systemlandschaft erarbeiten.

Cloud-ERP: Stärken und echte Schwächen

Cloud-ERP-Systeme wie SAP S/4HANA Cloud, Oracle NetSuite, Microsoft Dynamics 365 Business Central, Workday oder branchenspezifische Lösungen wie proAlpha Cloud haben klare Vorteile:

• Schnelle Verfügbarkeit: Oft innerhalb weniger Wochen oder Monate nutzbar.
• Regelmäßige Updates: Der Betreiber kümmert sich um Sicherheitsupdates, Compliance und neue Features.
• Geringerer Initialaufwand: Keine eigene Hardware, weniger interne IT-Ressourcen für den Betrieb.
• Skalierbarkeit: Benutzerzahlen und Module lassen sich meist flexibel erweitern.

Für Unternehmen mit standardisierten Prozessen und geringem Bedarf an Individualentwicklung kann das die richtige Wahl sein. Aber sobald ein Mittelständler spezifische Prozesse, Branchenlogik oder komplexe Integrationen hat, zeigen sich die Grenzen:

• Anpassbarkeit sinkt. Viele Cloud-ERP-Systeme bieten zwar Konfiguration, aber keine echte Individualentwicklung. Prozesse müssen sich an die Software anpassen, nicht umgekehrt.
• Vendor Lock-in. Datenexport und Migration in ein anderes System werden mit der Zeit teurer und riskanter.
• Laufende Kosten. Was anfangs günstig aussieht, wird bei wachsender Benutzerzahl, zusätzlichen Modulen und erforderlichen Integrationen schnell teuer.
• Drittlandzugriff. Bei US-basierten Anbietern oder Anbietern mit US-Muttergesellschaft kann der CLOUD Act greifen — auch wenn Daten physisch in Europa liegen. Das ist für viele Unternehmen ein relevantes DSGVO- und Vertrauensthema.
• Offline und Latenz. Für Produktionsumgebungen mit Echtzeitanforderungen oder Standorten mit schlechter Internetanbindung kann reine Cloud problematisch sein.

On-Premise-ERP: Kontrolle — aber auf altem Fundament

On-Premise-Lösungen, egal ob SAP ECC, proAlpha, abas ERP, Lexware, Navision / Dynamics NAV, Sage oder individuell entwickelte Systeme, bieten den Vorteil der Kontrolle:

• Daten liegen im eigenen Haus oder beim deutschen Hosting-Partner.
• Individuelle Anpassungen und Erweiterungen sind möglich.
• Langfristig entwickelte Prozesse und Know-how bleiben erhalten.
• Keine Abhängigkeit von externen Release-Zyklen, sofern man selbst wartet.

Aber der Nachteil ist ebenso real:

• Fachkräftemangel: Entwickler für ältere ERP-Technologien werden immer schwerer zu finden.
• Technische Veraltung: Monolithen, veraltete Oberflächen, schwierige Integrationen.
• Hoher Betriebsaufwand: Updates, Sicherheitspatches, Backups, Monitoring, Infrastruktur.
• Mangelnde Agilität: Neue Features, mobile Oberflächen, KI-Integration oder Kundenportale lassen sich nur mit hohem Aufwand realisieren.

Wer also heute noch argumentiert, On-Premise sei generell die bessere Wahl, übersieht, dass der Wartungsaufwand und die technische Schuld vieler alter Systeme mittlerweile ein echtes Wachstumshemmnis sind.

Warum die Entweder-oder-Frage veraltet ist

Der Fehler in der Debatte liegt darin, dass Cloud und On-Premise als zwei Gegenentwürfe behandelt werden, die sich gegenseitig ausschließen. In der Praxis moderner Softwarearchitektur ist das längst nicht mehr so.

Der entscheidende Punkt ist: Das ERP-System muss nicht das Zentrum jeder einzelnen Funktion sein. In vielen Unternehmen ist das ERP die einzige Quelle der Wahrheit für Stammdaten, Aufträge, Rechnungen, Lager und Fertigung. Das muss es auch bleiben. Aber die Interaktion mit Kunden, Lieferanten und Mitarbeitenden, die digitale Verarbeitung, die KI-gestützte Analyse und die Integration neuer Tools müssen nicht alle im ERP selbst passieren.

Hier kommt die decoupled Architecture ins Spiel.

Decoupled Architecture: Der dritte Weg für den Mittelstand

Eine decoupled Architecture ist keine Mischform aus Cloud- und On-Premise-ERP. Sie ist ein eigenständiger Architekturansatz, bei dem das ERP-System als System of Record für bestehende Kerndaten erhalten bleibt — egal ob es aktuell in der Cloud oder On-Premise läuft. Parallel dazu entsteht ein neues, eigenständiges System mit eigener Datenbank und eigenem State, das über kontrollierte Adapter mit dem ERP synchronisiert. In diesem neuen System laufen moderne Frontends, Workflows, KI-Funktionen und neue Geschäftslogik. Statt das ERP auf einen Schlag zu ersetzen, wird es schrittweise von einer modernen Schicht entlastet und ergänzt.

Typische Komponenten einer solchen Architektur:

Das neue System hält eigenständige Daten: Kundenportal-User, Dokumente, Workflow-States, KI-Embeddings, Chat-Historien, Konfigurationen. Das ERP bleibt weiterhin führend für Auftragsdaten, Rechnungen, Lager und Fertigung. Über den Adapter-Layer werden Daten kontrolliert zwischen beiden Systemen abgeglichen. So entsteht keine gefährliche Direktkopplung, sondern eine saubere, erweiterbare Architektur.

Statt also das ERP-System selbst zu migrieren, kann ein Unternehmen beispielsweise zuerst ein Kundenportal auf dem neuen System bauen. Das Portal synchronisiert über den Adapter Auftragsdaten aus dem ERP, speichert aber eigene Benutzer, Einstellungen und Dokumente selbst. Dann ein Mitarbeiter-Portal, dann eine KI-gestützte Dokumentenverarbeitung. Jeder Schritt liefert eigenständigen Nutzen — ohne Big Bang im ERP.

Wenn das ERP keine guten APIs hat: SQL, Views und Adapter

Ein realistischer Einwand: „Das klingt gut, aber unser ERP hat kaum brauchbare Schnittstellen.“

Das trifft auf viele ältere ERP-Systeme zu — sei es Lexware, Navision, ältere proAlpha-Versionen, Sage oder branchenspezifische Lösungen. Hier funktioniert die decoupled Architecture trotzdem, weil sie nicht zwingend auf moderne REST- oder GraphQL-APIs angewiesen ist.

Mögliche Anbindungswege:

• SQL-Read-Only-Zugriff auf eine Datenbank-Kopie oder Read-Replica. Ein separater Datenbank-Benutzer liest nur die benötigten Tabellen und Views. Keine Schreibrechte, keine direkte Gefahr für das ERP.
• ODBC- oder OLEDB-Adapter für Windows-basierte ERP-Systeme wie Dynamics NAV, Sage oder ältere proAlpha-Versionen.
• CSV-/XML-Exporte aus dem ERP, die periodisch per BullMQ-Job oder ETL-Prozess verarbeitet werden.
• Datenbank-Views im ERP, die stabilisierte Schnittstellen bilden, ohne das Tabellenschema preiszugeben.
• Change Data Capture (CDC) oder Trigger-basierte Ereignisse, um Datenänderungen an den Entkopplungs-Layer zu übermitteln.

Wichtige Regeln für den Adapter-Layer:

• Alle ERP-Zugriffe laufen zentral über den Adapter. Weder Frontends noch KI-Services noch Workflows sprechen direkt mit der ERP-Datenbank. Der Adapter ist die einzige Stelle, die das ERP-Schema kennt.
• Read-Replica oder Nachtabzug für lesende Abfragen nutzen, damit das produktive ERP nicht belastet wird.
• Schreiben in das ERP ist möglich, aber kontrolliert: Wenn das ERP keine brauchbare API für einen Schreibvorgang bietet, kann der Adapter nach Prüfung der Geschäftsregeln und Konsistenz direkt in ERP-Tabellen schreiben. Ad-hoc-Queries von einzelnen Anwendungen sind dagegen tabu.
• Schemänderungen absichern: Wenn sich ERP-Tabellen ändern, muss nur der Adapter angepasst werden, nicht das neue System oder die KI-Anwendungen.

Hinter dem Adapter liegt das neue System mit eigener Datenbank. Alle modernen Anwendungen, Portale, Workflows und KI-Agenten arbeiten auf diesem eigenen State. Das ERP wird nur noch dort abgefragt oder aktualisiert, wo es fachlich sinnvoll ist. Das ist der entscheidende Unterschied zur klassischen „ERP-Erweiterung“: das neue System ist kein Anhängsel, sondern eine eigenständige Plattform.

KI-Agenten, Vector-Datenbanken und die neue Datenbank

Ein besonders starker Effekt der decoupled Architecture zeigt sich bei KI und Agenten. Im neuen System können Vector-Datenbanken, Embeddings und Agent-Workspaces betrieben werden, die unabhängig vom ERP existieren:

• Dokumente und Wissensbasis werden im neuen System gespeichert und in eine Vector-DB indexiert.
• KI-Agenten greifen auf diese Vector-DB zu, beantworten Fragen, fassen Verträge zusammen oder unterstützen Support-Prozesse.
• Bedarfsfall synchronisiert der Adapter relevante ERP-Daten wie Auftragsstatus, Kundenstammdaten oder Artikelinformationen in das neue System, damit die KI kontextreich arbeiten kann.
• Rückwirkend können KI-Ergebnisse oder durch Agenten ausgelöste Prozesse über den Adapter wieder ins ERP fließen — etwa genehmigte Belege, aktualisierte Stammdaten oder Statusänderungen.

Plötzlich lassen sich Dinge bauen, die im ERP-Kern selbst undenkbar wären: intelligente Kundenportale, automatisierte Dokumentenanalyse, KI-gestützte Qualitätssicherung, Sprachassistenten für die Produktion — und das alles DSGVO-konform auf souveränem Hosting in Deutschland oder der EU.

Wie das in der Praxis aussieht: Drei Beispiele

Beispiel 1: Kundenportal für Auftragsstatus und Dokumente

Ein Fertigungsbetrieb nutzt proAlpha oder abas ERP für Auftragsabwicklung und Fertigungssteuerung. Kunden rufen regelmäßig an und fragen nach Lieferterminen, Rechnungen oder Lieferscheinen.

Klassischer Ansatz: Ein Modul im ERP erweitern oder ein teures Add-on kaufen.

Decoupled Ansatz: Ein neues Kundenportal wird auf einer modernen Plattform mit Next.js, Payload CMS und eigener Datenbank entwickelt. Das Portal hat eigene Benutzerkonten, Einstellungen und Dokumente. Über einen Adapter synchronisiert es periodisch oder ereignisgesteuert Auftragsstatus, Lieferscheine und Rechnungen aus dem ERP. Dabei greift der Adapter entweder auf eine REST-API, einen SQL-Read-Adapter oder ODBC zu. Rechnungen und Lieferscheine werden im Payload CMS des neuen Systems als Dokumenten-Hub verwaltet. Kunden können mobil arbeiten, KI-Funktionen wie „Fasse meine offenen Posten zusammen“ nutzen — und das alles ohne direkte ERP-Anbindung des Portals.

Vorteil: Das ERP wird nicht berührt, das Portal hat eigenen State, moderne UX, schneller Go-Live.

Beispiel 2: Automatisierte Dokumentenverarbeitung

Ein Handelsunternehmen erhält täglich hunderte Bestellungen, Anfragen und Rechnungen per E-Mail oder PDF. Das ERP könnte diese zwar erfassen, aber nur mit viel manuellem Aufwand oder teuren Modulen.

Decoupled Ansatz: Eingehende Dokumente werden im neuen System in Payload CMS oder einem Dokumentenmanagement zwischengespeichert und in einer Vector-Datenbank indexiert. BullMQ-Jobs extrahieren Inhalte per KI, prüfen Daten und halten den Verarbeitungsstatus in der eigenen Datenbank vor. Genehmigte Belege werden über den Adapter kontrolliert ins ERP überführt — entweder per API oder, wenn nötig, direkt per SQL-Adapter.

Vorteil: Automatisierung ohne ERP-Lock-in, Audit-Trail im neuen System, leichte Anpassbarkeit, KI-Agenten können später auf die Dokumenten-Wissensbasis zugreifen.

Beispiel 3: Produktionsnahe Meldung und Shopfloor-Integration

In einem Maschinenbau-Unternehmen sollen Maschinenstammdaten, Auftragsdaten und Fertigungsrückmeldungen mit einem neuen Shopfloor-System verbunden werden.

Decoupled Ansatz: Ein neues Shopfloor-System mit eigener Datenbank wird aufgebaut. Über den Adapter synchronisiert es nur die benötigten Maschinenstammdaten und Auftragsdaten aus dem ERP. Ereignisse wie „Auftrag gestartet“ oder „Maschine stillgestanden“ werden asynchron im neuen System über BullMQ verarbeitet und dort persistiert. Dashboards und Alarme entstehen in modernen Frontends, die auf den eigenen State zugreifen. Rückmeldungen werden über den Adapter kontrolliert ins ERP zurückgeschrieben.

Vorteil: Stabile Verbindung ohne direkte Kopplung, der Shopfloor hat eigenen State, spätere Erweiterungen leicht möglich.

Wann welcher Weg passt

Für den klassischen deutschen Mittelstand mit gewachsenen Prozessen, spezifischen Branchenanforderungen und hoher Datensensibilität ist die decoupled Architecture oft der pragmatischste Weg.

Total Cost of Ownership: Wie die Kosten wirklich laufen

Viele Unternehmen entscheiden sich für Cloud-ERP, weil die Startkosten niedrig erscheinen. Doch der Blick auf fünf bis zehn Jahre zeigt ein differenzierteres Bild:

Die decoupled Architecture verteilt Investitionen über die Zeit. Anstatt in Jahr eins ein komplettes ERP-Replacement zu finanzieren, wird Schritt für Schritt modernisiert — und jeder Schritt liefert messbaren Geschäftswert.

Customisation und Anpassbarkeit im KI-Zeitalter

Früher bedeutete Customization im ERP-Kontext teure Programmierung und enge Abhängigkeit vom Hersteller oder einem Spezialisten. Heute ist das anders. Mit modernen APIs, Workflow-Engines und KI-Services lassen sich individuelle Prozesse außerhalb des ERP-Kerns abbilden.

Ein Beispiel: Ein Unternehmen möchte Sonderpreise für langjährige Kunden automatisch berechnen. Statt im ERP ein neues Modul zu programmieren, kann ein BullMQ-Worker die Regeln ausführen, ERP-Daten abfragen, Preise berechnen und Ergebnisse zurückschreiben. Ändert sich die Geschäftslogik, wird der Worker angepasst — ohne ERP-Eingriff.

Mit Sprachmodellen wie Mistral AI lassen sich zudem Dokumente, E-Mails, Kundenanfragen und Berichte automatisch verarbeiten. Die KI arbeitet als Dienst, nicht als ERP-Modul. Das macht den Einsatz flexibler und DSGVO-konformer planbar.

Migration: Nicht alles auf einmal

Der große Fehler bei ERP-Modernisierung ist die Annahme, man müsse alles auf einmal umstellen. Das führt zu jahrelangen Projekten, Budgetüberschreitungen und Frustration.

Ein smarterer Weg:

1. Bestandsaufnahme: Welche Prozesse laufen im ERP? Welche Daten sind kritisch? Welche Schnittstellen existieren? Was fehlt komplett?
2. Schnellgewinn identifizieren: Wo schmerzt es am meisten? Kundenportal? Dokumentenverarbeitung? Mobile Erfassung? KI-gestützte Suche?
3. Sync-Adapter bauen: Einen kontrollierten Adapter etablieren, der Daten zwischen ERP und neuem System austauscht. Hier wird auch entschieden, welche Daten nur gelesen, welche synchronisiert und welche zurückgeschrieben werden.
4. Neues System mit eigener Datenbank aufsetzen: Die moderne Plattform mit Next.js, Payload CMS und eigener DB bauen — der erste Service entsteht darauf.
5. Schrittweise erweitern: Weitere Services, KI-Integrationen, Vector-Datenbanken, Agenten, Reporting, schließlich gezielte Ersetzung einzelner ERP-Module.

So entsteht keine Migration im klassischen Sinne, sondern eine kontrollierte Evolution.

Fazit

Die Frage „Cloud oder On-Premise ERP?“ ist für den deutschen Mittelstand längst zu kurz gedacht. Wer ein junges, standardisiertes Unternehmen führt, für den kann ein Cloud-ERP die richtige Lösung sein. Wer maximale Kontrolle über sensible Daten braucht, wird weiter On-Premise oder souverän gehostet setzen.

Aber die meisten deutschen Mittelständler befinden sich irgendwo dazwischen: Sie haben ein funktionierendes ERP, das sie nicht einfach abschreiben können, gleichzeitig müssen sie aber digitaler, kundenorientierter und effizienter werden.

Für diese Unternehmen ist die decoupled Architecture der bessere Weg. Das ERP bleibt System of Record für die bestehenden Kerndaten. Parallel entsteht ein neues, eigenständiges System mit eigener Datenbank, auf dem moderne Frontends, Workflows, KI-Services und Agenten laufen. Über einen kontrollierten Sync-Adapter werden Daten zwischen ERP und neuem System abgeglichen. So lässt sich Schritt für Schritt modernisieren — ohne Big Bang, ohne Vendor Lock-in und ohne die hart erkämpfte Prozess-Know-how aus dem alten System zu verlieren. Plötzlich können KI-Agenten, Vector-Datenbanken und moderne Benutzererfahrungen gebaut werden, die im ERP selbst nie möglich gewesen wären.

Wenn Sie wissen möchten, wie das für Ihr spezifisches ERP-System aussehen kann, sprechen Sie uns an. Ob Lexware, proAlpha, abas, SAP, Sage oder Navision: Die Architekturprinzipien bleiben ähnlich.

FAQs

Was ist eine decoupled Architecture im ERP-Kontext?

Eine decoupled Architecture trennt das ERP-System als zentrale Datenquelle für bestehende Kerndaten von einem neuen, eigenständigen System. Dieses neue System hat eine eigene Datenbank und einen eigenen State, auf dem moderne Services, Frontends, Workflows und KI-Agenten laufen. Ein kontrollierter Adapter synchronisiert Daten zwischen ERP und neuem System. Das ERP bleibt System of Record für seine Kerndaten, während Kundenportale, Dokumenten-Hubs, KI-Agenten und Vector-Datenbanken im neuen System betrieben werden.

Lohnt sich ein Cloud-ERP für den Mittelstand?

Ja, wenn die Prozesse standardisierbar sind und wenig Individualentwicklung nötig ist. Für Unternehmen mit komplexen, branchenspezifischen Prozessen, vielen Integrationen oder hohen Datensouveränitätsanforderungen kann ein reines Cloud-ERP aber schnell an Grenzen stoßen.

Was sind typische ERP-Systeme bei deutschen Mittelständlern?

Häufig anzutreffen sind SAP ECC und S/4HANA, proAlpha, abas ERP, Lexware, Microsoft Dynamics NAV / Navision, Sage sowie verschiedene Branchenlösungen. Viele davon laufen heute noch On-Premise und sind eng mit betrieblichen Prozessen verwoben.

Wie lässt sich KI DSGVO-konform in ERP-Prozesse einbauen?

Mit europäischen Sprachmodellen wie Mistral AI und einem souveränen Hosting-Stack in Deutschland oder der EU lassen sich KI-Services bauen, bei denen personenbezogene Daten die EU nicht verlassen. Wichtig sind Auftragsverarbeitungsverträge, Löschkonzepte, Datenminimierung und ggf. eine Datenschutz-Folgenabschätzung.

Ist eine decoupled Architecture teurer als ein ERP-Wechsel?

Nicht zwangsläufig. Ein ERP-Wechsel erfordert oft hohe Initialkosten, lange Projektlaufzeiten und erheblichen internen Aufwand. Die decoupled Architecture verteilt Investitionen auf mehrere, eigenständig nutzbare Schritte. Der erste Service — etwa ein Kundenportal — kann bereits nach wenigen Wochen live gehen.