Vierundvierzig Artikel, alle zum selben Gegenstand: Systeme, die es schon gibt. PHP, Go, AWS, und dazwischen die Dinge, die keine Technik sind und trotzdem über den Ausgang entscheiden.
Dieser Text ist kein Inhaltsverzeichnis, das steht unten. Er ist der Versuch, das aufzuschreiben, was sich durch alle Artikel gezogen hat, ohne dass es beim Schreiben geplant war. Fünf Sätze sind übrig geblieben.
Der teuerste Teil ist nie der Code
Es fing bei der Frage nach dem Preis an und kam danach in fast jedem Artikel wieder: Zwei Systeme gleicher Größe unterscheiden sich im Aufwand um den Faktor fünf, und der Unterschied liegt nie in der Menge des Codes. Er liegt darin, was es kostet, eine Änderung als richtig nachzuweisen.
Daran hängt mehr, als es zunächst aussieht. Ohne diesen Nachweis ist ein Werkzeug wie Rector auf die Regeln beschränkt, die die Sprache selbst erzwingt. Ohne ihn vervielfacht ein Coding-Agent nicht die Geschwindigkeit, sondern das Risiko. Ohne ihn ist jede Rücknahme von Berechtigungen ein Wagnis, und jede Abschaltung einer Funktion eine Vermutung.
Deshalb ist der Aufbau eines Netzes um die Stelle, die als Nächstes angefasst wird, keine Vorarbeit, die man sich sparen kann, wenn es eilig ist. Sie ist der Teil, der alles andere billiger macht, und der einzige, der nicht wegverhandelbar ist.
Ein Termin schlägt eine Meinung
Der zweite Satz ist keiner über Technik, und er hat in drei Artikeln ganz unterschiedlich ausgesehen.
„Wir sollten mal auf eine neuere Fassung gehen" ist eine Meinung und konkurriert mit Funktionen. „Am 31. Dezember endet die Wartung, der Umstieg braucht drei Monate Vorlauf, wir fangen Ende September an" ist ein Termin und konkurriert mit nichts. Dieselbe Sache, zwei verschiedene Gespräche.
Beim Aufräumen von Berechtigungen war es dieselbe Mechanik: Eine Ausnahme mit Begründung wächst wieder zu, eine Ausnahme mit Datum nicht. Und bei einer Funktion, die niemand mehr braucht, ist die angekündigte Abschaltung zum Datum etwas völlig anderes als dieselbe Abschaltung ohne Ankündigung, obwohl technisch nichts sie unterscheidet.
Wer eine Modernisierung durchbekommen will, verbringt deshalb weniger Zeit damit, sie zu begründen, und mehr damit, sie zu datieren.
Was niemand prüft, hält nicht
Der Satz, der in den Artikeln am häufigsten vorkam, und zwar in Zusammenhängen, die nichts miteinander zu tun haben.
Die Mandantentrennung, die nach drei Monaten eine Behauptung ist, weil kein Test sie nachhält. Die Vier-Angaben-Regel für neue Zwischenspeicher, die ohne eine Stelle, die sie erzwingt, nach zwei Wochen vergessen ist. Die Übergabe, die ohne den einen Test aus einer Präsentation besteht. Der Auftrag an einen Agenten, dessen Grenze sich mitverschiebt, wenn der Agent die Tests ändern darf.
Die Schlussfolgerung daraus ist unangenehm für Dokumente und angenehm für Entwickler: Eine Regel ist so viel wert wie der Mechanismus, der sie prüft. Gibt es keinen, ist sie eine Absichtserklärung, und Absichtserklärungen halten bis zur nächsten knappen Woche.
Kleiner schneiden ist fast immer die Antwort
In den Artikeln, die von gescheiterten Versuchen handelten, war die Ursache erstaunlich oft dieselbe, und es war nie das Werkzeug.
Rector über das ganze Projekt statt über ein Verzeichnis. Beobachtbarkeit flächendeckend statt entlang eines Pfades. Die Ablösung in einem Schritt statt in einer Reihe von Abschnitten mit je einem Ergebnis. Die Berechtigungen in einem Rutsch statt erst das, was nachweislich nie benutzt wurde.
Das Muster dahinter ist immer dasselbe: Die Menge pro Schritt bestimmt, ob ein Fehler zuzuordnen ist. Ist sie klein, ist jede Abweichung erklärbar. Ist sie groß, ist jede Abweichung eine Untersuchung, und nach zwei Tagen wird alles verworfen.
Was dabei entsteht, ist nicht Langsamkeit, sondern das Gegenteil. Zwölf Wochen in sechs Abschnitten mit je einem Ergebnis liefern früher etwas Brauchbares als zwölf Wochen am Stück, und sie überleben eine Unterbrechung.
Wegnehmen ist Modernisierung
Der fünfte Satz war der, der beim Schreiben am meisten überrascht hat, weil er in Artikeln auftauchte, die nichts davon handeln sollten.
Der Zwischenspeicher mit zwei Prozent Trefferquote wird entfernt, nicht dokumentiert. Zwei Dienste, die immer zusammen ausgerollt werden, sind einer und gehören zusammengelegt. Die Funktion, die seit vier Jahren niemand aufruft, kostet in jedem Upgrade und jeder Migration mit. Der alte Pfad nach einer Ablösung gehört in dieselbe Aufgabe wie das Umschalten, nicht in ein Folgeticket.
Jede dieser Entscheidungen macht das System kleiner, und keine davon lässt sich als Fortschritt vorzeigen. Genau deshalb passiert sie nicht von allein: Das Risiko ist einseitig verteilt, und wer wegnimmt, hat seinen Namen an der Entscheidung. Es braucht einen Ablauf, der das aushält, und der besteht aus Messen, Ankündigen, Abschalten, Warten.
Zwei Einschätzungen, die sich beim Schreiben verschoben haben
Wenn man vierundvierzig Artikel über denselben Gegenstand schreibt, verschieben sich ein paar Einschätzungen, und zwei davon gehören hierher.
Die organisatorischen Themen sind nicht das Beiwerk. Ich hatte die Reihe technisch geplant und die Artikel über Zuständigkeit, Übergabe, Termine und Zuschnitt als Auflockerung dazwischengelegt. Beim Schreiben stellte sich heraus, dass die technischen Artikel regelmäßig bei einer organisatorischen Frage endeten: Wer entscheidet, wer prüft, wer bekommt die Meldung. Der Code war selten der Engpass.
Der Unterschied zwischen Werkzeugen und Verfahren ist größer geworden. Beim Schreiben über Rector und über Coding-Agenten am selben Gegenstand wurde deutlich, dass die interessante Frage nie „welches Werkzeug" ist, sondern „was prüft das Ergebnis". Ein deterministisches Werkzeug braucht eine Stichprobe je Regel. Ein nicht deterministisches braucht ein Netz. Die Werkzeuge sind austauschbar, die Frage ist es nicht.
Vier Einstiege, wenn Sie ein konkretes Problem haben
Die Reihe ist nicht zum Durchlesen gedacht. Wer mit einer bestimmten Lage hier ankommt, fängt am besten an einer dieser vier Stellen an.
Das System soll umgebaut werden, und niemand weiß, was es kostet. Dann geht es um die fünf Treiber des Aufwands, um den Zuschnitt in Abschnitte und um die zweite Zahl, die im Gespräch mit der Geschäftsführung fehlt. Der Einstieg dafür ist Was eine Modernisierung kostet.
Es läuft, aber jede Änderung ist teuer. Dann ist die Reihenfolge: feststellen, was überhaupt benutzt wird, ein Netz um die Stelle legen, die als Nächstes drankommt, und erst danach etwas ändern. Der Einstieg dafür ist Legacy-Code testen, wenn es keine Tests gibt.
Der Betrieb ist das Problem, nicht der Code. Dann geht es um Auslieferung, Beobachtbarkeit, Zugriffe und Grenzen, und der billigste Einzelschritt ist fast immer die Auslieferungsfähigkeit. Der Einstieg dafür ist Blue/Green und Canary ohne Kubernetes.
Jemand geht, oder jemand kommt. Dann geht es um Wissen, Zugänge und den einen Test, der sagt, ob eine Übergabe getragen hat. Der Einstieg dafür ist Der Übergabetag.
Wenn Sie vor einer solchen Lage stehen und nicht sicher sind, an welcher Stelle Sie anfangen: Schreiben Sie mir. Zwei Sätze über das System reichen für eine Einschätzung, welche der vier Reihenfolgen bei Ihnen greift.
Alle Artikel der Reihe
Die Reihe hat vier Stränge, die sich abwechseln: Bestand und Umbau, AWS und Betrieb, Backend und Schnitt, sowie die Themen, die keine Technik sind.
- Rector im Altprojekt12. September 2026
- Der Übergabetag12. September 2026
- Blue/Green und Canary ohne Kubernetes12. September 2026
- Mandantenfähigkeit nachrüsten12. September 2026
- Was eine Modernisierung kostet12. September 2026
- Funktionen entfernen, die niemand mehr nutzt12. September 2026
- Ein EOL-Kalender für den ganzen Stack12. September 2026
- Der verteilte Monolith12. September 2026
- IAM aufräumen in einem gewachsenen AWS-Konto12. September 2026
- Testdaten aus der Produktion12. September 2026
- Coding-Agenten im Altsystem12. September 2026
- OpenTelemetry in PHP und Go einführen12. September 2026
- Der Cache als Schuld12. September 2026
- Server-gerenderte Oberflächen modernisieren, ohne SPA12. September 2026
- Zwölf Wochen Modernisierung: ein realistischer Plan12. September 2026
- Backups, die niemand je wiederhergestellt hat12. September 2026
- Konfiguration und Secrets für Go-Services12. September 2026
- Zehn Lücken, die in jedem alten PHP-System stecken12. September 2026
- Eine API vor den Monolithen setzen12. September 2026
- MySQL 5.7 auf 8.0: was beim Umzug bricht12. September 2026
- PHPStan Stufe für Stufe in Altcode einführen12. September 2026
- Modernisieren mit externem Freelancer12. September 2026
- Ein PHP-Monolith auf ECS Fargate12. September 2026
- Von Cronjobs zu Queues12. September 2026
- Wartungsmodus: ein Altsystem sicher weiterbetreiben12. September 2026
- Go lernen als PHP-Entwickler: fünf Denkfehler12. September 2026
- Shopware-5-Plugins bei der Migration auf 612. September 2026
- Dual-Write und Backfill: wo Umstellungen wirklich scheitern12. September 2026
- Wissen in einer Person ist ein Architekturproblem12. September 2026
- Terraform-Drift: wenn Konsole und Code auseinanderlaufen12. September 2026
- Laravel-Upgrades: wo die Fallen anders liegen12. September 2026
- Einen Anti-Corruption Layer zwischen Go und PHP bauen12. September 2026
- Drei Kennzahlen, bevor Sie eine Zeile refaktorieren12. September 2026
- Composer als Archäologie12. September 2026
- Sessions, Uploads, Konfiguration: drei Ketten an den Server12. September 2026
- Feature Flags in einem Monolithen ohne Framework-Support12. September 2026
- Lift-and-Shift oder Replatforming12. September 2026
- Welchen Service Sie zuerst aus dem Monolithen lösen12. September 2026
- Der Business Case für eine Modernisierung12. September 2026
- Symfony-Deprecations abarbeiten, ohne im Log zu ertrinken12. September 2026
- Das eigentliche Legacy ist Ihr Datenbankschema12. September 2026
- Wenn das Deployment noch per FTP läuft12. September 2026
- Legacy-Code testen, wenn es keine Tests gibt12. September 2026
- Technische Due Diligence: ein Altsystem in fünf Tagen prüfen12. September 2026
Die Reihe endet hier, der Gegenstand nicht. Wie ich an gewachsenen Systemen arbeite, steht auf einer eigenen Seite, und wer die nächsten Artikel nicht verpassen will, abonniert den Feed.
