ERP-Migration: Wann Cloud — und wann On-Prem bleiben

TL;DR

  • ERP-Migrationen scheitern an Integration und Ausfall, nicht VM-Größe — jede Schnittstelle mappen vor Cloud/On-Prem-Wahl.
  • On-Prem bei Latenz, OT-Kopplung, Lizenzen; Cloud wenn Elastizität, DR oder SaaS-Pfad klar.
  • Hybrid oft = ERP-Kern On-Prem + Analytics/Portal Cloud — nicht zwei halbe Migrationen.
  • Rollback-Owner und Restore-Test vor Produktions-Cutover.

Ein Operationsleiter hatte ein fünfzehn Jahre altes, stark angepasstes ERP — noch profitabel. Ein Integrator schlug „Cloud-first Modernisierung“ in achtzehn Monaten vor, ein Hoster VM-Lift in sechs Wochen. Keiner erklärte Scanner im Lager oder Rollback bei fehlgeschlagenem Monatsabschluss am Sonntag.

ERP-Entscheidungen bei 50–200 Mitarbeitern sind selten rein Cloud oder On-Prem. Dieser Leitfaden liefert eine Vier-Achsen-Scorecard vor dem Budget.

Vier Achsen

  1. Ausfalltoleranz
  2. Integrationskopplung — PLC, Drucker, WMS, EDI, flaches L2?
  3. Lizenzen und Compliance
  4. Operative Reife — Owner für ERP, DB, Netz?

Wann On-Prem rational

Fertigung/Logistik nahe der Linie. Regulierte Branchen mit dokumentiertem Datenfluss. Legacy günstiger stabilisieren als refaktorieren. On-Prem heißt nicht „keine Cloud“ — erst AD, MFA, Patch, Offline-Backup.

Wann Cloud gewinnt

Elastische Test-UMGs, DR ohne Generator, EOL-Hardware-Ablösung, angrenzende Workloads (Reporting, Portal, Files) vor ERP-Kern — häufiger Erfolg als Big-Bang.

Hybrid richtig vs. falsch

Richtig: ERP On-Prem, nächtliche anonymisierte Extracts, SSO, Runbook pro Tier. Falsch: ERP Cloud + temporäres PostgreSQL auf NAS + VPN-Hairpins.

Rollback

  • Benannter Rollback-Entscheider.
  • ERP-DB-Restore-Test < 30 Tage mit Timing.
  • Month-End-Blackout mit Finance.
  • Integrationspartner mit Eskalationsnummern.

Schnittstellen-Inventur: neunzig Minuten, die ein Quartal retten

Bevor jemand vCPU dimensioniert: Raum mit Operations, Finance und der Person, die wirklich bucht. Jedes System auflisten, das ERP liest oder schreibt — offizielle APIs zuletzt, inoffizielle zuerst. Im polnischen und deutschen Mittelstand finden wir dieselben Geister: CSV an den Spediteur per Aufgabenplanung auf einem Lager-PC; Barcodedrucker als LPT1 über Terminalserver; Excel-„Integration“ von 2017, die Controlling noch an die Bank mailt; Hallenterminal mit Roh-SQL ins ERP, weil die Lizenz für den richtigen Connector abgelaufen ist.

Jede Schnittstelle: Richtung, Owner, was bei vier Stunden Verspätung bricht, und ob Hostname- oder IP-Wechsel überlebt. Können Sie das letzte Feld nicht füllen, haben Sie keinen Migrationsplan — Sie haben ein Cutover-Gebet. Wir haben mehr ERP-Cloud-Züge wegen Druckern und EDI verschoben als wegen zu wenig vCPU.

Stacks, die wir wirklich treffen

  • Comarch Optima / XL — oft ein SQL Server, schwere Formulare, Shop- und WMS-Add-ons. Cloud-tauglich, wenn SQL + App + Spooler eine Einheit bleiben. Feindlich, wenn „nur die Datenbank in Azure“ und Terminals on-prem hinter einem geschwätzigen VPN bleiben.
  • Enova365 — serviceorientierter, stirbt trotzdem an Druck und Fiskal. Vor dem SaaS-Jubel klären, wer den lokalen Fiskaldrucker hält.
  • SAP Business One — Lizenz und Partnerpolitik wiegen so viel wie Latenz. VM-Lift kann rational sein; „gleich mit umschreiben“ ist ein zweites Projekt im ersten.
  • Custom / Fox / Access-Reste — hängt der Monatsabschluss an einer Desktop-MDB, on-prem zuerst oder Cloud wartet. Sonst endet der Cutover sonntags um 23:00 mit Finance am Telefon.

SaaS-ERP ist richtig, wenn Prozesse ins Produkt passen. Eine Falle, wenn der Integrator „Konfiguration“ verkauft, die eine Neuschreibung der Lagerlogik ohne Rollback zum alten Anbieter ist.

Cutover-Wochenende: ehrlicher Zeitplan

Typische Firma 80–150 Personen, ein Lager, eine Buchungskreis, wenn Schnittstellen kartiert und Restore in den letzten 30 Tagen getestet:

  1. Donnerstag 16:00 — unkritische Writes einfrieren; letztes Backup; Restore-Ziel leer und erreichbar.
  2. Freitag 18:00 — User raus; letztes Backup; Start; Integrationspartner auf Konferenznummer, nicht Mail.
  3. Samstag früh — Rauch: Testrechnung, Etikett, Dummy-EDI, bekannter Auftrag. Finance unterschreibt „wir schließen wenn wir bleiben“ oder „Rollback“.
  4. Sonntag 12:00 spätestens — Go / No-Go. Bei No-Go führt der Rollback-Owner (ein Name) das Restore-Runbook. Kein Gremium.
  5. Montag 07:00 — Hypercare: Drucker, EDI, Bankdateien, die drei Reports, die der Vorstand wirklich öffnet.

Kann der Integrator das nicht auf eine Seite mit Namen und Nummern bringen — Datum verschieben, nicht die Tests. Weiter: Restore-Nachweis vor jedem Produktionsfenster; Hybrid, wenn die Linie lokal bleiben muss.

Nächster Schritt

Alle Systeme listen, die ERP lesen/schreiben. Vier Achsen mit Finance, Operations, IT scoren. Einen angrenzenden Workload zuerst in die Cloud. Cloud-Dienste für Architektur und Hosting; Apps / E-Commerce für Shop-Integrationen.

Projekt besprechen?

Schreiben Sie uns

Mehr zu diesem Thema

Newsletter abonnieren

Erhalten Sie Neuigkeiten, Updates und Sonderangebote direkt per E-Mail.
Nein, danke