Legacy-Modernisierung ohne Betriebsunterbruch

Das Altsystem ist selten ein technisches Problem. Es ist ein Risikoproblem: Es funktioniert, das Geschäft hängt daran, und niemand traut sich, es anzufassen.

Die Versuchung ist die Neuentwicklung — parallel bauen, an einem Wochenende umstellen. Das ist der Ansatz mit der höchsten Ausfallquote, aus einem nachvollziehbaren Grund: Er verlangt, dass Sie alles Verhalten des alten Systems kennen, bevor Sie es ersetzen. Das wissen Sie nie vollständig. Das Wissen steckt in Sonderfällen, die vor Jahren jemand eingebaut hat, der nicht mehr im Unternehmen ist.

Sieben Grundsätze für den anderen Weg.

Grundsatz 1 — Betriebskontinuität steht über Technologieersatz

Die Zielfrage lautet nicht «Wie ersetzen wir dieses System?», sondern «Wie liefern wir Verbesserungen, ohne den Betrieb zu unterbrechen?».

Das klingt nach einer Nuance und verändert jede Folgeentscheidung. Es schliesst den grossen Umstellungstermin aus, verlangt Umkehrbarkeit auf jeder Etappe und macht Teilergebnisse wertvoll statt unvollständig.

Grundsatz 2 — Nach Fähigkeiten schneiden, nicht nach Technik

Zerlegt wird nicht in «Datenbankschicht», «Oberfläche», «Schnittstellen». Zerlegt wird in fachliche Fähigkeiten: Offerten erstellen, Bestellungen erfassen, Rechnungen stellen.

Der Grund ist praktisch. Eine Fähigkeit lässt sich einzeln ablösen und einzeln zurücknehmen. Eine technische Schicht nicht — sie hängt an allem.

Diese Sicht zeigt ausserdem, was sich gar nicht lohnt. In den meisten Altsystemen gibt es Funktionen, die seit Jahren niemand nutzt. Sie zu migrieren ist Aufwand ohne Gegenwert, und sie zu finden ist einer der schnellsten Gewinne einer Bestandsaufnahme.

Grundsatz 3 — Schrittweise ablösen, nicht umschalten

Das bewährte Muster ist die schrittweise Ablösung nach dem Strangler-Fig-Prinzip: Eine Weiche vor das Altsystem setzen, eine Fähigkeit nach der anderen neu bauen, den Verkehr dafür umleiten, den alten Teil erst dann abschalten.

Was das in der Praxis bringt:

• Jede Etappe ist umkehrbar. Geht etwas schief, leiten Sie den Verkehr zurück. Der Rückfall dauert Minuten, nicht ein Wochenende.
• Der Nutzen kommt früh. Die erste abgelöste Fähigkeit ist nach Wochen produktiv, nicht nach Abschluss des Gesamtprojekts.
• Das Wissen wächst mit. Jede Etappe deckt Verhalten auf, das in keiner Dokumentation stand — und zwar in einem Umfang, den Sie noch beherrschen.

Der Preis ist ein Zeitraum, in dem beide Systeme laufen. Das ist real und es ist einzuplanen. Es ist der Preis dafür, dass der Betrieb nicht stillsteht.

Genau so sind wir beim Palisis Backoffice vorgegangen: Das Google-Web-Toolkit-Frontend und sein Angular-Nachfolger liefen gleichzeitig in Produktion, Modul für Modul, bis die letzte GWT-Maske verschwunden war. Wie diese Migration geschnitten wurde.

Grundsatz 4 — Monolith zu Microservices nur mit Disziplin

Modernisierung wird oft mit Microservices gleichgesetzt. Das ist eine Entscheidung, keine Zwangsläufigkeit.

Microservices lösen ein organisatorisches Problem: mehrere Teams, die unabhängig ausliefern wollen. Haben Sie ein Team, kaufen Sie sich verteilte Systeme ein, ohne das Problem zu haben, das sie lösen.

Für viele KMU ist ein gut geschnittener modularer Monolith der bessere Zielzustand — eine saubere Struktur, eine Auslieferung, eine Datenbank. Er lässt sich später aufteilen, wenn ein echter Grund entsteht.

Grundsatz 5 — Datenintegrität und Nachweisbarkeit schützen

Bei einer schrittweisen Ablösung schreiben zeitweise zwei Systeme auf dieselben Daten. Das ist der Punkt, an dem stille Fehler entstehen.

Drei Regeln, die das beherrschbar halten:

• Pro Datenbereich gibt es genau ein führendes System. Zu jedem Zeitpunkt, ohne Ausnahme.
• Der Abgleich läuft automatisiert und wird protokolliert. Nicht als Stichprobe, sondern als laufender Vergleich mit Alarm bei Abweichung.
• Aufbewahrungs- und Löschfristen wandern mit. Was unter revDSG/nDSG und DSGVO für das Altsystem galt, gilt ab Tag eins für das neue.

Bei regulierten Datenbeständen — im Gesundheitswesen, im Finanzsektor — gehört der Prüfpfad zur Migration selbst dokumentiert, nicht nur zum Ergebnis.

Grundsatz 6 — Tests, Auslieferung und Rückfall automatisieren

Umkehrbarkeit ist nur dann eine Eigenschaft, wenn sie ohne Heldentum funktioniert. Das heisst: automatisierte Tests, die vor dem Umleiten laufen, eine automatisierte Auslieferung und ein Rückfall, der ein Kommando ist und kein Verfahren.

Der Aufwand dafür fällt einmal an und trägt über jede Etappe. Wer ihn spart, bezahlt ihn bei jeder Umstellung erneut — und irgendwann einmal sehr teuer.

Grundsatz 7 — An Geschäftskennzahlen messen

Technische Kennzahlen belegen nicht, dass die Modernisierung etwas gebracht hat. «Code-Abdeckung erhöht» beantwortet keine Frage, die die Geschäftsleitung gestellt hat.

Belastbar ist, was das Geschäft spürt: Durchlaufzeit eines Vorgangs, Anzahl manueller Korrekturen pro Monat, Zeit bis zur Auslieferung einer Änderung, Ausfallstunden.

Diese Werte gehören vor der ersten Etappe gemessen. Danach lassen sie sich nicht rekonstruieren.

Wie ein Vorhaben typischerweise aufgebaut ist

Bestandsaufnahme. Fähigkeiten kartieren, Nutzung messen, Ungenutztes identifizieren, Ausgangswerte erfassen.

Erste Etappe. Eine Fähigkeit wählen, die sichtbar ist und begrenzt vernetzt. Weiche setzen, neu bauen, umleiten, beobachten.

Serie. Nach Geschäftswirkung geordnet weiterarbeiten. Die Automatisierung aus der ersten Etappe trägt die folgenden.

Abschaltung. Den alten Teil erst entfernen, wenn er nachweislich keinen Verkehr mehr erhält — nicht, wenn angenommen wird, dass er keinen mehr erhält.

Wie wir das begleiten, steht unter Modernisierung. Verwandte Themen: Cloud-Migration: 10 Fehler, die KMU immer noch machen.

Wenn Sie ein Altsystem haben, das läuft und niemand anfassen will, vereinbaren Sie ein Gespräch — unverbindlich, und mit einer konkreten Einschätzung der ersten Etappe.