IT-Modernisierung im Mittelstand: vom Legacy-ERP zur Cloud-Architektur

1. Warum Legacy-Systeme im Mittelstand zum Engpass werden

Viele mittelständische Unternehmen arbeiten mit ERP-Landschaften, die über zwanzig Jahre hinweg an das eigene Geschäft angepasst wurden. Diese Systeme bilden reale Prozesse präzise ab — genau das macht sie wertvoll und gleichzeitig schwer veränderbar. Individuelle Modifikationen, undokumentierte Schnittstellen und Abhängigkeiten zu einzelnen Wissensträgern führen dazu, dass jede Änderung teuer, langsam und risikobehaftet wird.

Der Engpass zeigt sich selten als klassischer Ausfall. Er zeigt sich darin, dass neue Produkte, Standorte oder Kundenanforderungen Monate statt Wochen brauchen, dass Auswertungen aus mehreren Systemen manuell zusammengeführt werden und dass Fachbereiche eigene Insellösungen aufbauen, weil die Kernsysteme nicht mitkommen.

• Hoher Modifikationsgrad im ERP verhindert Releasefähigkeit und Wartbarkeit
• Punkt-zu-Punkt-Schnittstellen zwischen ERP, MES, PLM, CRM und Logistik
• Fehlende durchgängige Datenbasis für Planung, Controlling und Service
• Wissen liegt bei wenigen Personen statt in Dokumentation und Architektur
• Auslaufender Herstellersupport erzeugt Termindruck ohne inhaltliche Zielbildung

2. Zielbild statt Technologieentscheidung

Eine Modernisierung beginnt nicht mit der Frage, welche Cloud-Plattform eingesetzt wird, sondern mit der Frage, welche Fähigkeiten das Unternehmen in drei bis fünf Jahren braucht. Aus diesen Fähigkeiten leiten sich Architektur, Betriebsmodell und Reihenfolge ab — nicht umgekehrt.

Bewährt hat sich ein Zielbild auf drei Ebenen: Geschäftsfähigkeiten (was muss das Unternehmen können), Applikationslandschaft (welche Systeme erbringen diese Fähigkeiten) und Datenarchitektur (welche Daten müssen wo verlässlich verfügbar sein). Erst danach folgt die Technologieauswahl.

• Standardnah bauen: Erweiterungen konsequent außerhalb des ERP-Kerns
• Integration über eine zentrale Integrationsschicht statt bilateraler Schnittstellen
• Daten einmal erfassen, mehrfach nutzen — mit klarer fachlicher Verantwortung
• Betriebsmodell und Sicherheitsanforderungen von Beginn an mitdenken

3. Migrationsstrategien im Vergleich

Für die Ablösung gewachsener Systeme gibt es keine allgemeingültige Antwort. Entscheidend ist, die Landschaft in Bereiche zu zerlegen und je Bereich bewusst zu entscheiden — statt ein einziges Vorgehen über die gesamte IT zu legen.

• Rehost: schneller Plattformwechsel ohne funktionale Änderung — geeignet für Zeitdruck durch Rechenzentrums- oder Supportende
• Replatform: Modernisierung von Datenbank, Laufzeitumgebung und Betrieb bei stabiler Fachlogik
• Refactor: schrittweise Herauslösung von Funktionen in eigene Services rund um einen standardnahen Kern
• Replace: Ablösung durch Standardsoftware oder SaaS, wenn kein Differenzierungsbeitrag im Eigenbau liegt
• Retain/Retire: bewusst belassen oder abschalten — jede nicht migrierte Anwendung spart Aufwand und Risiko

4. Daten und Integration als Fundament

Die meisten Modernisierungsprogramme scheitern nicht an der Cloud, sondern an Daten. Stammdaten sind mehrfach vorhanden, Bewegungsdaten liegen in unterschiedlichen Granularitäten vor, und historische Sonderfälle sind in Programmcode statt in Regeln abgebildet.

Wir empfehlen, Datenmigration und Integrationsarchitektur als eigenständigen Arbeitsstrang zu führen — mit fachlicher Verantwortung, messbarer Datenqualität und automatisierten Prüfungen vor jedem Migrationsschritt. In der Produktion gehört dazu ausdrücklich die Anbindung von Shopfloor-Systemen wie MES und Instandhaltung.

• Stammdaten bereinigen, bevor migriert wird — nicht danach
• Integrationsschicht mit versionierten, dokumentierten Schnittstellen aufbauen
• Fachliche Datenverantwortung benennen (Data Ownership)
• Automatisierte Abgleiche zwischen Alt- und Neusystem in jeder Welle

5. Betrieb, Sicherheit und Compliance

Cloud-Architekturen verlagern Aufwand vom Rechenzentrum in Governance, Automatisierung und Betrieb. Wer diesen Anteil nicht plant, zahlt später über Betriebskosten und Störungen. Für den Mittelstand ist ein klar geschnittenes Betriebsmodell — intern, extern oder hybrid — meist wirtschaftlicher als der Aufbau vollständiger Eigenkompetenz.

Sicherheits- und Compliance-Anforderungen wie NIS2, DSGVO und branchenspezifische Nachweispflichten gehören in die Architektur und nicht in ein nachgelagertes Prüfprojekt. Berechtigungen, Protokollierung, Backup- und Wiederanlaufkonzepte werden mit dem ersten Release entworfen.

6. Wirtschaftlichkeit belastbar rechnen

Ein Business Case für IT-Modernisierung trägt nur, wenn er über die Lizenz- und Projektkosten hinausgeht. Relevant sind laufende Betriebskosten, Wartungsaufwände der Altwelt, Ausfall- und Compliance-Risiken sowie der Wert schnellerer Änderungen im Geschäft.

Praktisch bewährt hat sich, den Nutzen je Welle zu bemessen: Welche manuelle Tätigkeit entfällt, welcher Prozess wird durchgängig, welche Altanwendung kann abgeschaltet werden. So entsteht ein Programm, das sich abschnittsweise rechtfertigt statt erst am Ende.

• Total Cost of Ownership über fünf Jahre statt Projektbudget
• Abschaltung von Altanwendungen als expliziten Nutzen einplanen
• Cloud-Kosten von Beginn an steuern (FinOps-Routinen, Budgets, Alarme)
• Nutzen je Release messen und im Steuerkreis sichtbar machen

7. Typische Fehler — und wie Sie sie vermeiden

Die folgenden Muster begegnen uns in Modernisierungsvorhaben im Mittelstand besonders häufig.

• Big Bang statt Wellen: ein einziger Umstellungstermin bündelt alle Risiken auf einen Tag
• Altlasten übernehmen: Modifikationen werden migriert, statt fachlich hinterfragt zu werden
• Fachbereiche zu spät einbinden: Akzeptanz entsteht nicht im Test, sondern in der Gestaltung
• Kein Zielbild: Einzelentscheidungen ergeben in Summe keine tragfähige Architektur
• Betrieb erst am Ende denken: Betriebs- und Sicherheitsanforderungen kommen als Nachlauf
• Kein Abschaltplan: die Altwelt bleibt parallel bestehen und verdoppelt Kosten