Laravel-Agentur wechseln: So übernimmt ein neues Team dein Projekt

Eine Laravel-Agentur zu wechseln ist kein Neuanfang – es ist eine Übergabe. Ein neues Team liest sich in den bestehenden Code ein, prüft in einem Audit Zustand, Versionen und Abhängigkeiten, übernimmt Zugänge und Deployment, und arbeitet ab da an deiner Anwendung weiter. Bei einem gepflegten Projekt dauert diese Einarbeitung wenige Tage, bei einem verwahrlosten ein bis zwei Wochen. Deine Anwendung muss dafür nicht angehalten und schon gar nicht neu gebaut werden.

Trotzdem ist es die Entscheidung, vor der die meisten Unternehmer am längsten zögern. Weil sie Angst haben, dass „der Neue" alles schlechtredet und einen Rewrite verkaufen will. Diese Angst ist berechtigt – deshalb schreiben wir hier auf, wie eine seriöse Übernahme wirklich abläuft.

Woran du merkst, dass der Wechsel überfällig ist

In den Projekten, die bei uns landen, sind es fast immer dieselben Muster. Wenn du dich in zwei oder mehr davon wiedererkennst, ist der Wechsel kein Übersprungsverhalten, sondern eine betriebswirtschaftliche Notwendigkeit:

• Es antwortet niemand mehr. Der Freelancer meldet sich nach drei Tagen, die Agentur schiebt jeden Termin. Bei einem produktiven System, das dein Tagesgeschäft trägt, ist das ein Ausfallrisiko.
• Kleinigkeiten dauern Wochen. Ein zusätzliches Feld in einem Formular ist ein Halbtagesjob. Wenn daraus ein Ticket wird, das einen Monat liegt, stimmt entweder die Priorisierung oder die Codebasis nicht.
• Du bekommst keine Aufwände genannt, nur Rechnungen. Seriös ist: vorher grob schätzen, hinterher abrechnen. Wenn du systematisch überrascht wirst, fehlt Transparenz.
• Es gibt genau einen Menschen, der das System versteht. Das ist der gefährlichste Zustand überhaupt – dazu unten mehr.
• Die Laravel-Version ist Jahre alt. Läuft dein Projekt noch auf Laravel 8 oder 9 mit PHP 7.4, bekommst du keine Sicherheitsupdates mehr. Jeder Monat macht das Update teurer.
• Niemand traut sich mehr, etwas zu deployen. Wenn ein Release ein Ritual mit Bauchschmerzen ist, fehlen Tests und ein automatisiertes Deployment.
• Du kommst an deine eigenen Zugänge nicht ran. Server, Repository, Domain, Datenbank – wenn das alles beim Dienstleister liegt und du keinen Admin-Zugriff hast, gehört dir dein Produkt faktisch nur halb.

Der letzte Punkt ist der, bei dem wir am häufigsten hellhörig werden. Alles andere lässt sich reparieren. Fehlende Zugänge sind eine Machtfrage, keine technische.

Was ein seriöses Übernahme-Audit prüft

Bevor irgendjemand eine Zeile Code anfasst, gehört ein Audit an den Anfang. Es beantwortet genau eine Frage: In welchem Zustand ist dieses Projekt wirklich – und was kostet es, es weiterzuführen? Das sind die Punkte, die wir dabei durchgehen:

1. Laravel- und PHP-Version. Welche Version läuft, wird sie noch mit Sicherheitsupdates versorgt, wie groß ist der Sprung auf eine aktuelle Version? Laravel veröffentlicht jährlich eine Hauptversion; Bugfixes und Security-Patches sind zeitlich begrenzt. Ein Projekt zwei Versionen hinterher ist normal, fünf Versionen hinterher ist ein eigenes Projekt.

2. Abhängigkeiten. Ein Blick in composer.json und package.json verrät mehr über den Projektzustand als jede Präsentation. Wie viele Pakete sind verwaist, also seit Jahren nicht mehr gepflegt? Gibt es bekannte Sicherheitslücken? Wurden Pakete aus dem Vendor-Verzeichnis heraus gepatcht – ein Muster, das jedes Update sprengt?

3. Code-Qualität und Struktur. Nicht „schön oder hässlich", sondern: Folgt der Code den Laravel-Konventionen? Steckt Geschäftslogik in 2.000-Zeilen-Controllern? Gibt es N+1-Query-Probleme, die die Anwendung unter Last ausbremsen? Sind Migrations vollständig, sodass sich die Datenbank aus dem Repository heraus aufbauen lässt?

4. Tests. Gibt es eine Testsuite, läuft sie durch, und deckt sie das ab, was Geld verdient – Bestellprozess, Abrechnung, Rechteprüfung? Fehlende Tests sind kein Ausschlusskriterium, aber sie bestimmen, wie schnell wir uns danach trauen, etwas zu ändern.

5. Umgebungen und Deployment. Gibt es neben der Produktion ein Test- oder Staging-System? Wie kommt Code auf den Server – per Pipeline oder per FTP von Hand? Existieren Backups, und wurde schon einmal ein Restore getestet?

