Laravel-Projekt übernehmen: Welche Unterlagen und Zugänge werden benötigt?

Wenn die bisherige Betreuung endet

Ein Laravel-Projekt soll von einer neuen Person oder Dienstleistung übernommen werden. Die Anwendung läuft zwar, aber niemand weiß genau, auf welchem Server sie liegt, wie Deployments durchgeführt werden oder welche Zugangsdaten noch gültig sind. In dieser Situation ist es riskant, sofort Änderungen am Code vorzunehmen.

Eine geordnete Übernahme beginnt deshalb nicht mit neuen Funktionen, sondern mit einer Bestandsaufnahme. Ziel ist, die Anwendung technisch, organisatorisch und sicherheitstechnisch so weit zu verstehen, dass Änderungen planbar werden.

1. Überblick über die Anwendung schaffen

Zunächst sollte festgehalten werden, welchen Zweck die Anwendung erfüllt und welche Geschäftsprozesse davon abhängen. Eine kurze fachliche Beschreibung ist oft genauso wichtig wie die technische Dokumentation.

Hilfreich sind unter anderem diese Informationen:

• Welche Nutzergruppen verwenden die Anwendung?
• Welche Funktionen sind geschäftskritisch?
• Gibt es Kundenportale, interne Verwaltungsbereiche oder öffentliche Seiten?
• Welche Daten werden gespeichert und verarbeitet?
• Welche Abläufe dürfen bei Wartungsarbeiten nicht unterbrochen werden?
• Gibt es bekannte Fehler, offene Aufgaben oder bereits geplante Erweiterungen?

Auch eine Liste der wichtigsten Bereiche hilft bei der Priorisierung. Ein Login, eine Bestellverwaltung oder eine Schnittstelle zu einem anderen System kann beispielsweise kritischer sein als eine selten genutzte Auswertungsseite.

2. Quellcode und Versionsverwaltung prüfen

Der Quellcode sollte in einem nachvollziehbaren Repository liegen, beispielsweise in einer Git-Verwaltung. Entscheidend ist nicht nur, ob der Code vorhanden ist, sondern auch, ob die aktuelle Produktionsversion eindeutig erkennbar ist.

Für die Übernahme sind besonders relevant:

• Repository und verwendeter Branch für die produktive Version
• vorhandene Entwicklungs- und Testumgebungen
• Commit-Historie und offene Änderungen
• composer.json und composer.lock für PHP-Abhängigkeiten
• Hinweise auf Frontend-Abhängigkeiten und Build-Prozesse
• vorhandene README-Dateien oder technische Notizen
• Konfigurationen für Tests, Code-Qualität und Deployment

Die Dateien mit Umgebungsvariablen, häufig .env genannt, sollten nicht einfach in ein Repository kopiert werden. Sie können Passwörter, API-Schlüssel und andere vertrauliche Werte enthalten. Stattdessen sollte nachvollziehbar dokumentiert sein, welche Konfigurationswerte in welcher Umgebung benötigt werden und wer sie sicher bereitstellen kann.

3. Server, Hosting und Deployment dokumentieren

Eine Laravel-Anwendung besteht nicht nur aus dem Repository. Für den Betrieb werden unter anderem Webserver, PHP, Datenbank, Dateispeicher, Wartungsaufgaben und gegebenenfalls Hintergrundprozesse benötigt.

Vor dem Start sollte daher geklärt werden:

• Bei welchem Hosting-Anbieter oder auf welchem Server läuft die Anwendung?
• Wer besitzt die administrativen Zugänge?
• Welche PHP-Version und welche Datenbank werden verwendet?
• Wo liegen Uploads, Logdateien und temporäre Dateien?
• Wie wird der Code in die produktive Umgebung übertragen?
• Gibt es automatisierte Deployments oder erfolgt die Veröffentlichung manuell?
• Müssen Queue-Worker, Scheduler oder andere Hintergrundprozesse laufen?
• Wie werden Änderungen im Notfall zurückgenommen?

Ein Deployment bezeichnet den Vorgang, mit dem eine neue Version in eine Zielumgebung gebracht wird. Wenn dieser Ablauf nicht dokumentiert ist, sollte er bei der Übernahme zunächst beobachtet und schriftlich festgehalten werden. Eine Änderung direkt auf dem Produktivserver ist vermeidbar und erschwert spätere Fehleranalysen.

4. Datenbank und externe Schnittstellen erfassen

Die Datenbank enthält häufig die wichtigsten Geschäftsdaten. Deshalb sollte nicht nur der technische Zugang vorhanden sein. Ebenso wichtig sind Informationen über Backups, Wiederherstellung und die Struktur der zentralen Tabellen.

Zu prüfen sind beispielsweise:

• Datenbanktyp und Verbindungsdaten
• automatisierte Backups und deren Aufbewahrung
• dokumentierte Wiederherstellung oder vorhandene Test-Wiederherstellungen
• wichtige Tabellen, Beziehungen und Dateiverknüpfungen
• Rollen und Berechtigungen innerhalb der Anwendung
• Importe, Exporte und regelmäßige Datenverarbeitung

Zusätzlich sollten alle externen Systeme erfasst werden. Dazu gehören Zahlungsanbieter, Versanddienste, E-Mail-Versand, Warenwirtschaft, CRM-Systeme oder andere Unternehmenssoftware. Für jede Schnittstelle sollten Zweck, Authentifizierung, übertragene Daten und verantwortliche Ansprechpersonen bekannt sein.

