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.
PHPStan auf hoher Stufe gegen alten Code zu werfen, erzeugt eine Fehlerwand, die niemand abarbeitet. Der Weg, der trägt, ist umgekehrt: niedrig anfangen, den Ist-Zustand als Baseline einfrieren, die Pipeline sofort grün bekommen und erst dann Stufe für Stufe schärfer werden. Mein Vorgehen bei der Übernahme, mit Config und CI-Schritt.
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.
Drei Zeilen reichen: was läuft heute, was soll laufen, ab wann. Ich melde mich innerhalb von zwei Tagen — ehrlich, mit Ja oder Nein.