6. Dokumentation und Zugänge. Existiert eine Einrichtungs-Anleitung, mit der das Projekt lokal startet? Sind alle Zugänge vollständig: Git-Repository, Server/SSH, Datenbank, Domain und DNS, Mail-Versand, Zahlungsdienstleister, externe APIs?

So läuft eine Übernahme bei uns ab

Wir haben das inzwischen oft genug gemacht, dass es einem festen Ablauf folgt. Kein Prozess-Theater, sondern die Reihenfolge, die Risiken früh sichtbar macht:

1. Erstgespräch (kostenlos, ca. 30 Minuten). Du erzählst, was das System tut, wo es klemmt und was du als Nächstes vorhast. Wir sagen dir ehrlich, ob wir die Richtigen sind. Manchmal lautet die Antwort: „Bleib bei deinem Dienstleister und fordere X ein."
2. Lesezugriff aufs Repository. Schon ein halber Tag Codelektüre sagt uns mehr als jede Beschreibung. Wenn du magst, unterschreiben wir vorher eine NDA – das ist bei uns Routine.
3. Audit mit schriftlichem Ergebnis. Wir arbeiten die sechs Punkte von oben ab und liefern dir ein Dokument in Klartext: Zustand, konkrete Risiken nach Dringlichkeit sortiert, und was die Behebung jeweils kostet. Das Dokument gehört dir – auch wenn du danach mit jemand anderem weiterarbeitest.
4. Übernahme der Infrastruktur. Repository, Server, Deployment, Monitoring, Backups. Wir bauen das Projekt bei uns lokal auf und richten – falls nicht vorhanden – ein Staging-System ein. Erst wenn ein Release reproduzierbar durchläuft, sind wir wirklich übernommen.
5. Erste kleine Änderung produktiv bringen. Bewusst etwas Unspektakuläres: ein Feld, ein Text, ein Bugfix. Das ist die eigentliche Feuerprobe – danach wissen beide Seiten, dass die Kette vom Ticket bis zur Produktion funktioniert.
6. Stabilisieren, dann weiterentwickeln. Sicherheitsrelevante Updates und die gröbsten Risiken zuerst. Danach die Roadmap, wegen der du eigentlich gewechselt hast.

Wie wir generell arbeiten – testgetrieben, in kurzen Zyklen, mit nachvollziehbaren Aufwänden – haben wir in unserem Prozess beschrieben. An dieser Arbeitsweise ändert sich bei einer Übernahme nichts.

Die drei Risiken, die wirklich wehtun

Wissens-Monopol

Das häufigste und teuerste Problem. Ein einzelner Entwickler hat das System über Jahre gebaut, alles im Kopf, nichts aufgeschrieben. Fällt er aus, ist niemand da, der weiß, warum die Rechnungslogik ausgerechnet so funktioniert.

Entschärfen lässt sich das mit einer Übergabe im Guten: ein bis zwei gemeinsame Sitzungen mit dem bisherigen Entwickler, bezahlt und wertschätzend. Das ist die günstigste Stunde, die du in dem ganzen Projekt kaufst. Ist das nicht mehr möglich, rekonstruieren wir die Logik aus dem Code – dauert länger, funktioniert aber. Parallel schreiben wir mit, was wir lernen. Nicht als 80-seitiges Handbuch, sondern als lebende README, die reicht, damit der nächste Mensch in einem Tag startklar ist.

Veraltete Versionen

Alte Laravel- und PHP-Versionen sind kein Schönheitsfehler, sondern eine Sicherheitsfrage. Ohne Patches bleibt jede bekannt gewordene Lücke offen. Der Fehler, den wir dabei am häufigsten sehen: Das Update wird als Big-Bang geplant – erst alles gleichzeitig anfassen, dann hoffen.

Wir gehen andersherum vor: eine Hauptversion nach der anderen, jede einzeln getestet und deployt. Wenn keine Tests existieren, schreiben wir zuerst welche für die Bereiche, die Geld verdienen. Das fühlt sich langsamer an und ist am Ende schneller, weil nach jedem Schritt ein Zustand existiert, der nachweislich läuft. Bei sehr alten Systemen kann sich die Frage stellen, ob ein Update oder eine echte Migration sinnvoller ist – wie wir das abwägen, steht in unserem Beitrag zum Ablösen von Legacy-Software.

Fehlende Tests

Ohne Testsuite ist jede Änderung ein Blindflug. Die gute Nachricht: Du brauchst keine 100 % Abdeckung, um handlungsfähig zu werden. Es reichen die kritischen Pfade – Login und Rechte, Bestellung oder Buchung, Abrechnung, Schnittstellen nach außen. Aus unserer Erfahrung deckt eine Handvoll gut gewählter Feature-Tests den Großteil des realen Risikos ab und ist in wenigen Tagen geschrieben.

Was der Wechsel kostet – ehrlich gerechnet

Hier wird es konkret, weil du das planen können musst:

