B2B Case Study · Internationaler Automobilhersteller

Laravel 8 bis 13 für eine geschäftskritische B2B-Plattform.

Die B2B-Plattform wurde von Laravel 8 auf Laravel 13 aktualisiert. Kritische Geschäftsabläufe, Abhängigkeiten und Releases wurden vor jedem Versionsschritt geprüft und mit automatisierten Tests abgesichert.

Laravel 8 → 13: Kontrollierter Framework-Pfad
407 → 695: PHP-Tests
2.038 → 4.001: Assertions
6 / 6: Isolierte Browser-Flows

Die Ausgangslage

Die Plattform steuerte Bestellung, Lager und Abrechnung.

Die Anwendung war über Jahre zu einem operativen System gewachsen. Sie verband Händler- und Unternehmensdaten mit Bestellungen, Aktionen, Lagerbewegungen, Logistik, Rechnungs- und Lieferscheindokumenten, Datenaustausch und Reporting.

Ein Upgrade konnte deshalb nicht daran gemessen werden, ob Composer eine neue Laravel-Version akzeptiert. Entscheidend war, ob die fachlichen Abläufe nach jeder Etappe weiterhin verständlich funktionierten und reproduzierbar geprüft werden konnten.

Ein kompletter Neubau hätte die vorhandene Geschäftslogik neu entdecken und parallel zum laufenden Betrieb reproduzieren müssen. Der kontrollierte Upgrade-Pfad reduzierte diese Unsicherheit, ohne notwendige Modernisierung aufzuschieben.

Warum es schwierig war

Geschäftslogik, Sicherheit und Releases absichern.

01

Verhalten erhalten

Gewachsene Geschäftsregeln durften beim Wechsel von Framework, Livewire, Build-System und Abhängigkeiten nicht unbemerkt verändert werden.

02

Sicherheit verbessern

Uploads, Anhänge, Einstellungen, E-Mail-Flows und Prozessgrenzen mussten gehärtet werden, ohne das Upgrade durch unkontrollierte Nebenprojekte zu blockieren.

03

Releases vorab prüfen

Migrationen, Assets, Browser-Verhalten und Serverwechsel wurden mit festen Prüfungen und einem getrennten Deployment-Weg abgesichert.

Der Upgrade-Pfad

Von Laravel 8 bis Laravel 13 in geprüften Etappen.

Framework-Sprünge, Livewire-Wechsel und Frontend-Modernisierung wurden getrennt umgesetzt. Code, Browser-Flows, Migrationen und Produktions-Build mussten nach jeder Etappe alle Prüfungen bestehen.

01 Laravel 8
02 Laravel 9
03 Laravel 10
04 Livewire 4
05 Laravel 11
06 Laravel 12
07 Laravel 13

Die Vorgehensweise

So lief die Modernisierung ab.

01

Geschäftskritische Pfade zuerst verstehen

Vor Änderungen wurden die Abläufe identifiziert, deren Verhalten das Produkt tatsächlich ausmacht: Bestellung, Lager, Logistik, Dokumente, Datenaustausch und operative Verwaltung.

02

Regressionen sichtbar machen

Bestehende Tests wurden erweitert und kritische Browser-Abläufe isoliert. So entstand Schutz für Verhalten, das nicht allein aus einzelnen Klassen oder Methoden lesbar war.

03

Framework und Abhängigkeiten etappenweise bewegen

Jede Laravel-Stufe bekam einen klaren Umfang. Veraltete Pakete, Livewire-Verhalten, Assets, Migrationen und Security-Änderungen wurden dort angepasst, wo sie nachvollziehbar geprüft werden konnten.

04

Release auf dem neuen Server vorbereiten

Zum Abschluss wurden Produktions-Assets reproduzierbar gebaut, das Schema frisch aufgesetzt, Migrationen zurückgerollt und erneut ausgeführt sowie der neue Serverweg getrennt geprüft.

Das Ergebnis

Laravel 13, 695 Tests und reproduzierbare Releases.

Aktuelle technische Basis

Laravel 13, Livewire 4 und ein moderner Frontend-Build schaffen wieder einen unterstützten Ausgangspunkt für weitere Produktarbeit.

Geschäftsabläufe automatisiert getestet

695 PHP-Tests, 4.001 Assertions und sechs isolierte Browser-Flows sichern zentrale fachliche und technische Pfade ab.

Sicherer Betrieb

Private Anhänge, verschlüsselte Einstellungen, atomare Prozesse und Staging-Mail-Schutz reduzieren vermeidbare Produktionsrisiken.

Reproduzierbare Releases

Produktions-Build, Migrationen und der neue Serverpfad können vor dem Deployment getrennt geprüft werden.

Was andere Teams daraus mitnehmen können

Vier Grundsätze für Laravel-Upgrades.

Geschäftslogik sollte vor dem Framework-Pfad beschrieben und priorisiert werden.
Tests sind besonders wertvoll, wenn sie Verhalten schützen, das im Code nicht sofort offensichtlich ist.
Security- und Infrastrukturarbeit braucht einen klaren Platz im Upgrade, darf aber nicht alle Änderungen untrennbar vermischen.
Ein modernes Zielsystem ist erst erreicht, wenn Build, Migration und Deployment reproduzierbar geprüft werden können.

Entscheidungshilfe

Fragen vor einer Laravel-Modernisierung.

Wann ist ein schrittweises Laravel-Upgrade sinnvoller als ein Rewrite?

Ein schrittweises Upgrade ist sinnvoll, wenn die bestehende Anwendung wertvolle Geschäftslogik enthält, der fachliche Kern weiterhin passt und das Risiko eines kompletten Neubaus höher ist als eine kontrollierte Modernisierung mit Tests und klaren Zwischenzielen.

Was sollte vor einem Laravel-Upgrade geprüft werden?

Vor dem ersten Versionsschritt sollten Abhängigkeiten, kritische Geschäftsabläufe, Integrationen, Datenmigrationen, Testabdeckung, Build-Prozess und Deployment-Risiken sichtbar sein. Daraus entsteht ein Upgrade-Pfad mit Prüfpunkten und einer realistischen Rückfallstrategie.

Kann eine Laravel-Anwendung während der Modernisierung weiterbetrieben werden?

Ja, wenn die Modernisierung in releasefähige Etappen geschnitten wird. Jede Stufe braucht automatisierte Prüfungen, fachliche Abnahmen und einen kontrollierten Deployment-Weg, bevor die nächste Framework- oder Abhängigkeitsstufe beginnt.

Wie schützt man Geschäftslogik bei einem Framework-Upgrade?

Geschäftslogik wird geschützt, indem kritische Abläufe zuerst verstanden und mit Regressionstests abgesichert werden. Framework-Änderungen, Refactorings und Sicherheitsverbesserungen werden anschließend getrennt genug umgesetzt, damit Fehlerquellen nachvollziehbar bleiben.