Montagmorgen, 08:17 Uhr: Ein Team im Vertrieb kopiert wieder Bestellpositionen aus einer AS/400-Maske in Excel, dann ins CRM, dann ins ERP. Nebenbei laufen Mahnwesen und Versandstatus in zwei weiteren Tools. Niemand macht das gern, aber alle wissen: Wenn man „am Kernsystem“ etwas anfasst, kann es den Betrieb stoppen. Genau hier scheitern viele Modernisierungsprojekte - nicht an Technik, sondern an fehlender Risikosteuerung.
Eine Legacy-System-Modernisierung in Phasen ist der pragmatische Weg, aus diesem Dilemma herauszukommen: Betrieb sichern, ROI früh sichtbar machen, Architektur sauber weiterentwickeln. Nicht als Mammutprojekt mit Big-Bang-Risiko, sondern als kontrollierte Abfolge von Etappen, die jeweils ein konkretes operatives Problem lösen.
Warum „in Phasen“ in der Praxis besser funktioniert
Die Realität in deutschen Unternehmen ist selten „Greenfield“. Häufig sehen wir Mischlandschaften aus Microsoft Dynamics NAV/Business Central, Datev-Anbindungen, eigenentwickelten .NET-Tools, einem Java-Monolithen, plus Excel als heimlichem Orchestrator. Dazu kommen regulatorische Anforderungen (GoBD, revisionssichere Ablage, Rollen- und Berechtigungskonzepte) und knappe IT-Kapazitäten.
Der entscheidende Vorteil von Phasen: Sie trennen Risiko und Wertschöpfung. Statt alles zu ersetzen, identifizieren Sie zuerst die Prozessstellen, die Zeit verbrennen oder Fehler produzieren - und bauen dort gezielt neue Bausteine an, ohne den Kern sofort zu zerlegen.
Trade-off: Phasenmodernisierung ist nicht „schneller“ im Sinne von sofort alles neu. Sie ist schneller in dem, was zählt - messbare Verbesserungen im Betrieb, ohne Stillstand. Wer unbedingt „alles neu“ will, zahlt meist mit langen Freeze-Phasen, Shadow-IT und einem Projekt, das in der Prioritätenliste nach unten rutscht.
Die 6-Phasen-Roadmap für Legacy System Modernisierung in Phasen
Diese Roadmap ist bewusst operativ gedacht. Jede Phase hat ein Ergebnis, das man im Alltag merkt - und ein technisches Artefakt, das spätere Schritte einfacher macht.
Phase 1: Prozess- und Risiko-Schnitt (2-10 Tage)
Starten Sie nicht mit Technologie, sondern mit einem klaren Schnitt: Welche Prozesse sind geschäftskritisch, welche verursachen messbare Reibung, und wo ist das Ausfallrisiko am höchsten?
In deutschen SMBs sind typische „ROI-Hotspots“:
- Auftragsanlage und Auftragsergänzungen (Copy-Paste zwischen CRM, ERP, Versand)
- Rechnungsprüfung und Freigaben (E-Mail-Chaos, fehlende Audit-Trails)
- Reporting (Excel-Ketten, manuelle Monatsabschlüsse)
- Kundenportale (Statusanfragen, Dokumentenabrufe)
Das Ergebnis dieser Phase ist kein 40-Seiten-Papier, sondern eine priorisierte Problem-Landkarte: 3-5 Use Cases, je mit Zeitverlust, Fehlerkosten, Stakeholdern, Datenquellen, und einem Risikoprofil (z.B. „wenn das ausfällt, steht Versand“).
Phase 2: Daten- und Integrationsrealität klären (1-2 Wochen)
Legacy-Projekte scheitern oft an „Daten sind irgendwo“. Klären Sie früh: Wo liegt die führende Wahrheit (System of Record)? Welche Schnittstellen existieren wirklich (nicht nur im Organigramm)?
Konkrete Beispiele aus typischen Stacks:
- AS/400 oder IBM i mit flachen Exporten, nachts generiert
- SQL Server unter einem alten .NET-WinForms-Client
- SAP ECC mit IDoc/BAPI, aber niemand will den Core anfassen
- Datev-Export, der „seit Jahren so läuft“
Ziel ist eine Integrationsstrategie, die realistisch ist: API-first, wo möglich. Wo nicht, arbeiten Sie mit stabilen Adapter-Schichten, Events oder geplanten Exports - aber sauber versioniert und überwacht.
Trade-off: „Quick and dirty“ CSV-Exporte können als Übergang okay sein, wenn Monitoring, Validierung und Verantwortlichkeiten geklärt sind. Ohne das bauen Sie nur neue manuelle Arbeit - jetzt eben im Serverraum.
Phase 3: Der erste „Strangler“-Baustein (2-6 Wochen)
Jetzt kommt der Teil, der Vertrauen schafft: ein neues Modul, das einen klar abgegrenzten Prozess ersetzt, während das Legacy-System weiterläuft. Dieses Muster wird oft als Strangler Fig bezeichnet: Neues wächst um Altes herum, bis man Teile abschalten kann.
Gute Kandidaten für den ersten Baustein sind Prozesse mit hoher Frequenz und klarer Abgrenzung, zum Beispiel:
- Automatisierte Auftragserfassung aus E-Mail/PDF in das ERP (mit Freigabe-Workflow)
- Ein internes Tool für Freigaben, das Audit-Trails liefert (GoBD-fähige Protokollierung)
- Ein Kundenportal für Status und Dokumente, das Anfragen reduziert
Wichtig: Der Baustein braucht Produktionsqualität. Kein „Proof of Concept“, der in drei Monaten weggeworfen wird. Dazu gehören Logging, Rollen, Fehlerpfade, und ein Support-Plan.
Wenn wir solche Quick-Wins umsetzen, rechnen wir sie bewusst in operativen Kennzahlen: Stunden pro Woche, Durchlaufzeit, Fehlerquote, Rückfragen. So wird Modernisierung nicht zur IT-Wette, sondern zu einem Business-Case, den Operations verteidigen.
Phase 4: Schnittstellen stabilisieren und Ownership festziehen (laufend, 2-8 Wochen)
Sobald ein neuer Baustein live ist, zeigt sich die Wahrheit: Was passiert bei Ausfällen, Datenkonflikten oder Sonderfällen? Diese Phase entscheidet, ob Sie ein skalierbares Zielbild bauen oder nur mehr Komplexität.
Hier setzen Sie die nicht verhandelbaren Leitplanken:
- Monitoring und Alarmierung für Integrationsjobs
- Datenvalidierung und Dead-Letter-Mechanismen (was passiert mit fehlerhaften Datensätzen?)
- Klare Verantwortlichkeiten: Wer owned welche Schnittstelle, wer entscheidet bei Konflikten?
Gerade in mittelständischen Umgebungen ist das ein Kulturthema: „Die IT“ reicht nicht als Verantwortlicher. Ein Prozessowner aus Operations muss mit im Boot sein, sonst entsteht ein System, das technisch läuft, aber fachlich niemand pflegt.
Phase 5: Kernsystem entkoppeln, nicht „ersetzen“ (2-6 Monate in Etappen)
Viele Entscheider denken bei Modernisierung an Replacement. In der Praxis ist Entkopplung oft der bessere Hebel: Das Legacy-System bleibt zunächst System of Record, aber es verliert die Rolle als Prozess-Orchestrator.
Beispiel: Ein alter Java-Monolith steuert Auftrag, Versand, Rechnung. Statt ihn komplett neu zu bauen, verlagern Sie Workflow und UI schrittweise in neue Services oder eine moderne Web-App. Das Legacy-System wird über definierte Schnittstellen bedient, bis einzelne Domänen wirklich „reif“ für Replacement sind.
Hier lohnt sich ein klarer Domänenschnitt: Versandlogik ist häufig anders als Pricing oder Finance. Wer alles zusammen neu baut, baut zwangsläufig zu groß.
Trade-off: Entkopplung kann kurzfristig mehr Integrationsaufwand bedeuten. Der Gewinn kommt über Stabilität, bessere Änderbarkeit, und die Möglichkeit, einzelne Teile später sauber abzulösen - ohne den Betrieb als Geisel zu nehmen.
Phase 6: Abschalten, konsolidieren, Kosten realisieren (ab Monat 6, wiederkehrend)
Der teuerste Zustand ist „alles doppelt“. Phasenmodernisierung funktioniert nur, wenn Sie auch konsequent stilllegen: alte Masken, alte Jobs, alte Server, alte Lizenzen.
Setzen Sie dafür Abschaltkriterien, die nicht politisch verhandelbar sind: Wenn ein Prozess X seit 8 Wochen vollständig über das neue Modul läuft und die Datenqualität passt, wird der alte Pfad entfernt. Nicht „deaktiviert, falls man ihn nochmal braucht“, sondern wirklich raus.
Das ist der Moment, in dem ROI nicht nur als Zeitersparnis, sondern als echte Kostensenkung sichtbar wird: weniger Wartungsverträge, weniger Sonderwissen, weniger Incident-Risiko.
Was Sie vor Projektstart entscheiden müssen (sonst wird es zäh)
Phasenmodernisierung ist kein Selbstläufer. Drei Entscheidungen machen den Unterschied.
Erstens: Akzeptieren Sie, dass das Zielbild iterativ entsteht. Sie brauchen ein klares Architekturprinzip, aber Sie müssen nicht jede Tabelle des Zielsystems heute definieren.
Zweitens: Legen Sie Messgrößen fest, die Operations ernst nimmt. „Modern“ ist keine Metrik. Besser sind Durchlaufzeiten, manuelle Touchpoints pro Auftrag, Fehlerquoten, und die Zahl der Rückfragen aus Kundenservice.
Drittens: Klären Sie das Betriebsmodell. Wer übernimmt nach Launch? Wer reagiert auf Incidents? Wer pflegt Rollen, Workflows, Stammdatenregeln? Wenn das offen bleibt, wird jedes neue Modul zur Dauerbaustelle.
Typische Fehler in deutschen Modernisierungsprogrammen
Der häufigste Fehler ist der falsche Startpunkt: Man beginnt mit einer Plattformentscheidung, bevor klar ist, welcher Prozess wirklich wehtut. Dann wird ein Tool eingeführt, das zwar „State of the Art“ ist, aber die Engpässe nicht trifft.
Der zweite Fehler ist Schattenarbeit: Neue Systeme werden eingeführt, aber niemand schaltet die alten Pfade ab. Das Ergebnis ist mehr Abstimmung, mehr Datenkonflikte, mehr „welche Zahl stimmt jetzt?“
Der dritte Fehler ist fehlende Verbindlichkeit in der Umsetzung. Wenn Liefergegenstände, Sprint-Ziele und Abnahmekriterien nicht transparent sind, ist Modernisierung plötzlich ein Dauerthema ohne klaren Endpunkt pro Etappe.
Wie wir das als Partner auf ROI und Risiko ausrichten
Wenn wir Modernisierung begleiten, behandeln wir sie wie ein Lieferprogramm mit klaren Etappen: definierter Scope, feste Sprint-Takte, wöchentliche Demos, und ein Betriebsplan ab Tag 1. Für viele Teams ist das der Unterschied zwischen „IT-Projekt“ und „operativer Verbesserung, die wirklich ankommt“.
Moon Software Solutions arbeitet dabei konsequent 100% in-house, ohne Outsourcing. Das reduziert Abstimmungsrisiko und macht Ownership im Betrieb einfacher - weil die Leute, die bauen, auch die Konsequenzen in Produktion verantworten. Mehr Details dazu stehen auf https://moonsoftwaresolutions.com/.
Der pragmatische Test: Ist Ihr Legacy-System ein Risiko - oder nur unbequem?
Nicht jedes alte System muss ersetzt werden. Manche sind stabil und tun ihren Job. Modernisierung lohnt sich dann, wenn mindestens eines dieser Muster zutrifft: Sie verlieren jede Woche spürbar Zeit durch manuelle Übergaben, Änderungen dauern unverhältnismäßig lang, oder der Betrieb hängt an Einzelwissen, das gerade dabei ist zu verschwinden.
Wenn Sie sich wiederfinden, starten Sie klein, aber verbindlich: ein Prozess, ein messbarer Effekt, ein Baustein mit Produktionsqualität. Wer so arbeitet, gewinnt Schritt für Schritt Kontrolle zurück - und macht aus „Legacy“ wieder eine Umgebung, die Wachstum trägt.