Besonders wichtig sind Fehlerfälle: Was passiert, wenn ein externer Dienst nicht erreichbar ist? Werden fehlgeschlagene Vorgänge protokolliert, wiederholt oder zur manuellen Prüfung markiert? Diese Fragen entscheiden darüber, ob ein Problem schnell gefunden werden kann oder unbemerkt zu falschen Daten führt.

5. Zugänge sicher übergeben

Für eine technische Übernahme werden oft viele Zugänge benötigt: Versionsverwaltung, Hosting, Datenbank, Domainverwaltung, Monitoring, E-Mail-Dienste und externe Schnittstellen. Eine unstrukturierte Weitergabe per unverschlüsselter E-Mail ist dafür nicht geeignet.

Besser ist eine kontrollierte Übergabe über einen geeigneten Passwortmanager oder einen anderen abgesicherten Weg. Nach der Übergabe sollten nicht mehr benötigte Konten entfernt und gemeinsam genutzte Passwörter geändert werden. Zugänge sollten nach dem Prinzip der geringsten notwendigen Berechtigung vergeben werden: Wer nur Logs prüfen muss, benötigt nicht automatisch vollständige Serverrechte.

Außerdem sollte dokumentiert werden, wem welche Konten gehören. Ein Dienstleister sollte nicht der alleinige Besitzer eines geschäftskritischen Kontos sein. Das Unternehmen muss die Kontrolle über Hosting, Domains, Daten und zentrale Dienste behalten.

6. Sicherheit und Wartbarkeit nicht überspringen

Eine Übernahme ist ein guter Zeitpunkt für eine technische Sicherheits- und Wartbarkeitsprüfung. Dabei geht es nicht um eine pauschale Garantie, sondern um das Erkennen konkreter Risiken.

Sinnvolle Prüfpunkte sind:

• Werden Sicherheitsupdates für PHP, Laravel und Abhängigkeiten eingeplant?
• Gibt es Fehlermeldungen mit sensiblen Daten in der produktiven Umgebung?
• Sind Debug-Funktionen deaktiviert?
• Werden Zugriffe und wichtige Änderungen nachvollziehbar protokolliert?
• Funktionieren Backups tatsächlich und lässt sich eine Wiederherstellung durchführen?
• Gibt es automatisierte Tests für kritische Geschäftsabläufe?
• Sind veraltete oder nicht mehr benötigte Abhängigkeiten vorhanden?

Nicht jede technische Schwäche muss sofort behoben werden. Entscheidend ist eine priorisierte Liste: akute Betriebs- oder Sicherheitsrisiken zuerst, danach Verbesserungen an Dokumentation, Tests und Codequalität.

7. Die ersten Schritte nach der Übergabe

Nach dem Sammeln der Informationen empfiehlt sich ein klarer Ablauf:

1. Zugänge und Verantwortlichkeiten bestätigen.
2. Entwicklungs- oder Testumgebung einrichten.
3. Anwendung lokal oder in einer geschützten Umgebung starten.
4. Produktive Architektur, Abhängigkeiten und Datenflüsse dokumentieren.
5. Backups und Wiederherstellungsweg prüfen.
6. Bekannte Fehler und offene Aufgaben bewerten.
7. Risiken und kurzfristige Maßnahmen priorisieren.
8. Erst danach neue Funktionen planen.

Ein erfundenes Beispiel: Eine interne Laravel-Verwaltung läuft stabil, aber der bisherige Entwickler ist nicht mehr erreichbar. Bei der Übernahme stellt sich heraus, dass es zwar tägliche Datenbank-Backups gibt, die Uploads aber nicht gesichert werden. Die wichtigste erste Maßnahme wäre dann nicht eine neue Oberfläche, sondern die Prüfung und Absicherung der vollständigen Datensicherung.

Checkliste für das Übergabegespräch

• Zweck und kritische Funktionen der Anwendung sind beschrieben.
• Repository und produktiver Stand sind bekannt.
• Entwicklungs-, Test- und Produktionsumgebung sind unterschieden.
• Hosting-, Server- und Datenbankzugänge sind sicher übergeben.
• Deployment, Hintergrundprozesse und geplante Aufgaben sind dokumentiert.
• Externe Schnittstellen und Verantwortlichkeiten sind erfasst.
• Backups und Wiederherstellung wurden geprüft.
• Bekannte Fehler, Risiken und offene Aufgaben sind priorisiert.
• Nicht mehr benötigte Zugänge wurden entfernt oder gesperrt.

Fazit

Eine Laravel-Übernahme ist mehr als die Übergabe eines Git-Repositories. Erst das Zusammenspiel aus Code, Infrastruktur, Daten, Schnittstellen, Zugängen und Verantwortlichkeiten macht eine Anwendung verlässlich wartbar.

Wenn Informationen fehlen, sollte das offen dokumentiert werden. So lassen sich Risiken schrittweise reduzieren, ohne vorschnell eine komplette Neuentwicklung zu beginnen. Supptech unterstützt bei der strukturierten Bestandsaufnahme und der geordneten Weiterentwicklung bestehender Laravel-Anwendungen.