• Das Erstgespräch kostet nichts. 30 Minuten, in denen wir dir sagen, ob und wie wir helfen können.
• Audit und Einarbeitung rechnen wir nach Aufwand zu 79 €/h ab. Für ein durchschnittliches Laravel-Projekt landen wir dabei erfahrungsgemäß bei ein bis drei Tagen. Ist der Code gut gepflegt, wird es weniger; ist es ein gewachsenes System ohne Tests und Doku, mehr. Wir sagen dir vorher, mit welchem Rahmen wir rechnen, und melden uns, bevor wir ihn überschreiten – nicht danach.
• Ein größeres Update oder eine Stabilisierungsphase kalkulieren wir als eigenes, gedeckeltes Paket. Du weißt vorher, woran du bist.
• Laufende Betreuung gibt es ab 119 €/Monat. Darin stecken Updates, Monitoring, Backup-Kontrolle und ein fester Ansprechpartner. Warum das kein optionales Extra ist, haben wir in Software-Wartung: warum sie wichtig ist aufgeschrieben.
• Neuentwicklungen auf Laravel-Basis starten bei uns ab 3.900 € – aber genau das ist bei einer Übernahme in der Regel nicht nötig. Alle Pakete und Optionen findest du transparent auf unserer Preisübersicht.

Das Wichtigste dabei: Ein Audit ist kein Vorverkaufstermin. Wenn dein bestehendes System solide gebaut ist, sagen wir das – auch wenn ein Rewrite für uns lukrativer wäre.

Häufige Fragen zum Agenturwechsel

Kann man mitten im Projekt wechseln?

Ja. Es ist unangenehmer als zu einem Feature-Schnitt, aber es geht. Wichtig ist, dass der Stand ins Repository committet und deploybar ist. Halbfertige Features lassen wir zunächst liegen, bringen das System in einen stabilen Zustand und entscheiden dann bewusst: fertigbauen oder verwerfen. Was wir nicht tun, ist einen halbfertigen Zweig blind zu Ende bauen, ohne zu verstehen, was er soll.

Muss die Anwendung dafür offline gehen?

Nein. Eine Übernahme findet erst einmal komplett neben dem Livebetrieb statt: lesen, aufsetzen, prüfen. Der einzige Moment mit Berührung ist ein möglicher Umzug der Infrastruktur, und der lässt sich in ein Wartungsfenster von Minuten legen.

Was, wenn der alte Dienstleister nicht kooperiert?

Kommt vor, ist aber lösbar. Repository und Server-Zugang sind die einzigen wirklich harten Punkte – alles andere lässt sich rekonstruieren. Steht der Code nur auf dem Produktionsserver, holen wir ihn dort. Domain und DNS lassen sich über den Registrar zurückholen, sofern du als Inhaber eingetragen bist. Deshalb: Prüfe heute, wer bei deiner Domain als Inhaber steht.

Braucht ihr den Original-Entwickler?

Schön, aber nicht zwingend. Laravel ist ein konventionsstarkes Framework – wer es kennt, findet sich auch in fremdem Code zurecht, weil Verzeichnisstruktur, Routing, Models und Migrations überall gleich funktionieren. Genau deshalb ist Laravel für Bestandsprojekte so angenehm: Du bist nicht auf einen einzigen Menschen angewiesen. Warum wir grundsätzlich darauf setzen, steht in Warum wir auf Laravel setzen.

Lohnt sich stattdessen ein Neubau?

Selten. Ein Rewrite kostet ein Vielfaches, dauert Monate und produziert erst einmal null neuen Nutzen – während das alte System weiterlaufen muss. Wir empfehlen ihn nur, wenn die Fachlichkeit selbst überholt ist oder die technische Basis so weit weg ist, dass jede Änderung mehr kostet als ein Neuanfang. In neun von zehn Fällen ist die richtige Antwort: übernehmen, stabilisieren, weiterentwickeln.

Fazit: Ein Wechsel ist kein Neustart

Der Wechsel der Laravel-Agentur ist kein Drama, sondern Handwerk. Entscheidend sind drei Dinge: die Zugänge vollständig in deiner Hand, ein ehrliches Audit vor dem ersten Angebot, und ein neues Team, das erst stabilisiert und dann weiterbaut, statt sofort einen Rewrite zu verkaufen. Wenn das gegeben ist, merkst du vom Wechsel im laufenden Betrieb kaum etwas – außer, dass wieder jemand antwortet.

Als Laravel-Agentur übernehmen wir regelmäßig bestehende Projekte, auch solche, die ihre besten Jahre hinter sich haben. Und wenn dabei herauskommt, dass dein System eigentlich mehr ist als eine Laravel-App – zum Beispiel eine gewachsene Individualsoftware mit Schnittstellen in alle Richtungen – schauen wir uns das genauso an.

Du hast eine Laravel-Anwendung, um die sich gerade niemand richtig kümmert? Schick uns einen kurzen Überblick, worum es geht, und wir schauen in einem kostenlosen Erstgespräch gemeinsam drauf. Du bekommst eine ehrliche Einschätzung zum Zustand deines Projekts – auch dann, wenn sie lautet, dass du gar nicht wechseln musst. Melde dich einfach, unverbindlich und ohne Verkaufsdruck.