Legacy-Code-Refactoring als Dienstleistung: Was Du bekommst, was es kostet und wie Du einen Partner bewertest
Wenn Deine PHP-Anwendung auf einer Framework-Version von 2014 läuft oder Dein React-Frontend drei Schichten widersprüchlicher State-Management-Bibliotheken angesammelt hat, erreichst Du irgendwann den Punkt, an dem Flicken teurer wird als die Struktur neu zu denken. Dann beginnen Unternehmen, nach Legacy-Code-Refactoring-Dienstleistungen zu suchen - und dann passieren auch viele Fehler.
In diesem Beitrag geht es nicht darum, ob Du refactoren solltest. Es geht darum, was tatsächlich passiert, wenn Du jemanden dafür beauftragst: wie die Arbeit strukturiert ist, was Du im europäischen Markt für PHP/Symfony- und React-Codebasen erwarten solltest und woran Du einen kompetenten Partner von einem erkennst, der Dich schlechter zurücklässt als vorher.
Was Legacy-Code-Refactoring-Dienstleistungen tatsächlich liefern
Ein seriöses Legacy-Code-Optimierungsprojekt beginnt nicht mit dem Schreiben von Code. Es beginnt damit zu verstehen, warum der Code so ist, wie er ist - und das erfordert strukturierte Discovery.
Phase 1: Discovery und Baseline-Messung
Die ersten zwei bis vier Wochen dienen dazu, ein gemeinsames Verständnis der Codebasis aufzubauen. Ein seriöser Partner instrumentiert Deine Anwendung, um messbare Baselines zu etablieren: Testabdeckung in Prozent, zyklomatische Komplexität pro Modul, Antwortzeiten wichtiger Endpoints und Deployment-Frequenz. Ohne diese Zahlen ist jede Behauptung über "verbesserte Codequalität" nach dem Projekt bedeutungslos.
Während der Discovery solltest Du außerdem ein Dependency-Audit erwarten. Es identifiziert veraltete Bibliotheken, nicht mehr gepflegte Pakete und Sicherheitslücken - oft die dringendsten Punkte in einem Legacy-PHP- oder Symfony-Projekt.
Was Du am Ende dieser Phase bekommst: eine schriftliche Bewertung, die die riskantesten Teile der Codebasis kartiert, quantifiziert mit den Metriken oben, plus eine priorisierte Liste der Handlungsfelder.
Phase 2: Priorisierter Arbeitsplan
Nicht alles in einer Legacy-Codebasis braucht Refactoring. Der Großteil des Werts entsteht durch die Bearbeitung einer relativ kleinen Zahl stark frequentierter, risikoreicher Module. Ein guter Partner hilft Dir bei der Triage: Welche Teile des Systems werden bei jedem Deployment angefasst, welche verursachen die meisten Produktionsvorfälle und welche sind stabil genug, um sie in Ruhe zu lassen.
Der Arbeitsplan sollte definieren, was refactored wird, in welcher Reihenfolge und wie der Fortschritt verifiziert wird. Wenn ein Partner Dir vor Arbeitsbeginn nicht sagen kann, wie "fertig" für jedes Modul aussieht, ist das ein Problem.
Phase 3: Parallele Umsetzung
Das Refactoring selbst läuft parallel zu Deiner bestehenden Entwicklungsarbeit. Das Schlüsselwort ist "parallel" - ein professionelles Projekt friert Deine Roadmap nicht ein. Die Arbeit erfolgt in kleinen, reviewbaren Paketen, jedes vor dem Merge durch Tests validiert. Wenn der Partner einen Branch drei Monate übernehmen und Dir ein fertiges Produkt zurückgeben will, frag ihn nach seinem Rollback-Plan. Hat er keinen, geh.
Bei PHP/Symfony-Projekten umfasst diese Phase typischerweise Dependency-Upgrades, die Einführung von Type Hints und Return Types für die statische Analyse in modernem PHP, das Ersetzen prozeduraler Blöcke durch Service-Klassen und Integrationstests rund um die riskanteste Geschäftslogik. React-Refactoring konzentriert sich meist auf die Konsolidierung des State Managements, das Ersetzen von Klassenkomponenten, das Aufteilen überdimensionierter Dateien in fokussierte Module und konsistente Data-Fetching-Muster.
Phase 4: Übergabe und Wissenstransfer
Am Ende des Projekts solltest Du das Ergebnis besitzen. Das heißt: dokumentierte Entscheidungen (warum eine bestimmte Architekturentscheidung getroffen wurde, welche Alternativen erwogen wurden), aktualisierte README-Dateien und mindestens eine Session, in der der Partner Dein Team durch die Änderungen führt und erklärt, warum. Projekte, die mit einer ZIP-Datei und einem Abschiedscall enden, zählen nicht.
Was Legacy-Code-Refactoring-Dienstleistungen in der EU kosten
Kosten sind die Frage, die die meisten vermeiden, direkt zu stellen - weshalb sie oft überrascht sind, wenn die Angebote kommen. Hier ist ein realistisches Bild des EU-Markts für 2025 und 2026.
Unabhängige Berater und kleine spezialisierte Studios in Westeuropa verlangen für Senior-Level-Refactoring an PHP/Symfony- oder React-Codebasen typischerweise zwischen 120 und 200 EUR pro Stunde. Osteuropäische Teams, die mit westeuropäischen Kunden arbeiten, liegen meist im Bereich von 60 bis 100 EUR, wobei das untere Ende Agenturen und das obere Ende erfahrene Einzelberater repräsentiert.
Für ein sauber umrissenes Projekt an einer mittelgroßen PHP/Symfony-Anwendung - vier bis acht Jahre in Produktion, zwischen 50.000 und 200.000 Zeilen Code, definierter Scope über zwei bis vier Kernmodule - solltest Du für die Refactoring-Arbeit selbst zwischen 15.000 und 45.000 EUR budgetieren, ohne die Discovery-Phase.
Die Discovery-Phase ist typischerweise ein Festpreisposten im Bereich von 3.000 bis 8.000 EUR. Sie sollte separat bepreist und geliefert werden. Bündelt ein Partner die Discovery in einen großen Vorabvertrag, verlierst Du die Möglichkeit, auf Basis dessen, was tatsächlich in der Codebasis steckt, informiert über das weitere Vorgehen zu entscheiden.
Größere Projekte, die eine vollständige Anwendungsmodernisierung abdecken - Migration von PHP 7 auf PHP 8, Update einer Symfony-3-Anwendung auf Symfony 7 oder Restrukturierung einer React-Anwendung, die durch drei verschiedene Teams gegangen ist - können 80.000 bis 180.000 EUR erreichen und laufen typischerweise sechs bis zwölf Monate.
Diese Zahlen gehen davon aus, dass der Partner mit Deinem Team arbeitet, nicht es ersetzt. Soll der Partner während des Projekts zusätzlich die Feature-Entwicklung übernehmen, steigen Scope und Kosten entsprechend.
Fragen, die Du vor der Unterschrift stellen solltest
Die Fragen unten dienen nicht dazu, unehrliche Partner auszusieben. Die meisten Projekte scheitern aus banalen Gründen: unterschiedliche Erwartungen, unklarer Scope oder nicht zusammenpassende Arbeitsweisen. Diese Fragen bringen solche Diskrepanzen früh an die Oberfläche.
Wie messt ihr Fortschritt? Du willst konkrete Metriken hören - Delta der Testabdeckung, Reduktion der Komplexitätswerte, Deployment-Frequenz vorher und nachher. Vage Antworten über "saubereren Code" oder "bessere Architektur" reichen nicht.
Was ist euer Rollback-Plan, wenn in Produktion etwas kaputtgeht? Refactoring birgt Risiken. Ein professioneller Partner hat eine konkrete Antwort: Feature Flags, Blue-Green-Deployment, branchbasierte Lieferung mit expliziten Merge-Kriterien. Lautet die Antwort "wir testen sorgfältig", hak nach.
Arbeitet ihr auf der Live-Produktion oder auf einem separaten Branch? Die Antwort sollte ein separater Branch mit klar definierten Merge-Kriterien sein. Jeder Partner, der ohne Review-Prozess direkten Push-Zugriff auf Deine Produktionsumgebung will, ist ein Risiko.
Wie sieht die Übergabe aus? Du musst Konkretes hören: Dokumentation, Wissenstransfer-Sessions, Anforderungen an die Testabdeckung vor dem Abschluss.
Könnt ihr mir eine Codebasis zeigen, die ihr refactored habt, und mich durch einen Vorher-Nachher-Vergleich führen? Die Antwort verrät viel. Ein Partner, der das schon gemacht hat, kann konkrete Entscheidungen beschreiben und begründen. Einer, der es nicht getan hat, gibt Dir eine generische Antwort.
Warnsignale, die Du ernst nehmen solltest
Ein Festpreisvertrag für das gesamte Projekt, bevor die Discovery abgeschlossen ist. Das ist der häufigste Grund, warum Refactoring-Projekte schiefgehen. Niemand kann sechs Monate Arbeit an einer Codebasis akkurat schätzen, die noch nicht analysiert wurde. Festpreis vor der Discovery heißt: Jemand rät - und der Anreiz ist, zu den eigenen Gunsten zu raten.
Versprechen von null Störung für Dein bestehendes Team. Refactoring braucht Zugang zu Deinen Entwicklern für Kontext, Code Reviews und Entscheidungen zur Geschäftslogik. Ein Projekt, das verspricht, für Dein Team komplett unsichtbar zu sein, produziert Änderungen, die Dein Team nicht versteht und nicht warten kann.
Keine Erwähnung von Tests. Jedes Refactoring, das Testabdeckung nicht als explizites Liefergebnis enthält, ist eine Hypothek. Ohne Tests hast Du keine Möglichkeit zu verifizieren, dass sich der refactorte Code genauso verhält wie das Original.
Fehlende Vertrautheit mit Deinem konkreten Stack. Allgemeine Softwareentwicklungs-Skills übertragen sich nicht automatisch auf Legacy-Symfony-Refactoring oder React-Modernisierung. Frag nach Beispielen. Hat ein Partner nie mit Deiner Framework-Version gearbeitet, verbrennt er Dein Budget beim Lernen.
Der Einstieg
Wenn Deine Codebasis Dich ausbremst und Du eine ehrliche Einschätzung willst, was die Behebung kosten würde, ist der erste Schritt eine strukturierte Discovery - kein Angebot.
Bei Wolf-Tech arbeiten wir mit Teams an Legacy-Code-Optimierungsprojekten, die mit Messung beginnen und mit Code enden, den Dein Team warten kann. Wenn Du konkrete Fragen hast, wie ein Projekt mit Deinem Stack und Deiner Codebasis-Größe aussehen könnte, melde Dich unter hello@wolf-tech.io oder besuche wolf-tech.io.