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.
Eine aktuelle Framework-Version ist kein Qualitätssiegel. Ein gewachsenes Laravel ohne Tests ist genauso Legacy wie prozeduraler Alt-PHP-Code, die Fassade täuscht nur besser. Was ich in den ersten Wochen einer Laravel-Übernahme anschaue, warum das Sicherheitsnetz vor allem anderen kommt, und ein Feature-Test, der das Ist-Verhalten festhält, bevor jemand refactort.
Der Rewrite-Reflex ist oft eine Flucht vor Komplexität, keine technische Notwendigkeit. Es gibt drei Konstellationen, in denen Neubau trotzdem trägt – und die haben nichts mit 'der Code ist hässlich' zu tun. Meine drei Fragen und ein Diff aus einem Fall, der fast neu gebaut worden wäre.
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.
Drei Zeilen reichen: was läuft heute, was soll laufen, ab wann. Ich melde mich innerhalb von zwei Tagen — ehrlich, mit Ja oder Nein.
