Alle Artikel
12. September 2026
8 mins

Zwölf Wochen Modernisierung: ein realistischer Plan

Von Tim Rutte, Cloud & Software ArchitectThemaLegacy & Modernisierung

Sechs Trittsteine in einer Linie über dunkles Wasser, der letzte ist blau.

Modernisierungsvorhaben werden entweder zu groß geplant oder gar nicht. Zu groß heißt: ein Jahr, ein Ziel am Ende, eine Zahl, die eine Geschäftsführung nicht genehmigt. Gar nicht heißt: Es wird nebenbei aufgeräumt, und nach sechs Monaten ist nichts anders.

Dieser Artikel beschreibt den Zuschnitt, der bei mir am häufigsten funktioniert hat: zwölf Wochen, mit einem Ergebnis nach jedem Abschnitt und einer Entscheidung am Ende. Es ist kein Vorlagenplan für jedes System, sondern eine Reihenfolge und eine Begründung dafür.

Wichtig vorweg: Zwölf Wochen modernisieren kein System. Sie bringen es in einen Zustand, in dem Modernisierung planbar wird, und liefern den ersten echten Umbau als Beleg.

Warum zwölf Wochen

Die Zahl hat zwei Gründe, und beide sind nicht technisch.

Ein Quartal ist die Einheit, in der Unternehmen entscheiden. Ein Vorhaben, das in diesen Rahmen passt, braucht keine Sonderbehandlung. Eines, das darüber hinausgeht, braucht eine Genehmigung über mehrere Zyklen, und dabei geht es verloren.

Nach drei Monaten ist die Ausgangslage eine andere. Menschen wechseln, Prioritäten verschieben sich, ein Wettbewerber tut etwas. Ein Plan über ein Jahr plant gegen eine Welt, die es beim Start des vierten Quartals nicht mehr gibt.

Daraus folgt die Regel, die den ganzen Zuschnitt trägt: Nach zwölf Wochen steht eine Entscheidung an, nicht eine Fortsetzung. Entweder die nächsten zwölf Wochen werden beschlossen, weil das Ergebnis überzeugt, oder das Vorhaben endet mit einem Zustand, der für sich trägt.

Das ist der Unterschied zu einem Plan, der sich über Jahre streckt: Jeder Abschnitt muss so enden, dass ein Abbruch danach kein Schaden ist.

Woche 1 und 2: sehen und zurückkönnen

Der erste Abschnitt fasst keinen Anwendungscode an. Das ist die Entscheidung, die am häufigsten in Frage gestellt wird und die sich am deutlichsten auszahlt.

Drei Dinge entstehen.

Eine Ausgangsmessung. Antwortzeiten als Perzentil an der Außenkante, Fehlerrate getrennt nach erwartet und unerwartet, die Sättigung der Ressource, die zuerst ausgeht. Eine Woche Messung, damit die Rhythmen einmal vollständig darin sind.

Ein Weg auf den Server, der reproduzierbar ist, und ein Rückweg, der einmal gegangen wurde. Wo es schon eine Pipeline gibt, ist das ein halber Tag. Wo Dateien hochgeladen werden, ist es der größte Einzelposten des Abschnitts und der wichtigste.

Eine Umgebung, in der man etwas ausprobieren kann. Mit Daten, die den echten ähneln. Ohne sie ist jede Änderung im weiteren Verlauf ein Eingriff am lebenden Objekt.

Am Ende von Woche zwei ist nichts modernisiert und drei Dinge sind möglich, die vorher nicht gingen: messen, ausrollen, zurückdrehen. Das ist der Zustand, auf dem alles Weitere aufbaut.

Woche 3 und 4: das Netz um die erste Stelle

Jetzt wird entschieden, welcher Teil als Erster umgebaut wird, und zwar nach zwei Kriterien: Er wird häufig geändert, und ein Fehler dort ist ärgerlich, aber nicht existenziell.

Um diesen Teil entsteht ein Netz aus Tests. Nicht im ganzen System, dort. Die Tests halten fest, was das System heute tut, einschließlich der Fehler, denn das ist der Vergleichsmaßstab für alles Weitere.

In diesem Abschnitt fällt regelmäßig der erste unangenehme Fund an: eine Stelle, an der sich das Verhalten nicht festhalten lässt, weil es von Zeit, Zufall oder einem Fremdsystem abhängt. Das ist keine Verzögerung, sondern ein Ergebnis. Es sagt etwas über den Aufwand des Umbaus, und zwar früh genug, um den Zuschnitt zu ändern.

Parallel läuft in diesem Abschnitt die statische Analyse an, mit eingefrorenem Bestand. Das kostet einen halben Tag und wirkt ab dann bei jeder Änderung.

Woche 5 bis 8: der erste echte Umbau

Vier Wochen für den ersten Umbau klingen nach viel. Sie sind es nicht, weil in diesem Abschnitt zwei Dinge gleichzeitig passieren: Der Umbau selbst, und das Lernen des Verfahrens.

Der Umbau wird in zwei Auslieferungen geschnitten, mit einem Schalter dazwischen. Erst läuft der neue Weg für interne Nutzer, dann für einen Teil, dann für alle. Wer das für übertrieben hält, hat den Zweck missverstanden: Es geht nicht um dieses eine Feature, sondern darum, dass das Team danach weiß, wie man so etwas macht.

Zum Abschnitt gehört ein Messpunkt: Die Zahlen aus Woche eins werden erneut erhoben. Was besser geworden ist, steht damit fest, und was schlechter geworden ist, auch. Beides wird aufgeschrieben, weil die Entscheidung am Ende darauf beruht.

