Ich übernehme, analysiere und modernisiere — ohne dass Production stehen bleibt. Kein Rewrite wenn es nicht sein muss. Kein Subunternehmer. Dein Team weiß jederzeit, woran ich gerade arbeite.
Ich übernehme, analysiere und modernisiere — ohne dass Production stehen bleibt. Kein Rewrite wenn es nicht sein muss. Kein Subunternehmer. Dein Team weiß jederzeit, woran ich gerade arbeite.
Einmal war Neubau die einzige vernünftige Antwort. Einmal war er es nicht — 28 Jahre, kein Rewrite, kein Feature-Freeze. Den Unterschied erkennst du nur, wenn du den Code kennst.
Projekte über Jahre, nicht Sprints. Immer als Lead. Viele laufen noch, andere habe ich sauber übergeben. Konkrete Zahlen (Last, Nutzer, Transaktionen) sag ich dir gern im Gespräch — die stehen unter NDA.
Die meisten Codebases, die ich übernehme, hat vorher jemand anderes aufgegeben.
Das Ziel ist immer dasselbe: ein System, das morgen noch läuft — ohne dass heute alles stillsteht. Was läuft, lass ich laufen und räume nach und nach auf. Was nicht mehr passt, tausche ich Schritt für Schritt aus, im laufenden Betrieb, mit Tests. Das Werkzeug wähle ich nach dem Problem — nicht nach Gewohnheit.
Seit über 20 Jahren — Banking, Logistik, Retail, öffentlicher Sektor — kenne ich die typischen Muster: warum Legacy-Projekte scheitern, wie Codebases veralten, welche Entscheidungen sich rächen. Ich rede direkt mit deinem Team, stelle die Fragen, die intern niemand gestellt hat — und schreibe Code, der auch nach mir noch lesbar ist.
Wenn wir zusammenarbeiten: Ich frag erst, bevor ich was umbaue. Wenn ich was nicht weiß, sag ich das — statt zu raten. Und ich halte Termine ein, auch wenn die Antwort „nein“ ist.
Alles hier hab ich produktiv im Einsatz — meistens über ein Jahr. Die mit Punkt nutze ich gerade aktiv in einem laufenden Projekt.
Hier schreib ich auf, wo es bei Symfony-Migrationen, Laravel-Updates und PHP Legacy oder WP-Multisite-Übernahmen immer wieder hakt.
Laravel-Upgrades sind mechanisch gut machbar. Der teure Fehler ist nicht die Migration selbst, sondern der Versuch, mehrere Major-Versionen auf einmal zu nehmen. Warum ein Major pro Schritt die einzige sichere Reihenfolge ist, warum die abandoned Packages der eigentliche Blocker sind, und ein Blick darauf, was pro Version typischerweise bricht.
Es gibt nicht die eine Migrationsstrategie, sondern vier brauchbare – jede mit klaren Mindestvoraussetzungen. Wer die falsche wählt, zahlt mit Downtime oder mit einem Projekt, das nach Monat neun niemand mehr anfasst. Die vier im Vergleich, mit Code-Ankern und einem Entscheidungsbaum am Ende.
Die ersten vier Wochen einer Legacy-Übernahme entscheiden über das Mandat, nicht über den Code. Was ich in dieser Zeit anschaue, welche Quick Wins ich tatsächlich ausliefere, welche bewusst nicht, und wie ein Bericht aussieht, den auch die GF liest.
Drei Zeilen reichen: was läuft heute, was soll laufen, ab wann. Ich melde mich innerhalb von zwei Tagen — ehrlich, mit Ja oder Nein.
