Kernsystem-Migration ohne Big Bang: Strangler und Parallel Run
Der Albtraum jedes IT-Leiters: Freitag abends wird das alte ERP ausgeschaltet, Montag morgens die neue eingeschaltet. Der ganze Betrieb hängt vom Erfolg eines Wochenendes ab. Wenn der Datentransfer fehlschlägt, wenn irgendein Geschäftsprozess nicht funktioniert – dann steht Produktion, Verkauf, Buchhaltung still. Das ist Big Bang, und es gehört in den Albtraum-Ordner. Dennoch sehen viele Mittelständler keine Alternative. Es gibt sie aber.
Drei bewährte Strategien vermeiden Big-Bang-Ausfälle: Strangler-Pattern (6-9 Monate, minimal Risiko), Parallel Run (4-6 Monate, einfach durchzuführen), Progressive Throughput (3-4 Monate, höchste Überwachung). Alle verteilen Migrations-Risiko über Wochen statt auf ein Wochenende zu konzentrieren.
Strategie 1: Strangler-Pattern – Piece by Piece Replacement
Das alte System wird wie von einer Kletterpflanze umwachsen, Stück für Stück von außen. Eine Funktion wird identifiziert, die ablöst werden kann. Das neue System baut diese Funktion. Ein Proxy/Router leitet dann: Kommt das von Funktion X? → Route zum neuen System. Alles andere → Route zum alten System.
Praktisches Beispiel – Maschinenbauer mit 290 Mitarbeitern: Altes SAP mit fünf Modulen. Phase 1 (Woche 1-6): Qualitätskontrolle-Modul (stabil, wenig Abhängigkeiten). Ein Router registriert: Alle QC-Anfragen → neues System. Nach 5 Wochen: Nur noch neues System für QC. Phase 2 (Woche 7-15): Lagerbestände migrieren. Phase 3-5: Bestellung, Rechnungswesen, Personalverwaltung. Gesamtdauer: 6 Monate. Kein Tag, an dem die ganze Fabrik stillsteht.
Strategie 2: Parallel Run mit Cutover-Punkt
Das neue System wird voll aufgebaut. Das alte System läuft weiter, wird aber redundant mit dem neuen gefüttert. Jede neue Bestellung, jeder neue Kunde – beide Systeme erhalten Daten. Nach 4-8 Wochen: Abgleich aller Daten. Welche Unterschiede gibt es? Bugs werden behoben. Dann: Cutover-Punkt am Wochenende.
Fallbeispiel – Kunststoffhersteller mit 520 Mitarbeitern: Parallel-Run Monat 3-4. Ein Jobflow schreibt jede neue Bestellung ins alte und neue System. Ein Script vergleicht täglich: Unterschiede? Die meisten Tage: < 0,5% OK. Woche 3: Bug im Lagerlogik-Modul erzeugt 5% Unterschiede. Wird behoben. Woche 4: Beide identisch. Wochenende 5: Cutover. Alte Maschine um 20 Uhr freitag ab. Neue läuft Tests durch (Stunden 0-3 nachts). 5 Uhr morgens: Produktion startet. Resultat: 9 Stunden Downtime über Nacht.
Strategie 3: Progressive Throughput – Gradueller Durchsatz
Das neue System lädt erst 10% der Transaktionen, nach 1 Woche 25%, nach 2 Wochen 50%, nach 3 Wochen 100%. Die Quote wird kontinuierlich hochgefahren, Fehlerquoten überwacht. Wenn Fehlerrate über Schwelle steigt, wird Quote einen Tag heruntergefahren.
Fallbeispiel – Großhändler mit 420 Mitarbeitern: Woche 1 (10% neuer Bestellungen im neuen System): Fehlerquote 0,3%. Woche 2 (30%): Fehlerquote 0,8%. Woche 3 (60%): Fehlerquote 1,2% (über Schwelle, halt). Zurück auf 45% für 2 Tage. Bug gefunden, fixed. Woche 4: 100% im neuen System. Gesamte Umstellung: Zero ungeplante Ausfallzeiten.
Häufige Fragen
Welche Strategie ist am schnellsten?
Progressive Throughput, wenn Infrastruktur es erlaubt: 3-4 Monate. Strangler dauert 6-9 Monate, aber mit weniger technischer Komplexität.
Kann man zwei Strategien kombinieren?
Ja, und das ist oft optimal. Strangler für einfache Module (QC, HR), Parallel Run für kritische Module (Bestandsverwaltung, Finanz).
Wie überwacht man Konsistenz zwischen Systemen?
Mit automatisierten Abgleich-Skripten. Nach jeder Transaktion wird in beiden Systemen geprüft. Unterschiede werden gemeldet.
Welche Strategie für produzierende Betriebe?
Strangler-Pattern für Produktion mit kurzen Wochenend-Umschaltungen pro Modul. Progressive Throughput braucht zu viel Monitoring bei kritischen Prozessen.
Wie viel KI kostet die Infrastruktur für die Migration?
Planen Sie parallel KI-Integration in neue Systeme ein – rechnen Sie die Kosten mit unserem Tool.
Migrations-Kosten planen →Vom Pilot in den Regelbetrieb: Hosting, Berechtigungen und Rollout je Abteilung stehen auf der Seite KI-Implementierung.
Ein Problemfeld, mehrere Blickwinkel, alle enden in derselben Rechnung: dem LLM-Kostenrechner.
- Open-Source-KI-Modelle: vier Lizenzklauseln vor dem Einsatz
- VRAM-Rechnung: welche GPU für welches KI-Modell
- Quantisierung: was 4 Bit an Genauigkeit kosten
- Lokale KI vs. API: ab wann sich eigene Hardware rechnet
- Datenhoheit bei KI: vier Betriebsformen im Vergleich
- Legacy modernisieren ohne Neustart: Hybrid-Ansätze