Und eine Regel, die diesen Abschnitt schützt: Der Umfang wächst nicht. Was beim Umbau auffällt und nicht dazugehört, kommt auf eine Liste. Die Liste ist ein Ergebnis des Vorhabens, nicht seine Erweiterung.

Woche 9 und 10: der zweite Umbau, vom Team

Dieser Abschnitt ist der eigentliche Test des ganzen Vorhabens, und er wird am häufigsten gestrichen, wenn es eng wird.

Der zweite Umbau macht das Team. Wer vorher gebaut hat, liest den Änderungssatz und beantwortet Fragen. Das kostet Tempo, und zwar spürbar: Zwei Wochen für etwas, das in vier Tagen fertig wäre.

Was man dafür bekommt, ist die Antwort auf die einzige Frage, die nach zwölf Wochen wirklich zählt: Kann das Team allein weitermachen? Ohne diesen Abschnitt ist die Antwort eine Hoffnung.

Der Zeitpunkt ist bewusst nicht am Ende. Wer den Übergang in die letzten zwei Wochen legt, hat keine Zeit mehr, auf das zu reagieren, was dabei auffällt.

Woche 11 und 12: der Puffer, und was er wirklich ist

Zwei Wochen ohne Inhalt sehen in einem Plan nach Verschwendung aus, und in jeder Verhandlung wird zuerst dort gekürzt. Sie sind der Grund, warum dieser Zuschnitt hält.

In der Praxis füllen sich diese zwei Wochen immer, und zwar mit drei Dingen.

Dem, was in Woche 5 bis 8 länger gedauert hat. In fast jedem Vorhaben gibt es einen Fund, der eine Woche kostet. Ohne Puffer verschiebt er alles Nachfolgende, und als Erstes fällt Woche 9 und 10.

Dem Aufräumen. Die Schalter aus dem ersten Umbau werden entfernt, der alte Weg wird gelöscht. Das ist der Teil, der als eigenes Ticket nie gemacht wird und der entscheidet, ob das System danach einfacher ist oder komplizierter.

Der Entscheidungsvorlage. Was gemessen wurde, was das gekostet hat, was als Nächstes anstünde und was es voraussichtlich kostet. Zwei Seiten, mit Zahlen aus dem eigenen Haus.

Wer den Puffer streicht, streicht in der Reihenfolge dieser drei Punkte von unten. Am Ende steht ein Vorhaben ohne Beleg und ein System mit doppelten Wegen.

Woraus sich der Preis dieser zwölf Wochen ergibt, steht in Was eine Modernisierung kostet.

Die Stelle, an der jeder Plan reißt

In den Vorhaben, die ich begleitet habe, ist es immer dieselbe Stelle, und sie liegt nicht in der Technik: Das Team ist nicht so verfügbar wie geplant.

Der Ablauf ist vorhersehbar. Zugesagt sind fünfzig Prozent der Zeit von zwei Personen. In Woche drei kommt ein Vorfall, in Woche fünf eine dringende Anforderung aus dem Vertrieb, in Woche sieben ist jemand krank. Am Ende waren es zwanzig Prozent, und der Plan war auf fünfzig gerechnet.

Drei Dinge helfen dagegen, und alle drei sind vorab zu klären.

Feste Tage statt Prozente. „Dienstag und Mittwoch arbeitet Frau K. am Vorhaben" ist durchsetzbar. „Fünfzig Prozent" ist es nicht, weil der Anteil immer der ist, der übrig bleibt.

Eine benannte Vertretung für das Tagesgeschäft. Ohne sie ist jeder Vorfall eine Unterbrechung des Vorhabens.

Ein wöchentlicher Blick auf die tatsächliche Zeit. Nicht als Kontrolle, sondern als Frühwarnung: Wenn in Woche drei sichtbar ist, dass es zwanzig Prozent sind, lässt sich der Zuschnitt anpassen. In Woche neun nicht mehr.

Der dritte Punkt ist der, der am seltensten gemacht wird und am billigsten ist.

Wie die Arbeitsteilung mit einem Externen dabei aussieht, steht in Modernisieren mit externem Freelancer.

Was nach zwölf Wochen dasteht

Am Ende steht kein modernisiertes System. Es steht ein System, an dem Modernisierung möglich ist, und der Unterschied lässt sich benennen.

  • Zahlen statt Gefühl. Antwortzeiten, Fehlerraten und Durchlaufzeit vorher und nachher, aus dem eigenen Haus.
  • Ein Weg, Änderungen auszuliefern und zurückzudrehen, geübt statt beschrieben.
  • Ein Netz aus Tests um den Teil, an dem gearbeitet wird, und eine Analyse, die jede neue Zeile prüft.
  • Zwei durchgeführte Umbauten, von denen der zweite vom Team kam.
  • Eine Liste dessen, was auffiel und nicht dazugehörte, mit Einschätzung.

Mit diesen fünf Punkten ist die Entscheidung über die nächsten zwölf Wochen eine andere: Sie beruht auf Erfahrung mit diesem System und diesem Team, nicht auf einer Schätzung. Und wenn sie negativ ausfällt, bleibt ein System zurück, das sich besser betreiben lässt als vorher.

Was diese zwölf Wochen ungefähr kosten und wie man sie gegen den Zustand ohne sie rechnet, gehört in die Vorlage aus Woche elf. Warum der große Wurf am Stück fast immer scheitert, steht in einem eigenen Artikel, und dieser Zuschnitt ist die Antwort darauf.

Wie ich solche Vorhaben schneide und begleite, steht auf einer eigenen Seite.

Dieser Artikel gehört zu einer Reihe über Systeme, die es schon gibt. Der Rückblick ordnet alle Artikel der Reihe nach Anlass.