Technologische Due Diligence bei Laravel-Anwendungen: Prozess und Checkliste

Ein funktionierendes Frontend ist kein Qualitätsbeweis. Diese Erkenntnis klingt banal – und doch ist sie der Ausgangspunkt für eine der wichtigsten Entscheidungen, die Unternehmen vor einer Softwareübernahme, Investition oder Partnerschaft treffen können. Was sich hinter einer gepflegten Oberfläche verbirgt, entscheidet darüber, ob eine Anwendung in zwei Jahren noch tragfähig ist – oder zum teuren Sanierungsfall wird.

Genau hier setzt die technologische Due Diligence an. Und gerade bei Laravel-Anwendungen lohnt sich ein strukturierter, tiefer Blick in die Architektur, den Code und die Infrastruktur – weit über das hinaus, was sich im Browser beobachten lässt.

Was auf dem Spiel steht: Zahlen, die man kennen sollte

Der Technologiesektor verzeichnete 2024 M&A-Aktivitäten im Wert von 640 Milliarden US-Dollar – ein Plus von 16 Prozent gegenüber 2023. Dennoch sind Technologieintegrationsprobleme laut Deloitte für rund 30 Prozent aller gescheiterten Fusionen verantwortlich.

Schätzungen zufolge hängen zwischen 40 und 60 Prozent der erwarteten Synergien in M&A-Transaktionen direkt vom Erfolg der IT-Integration ab – und dennoch werden technologische Aspekte im Akquisitionsprozess regelmäßig unterschätzt.

Erschreckend dabei: Nur einer von vier CEOs gibt an, für die meisten seiner Transaktionen eine technologische Due Diligence durchzuführen – obwohl 74 Prozent Technologie als zentralen Wachstumstreiber bezeichnen.

Die Lücke zwischen dem, was Entscheider für selbstverständlich halten, und dem, was sie tatsächlich prüfen, ist beträchtlich. Wer eine Laravel-Anwendung oder ein Tech-Unternehmen übernimmt, ohne die technische Substanz zu kennen, kauft die Katze im Sack – inklusive aller versteckten Folgekosten.

Was technologische Due Diligence wirklich bedeutet

Technologische Due Diligence ist eine umfassende Überprüfung des technologischen Ökosystems eines Unternehmens – von IT-Infrastruktur und Software über Sicherheitsprozesse bis hin zu digitalen Produkten. Ziel ist es, potenzielle Transaktionsrisiken, Investitionschancen und Verbesserungspotenziale im Rahmen von Investitions- oder Akquisitionsprozessen zu identifizieren. Anders als die finanzielle oder kommerzielle Due Diligence, die sich auf Geschäftskennzahlen und Marktpositionierung konzentriert, bewertet die technologische Due Diligence Qualität, Skalierbarkeit, Sicherheit und Nachhaltigkeit der technischen Infrastruktur sowie der Produktentwicklungspraktiken.

Für Laravel-Projekte konkret: Es geht nicht darum, ob eine Anwendung läuft. Es geht darum, wie sie läuft, warum sie so gebaut wurde – und welche Konsequenzen bestimmte Architekturentscheidungen für die nächsten Jahre haben.

Wer auf eine gründliche Software-Due-Diligence verzichtet, riskiert, Plattformen zu übernehmen, die auf instabilen oder veralteten Technologien aufgebaut sind, unter schlechter Codequalität leiden oder kritische Sicherheitslücken aufweisen.

Wann eine technische Prüfung sinnvoll ist

Die klassischen Anlässe kennen die meisten: Unternehmenskauf, Investitionsrunde, Beteiligungsentscheidung. Doch in der Praxis begegnen uns bei mindtwo deutlich mehr Szenarien, in denen eine strukturierte technische Bewertung echten Mehrwert schafft.

Übernahme einer bestehenden Anwendung: Wenn eine Webanwendung mitsamt ihrer Codebasis übernommen wird, sollte vor Vertragsabschluss klar sein, welcher technische Zustand tatsächlich vorliegt. Versteckter technischer Schuldenstand, veraltete Abhängigkeiten oder ein fehlendes Testfundament können die Folgekosten massiv in die Höhe treiben – und tun es regelmäßig.

Bewertung externer Dienstleister: Bevor ein Unternehmen ein laufendes Projekt von einer anderen Agentur oder einem Freelancer übernimmt, lohnt sich ein strukturierter Blick auf die geleistete Arbeit. Potenzielle Herausforderungen wie inkompatible Architekturen, ineffiziente Infrastruktur, fragile Deployment-Prozesse oder auf Einzelpersonen konzentriertes Wissen tauchen dabei regelmäßig auf – und beeinflussen direkt, wie schnell eine übernommene Anwendung skaliert, gewartet oder integriert werden kann.

Investitions- und Partnerentscheidungen: In M&A-Transaktionen ist eine technologische Due Diligence wichtig, um zu validieren, ob die Technologie des Zielunternehmens die Investitionsthese tragen kann. Sie hilft, technischen Schuldenstand, Skalierungsgrenzen, Cybersicherheitsrisiken und IP-Probleme zu identifizieren, die sich auf die Integration, den post-deal Investitionsbedarf oder die langfristige Wertschöpfung auswirken.

Interne Qualitätssicherung vor einem Relaunch: Auch ohne externen Anlass ist eine technische Bestandsaufnahme wertvoll – etwa bevor eine gewachsene Laravel-Anwendung skaliert oder grundlegend modernisiert werden soll. Das sehen wir immer wieder in Projekten: Unternehmen, die glauben, ihre Plattform gut zu kennen, entdecken im Rahmen eines solchen Assessments strukturelle Schwächen, die bis dahin unsichtbar waren.

Die zentralen Prüfbereiche im Detail

Architektur und technischer Schuldenstand

Der Ausgangspunkt jeder technischen Prüfung ist die Architektur. Die Architektur der Software erfordert eine umfangreiche Analyse hinsichtlich Qualität, Wartbarkeit, Skalierbarkeit und der Fähigkeit zur Integration in bestehende Systeme des übernehmenden Unternehmens.

Bei Laravel-Anwendungen stellen sich konkret folgende Fragen: Folgt die Anwendung dem MVC-Prinzip konsequent? Sind Verantwortlichkeiten klar getrennt? Werden Service-Klassen, Repositories und Events sinnvoll eingesetzt – oder ist die Geschäftslogik in Controllern vergraben, die niemand mehr vollständig überblickt?

Die Lücke zwischen oberflächlichen Wachstumskennzahlen und tatsächlicher Wertschöpfung versteckt sich häufig im Tech-Stack – fragile Architektur, nicht tragfähige Cloud-Kosten oder Integrationsalbträume, die erst nach Vertragsabschluss sichtbar werden.

Besonders kritisch: der Umgang mit technischem Schuldenstand. Technischer Schuldenstand führt zu höheren Wartungskosten, einem langsameren Entwicklungsprozess und eingeschränkter Systemzuverlässigkeit. Wer diesen Ballast übernimmt, sieht den Wert seiner Investition oft schleichend erodieren.

Codequalität und Testabdeckung

Sauberer, wartbarer Code ist keine ästhetische Präferenz – er ist die Grundlage für stabile Weiterentwicklung. Im Kontext von Webentwicklung mit PHP und Laravel gilt das besonders: PHP ist eine sehr flexible Sprache, die weniger erfahrene Entwickler zu Abkürzungen verleitet.

Die Bewertung von Coding-Standards und Test-Ansätzen gibt Aufschluss über die Effizienz des Teams und die Resilienz des Produkts. Konsistenz in Coding-Standards, Dokumentation und Versionskontrolle sind dabei zentrale Indikatoren.

Konkret prüfen wir: Werden PSR-Standards eingehalten? Ist der Code konsistent formatiert? Gibt es eine sinnvolle Test-Suite mit Unit- und Feature-Tests? Automatisierte statische Codeanalyse mit Tools wie PHPStan oder Larastan liefert schnell erste objektive Metriken – ergänzt durch manuelle Code-Reviews durch erfahrene Laravel-Entwickler, die das Framework in der Tiefe kennen.

Versionsstatus und Support-Fenster

Eine der am schnellsten prüfbaren, aber oft vernachlässigten Dimensionen: Auf welchem Stand befindet sich der Tech-Stack?

Für alle Laravel-Releases werden Bug-Fixes für 18 Monate und Sicherheits-Fixes für 2 Jahre bereitgestellt. Für alle zusätzlichen Bibliotheken erhält nur das jeweils aktuellste Major-Release Bug-Fixes.

Laravel 13 wurde am 17. März 2026 veröffentlicht. Das Framework setzt mindestens PHP 8.3 voraus und ist stabil sowie produktionsbereit. Laravel 12, veröffentlicht am 24. Februar 2025, erhält Bug-Fixes bis zum 13. August 2026 und Sicherheits-Fixes bis zum 24. Februar 2027.

Anwendungen, die noch auf Laravel 10 oder älter laufen, befinden sich außerhalb des offiziellen Support-Fensters. Das ist kein theoretisches Risiko – eine Anwendung, die vor zwei oder drei Jahren live gegangen ist, mag noch funktionieren, aber das bedeutet nicht, dass sie gut oder sicher funktioniert. Wenn sie auf Laravel 7, 6 oder sogar 5.8 aufbaut, hat sie sich still und leise außerhalb des Support-Fensters bewegt. PHP-Kompatibilität hat sich verändert. Paket-Maintainer sind weitergezogen. Funktionen, auf die man einst vertraute, sind nun veraltet.

Neben der Laravel- und PHP-Version gehören zur Stack-Prüfung: das Datenbanksystem und dessen Version, der Webserver, alle eingesetzten Composer-Pakete sowie die Deployment-Mechanismen.

Abhängigkeiten und Lizenzen

Laravel-Anwendungen sind typischerweise von einer Vielzahl von Composer-Paketen abhängig – und genau diese Abhängigkeiten sind ein oft unterschätzter Risikofaktor.

In M&A-Transaktionen ist besondere Aufmerksamkeit auf Vertragszuweisungsrechte geboten, da sie zeigen, ob die wertvollsten Vereinbarungen nach dem Closing weiterhin nutzbar sind. Viele kommerzielle Verträge enthalten Anti-Assignment-, Change-of-Control- oder "Deemed Assignment"-Klauseln, die bei Nichtbeachtung die Integrationsstrategie des Käufers gefährden oder kostspielige Neuverhandlungen erzwingen können.

Konkret bedeutet das für die Prüfung: Werden alle eingesetzten Pakete aktiv gepflegt? Gibt es bekannte CVEs (Common Vulnerabilities and Exposures)? Sind die verwendeten Lizenzen kompatibel mit dem geplanten Einsatz – insbesondere bei kommerziellen Anwendungen?

Sicherheit und DSGVO-Konformität

Der globale Markt für Cybersecurity Due Diligence für M&A wurde 2024 auf 5,16 Milliarden US-Dollar geschätzt und soll bis 2031 auf 7,82 Milliarden US-Dollar anwachsen – ein Indikator für den wachsenden Fokus auf Sicherheitsrisiken bei Transaktionen.

Bei Laravel-Projekten umfasst die Sicherheitsprüfung konkret: Wie ist die Authentifizierung implementiert? Werden Passwörter korrekt gehasht? Gibt es CSRF-Schutz, SQL-Injection-Prävention und eine korrekte Konfiguration der CORS-Header? Werden sensible Konfigurationsdaten über Environment-Variablen verwaltet und nicht im Repository hinterlegt?

Cyber-Bedrohungen haben in den letzten Jahren massiv zugenommen und machen Cybersicherheit zu einem der dringlichsten Bestandteile jeder IT-Due-Diligence. Eine schwerwiegende Sicherheitslücke oder ein früherer Breach kann eine Transaktion zum Scheitern bringen oder den Deal-Wert erheblich mindern – wie einige aufsehenerregende Fälle gezeigt haben, in denen unentdeckte Vorfälle mitten in der Transaktion ans Licht kamen.

Für Anwendungen, die personenbezogene Daten verarbeiten, ist zusätzlich die DSGVO-Konformität zu prüfen: Datensparsamkeit, Löschkonzepte, Verarbeitungsverzeichnisse und Auftragsverarbeitungsverträge sind keine optionalen Extras.

Infrastruktur, Deployment und Betrieb

Damit das Versprechen einer Akquisition eingelöst werden kann, muss die IT-Umgebung des Zielunternehmens in der Lage sein, erhöhte Nachfrage und gesteigerte Geschäftskomplexität zu bewältigen. Wenn die übernommenen Systeme unter höherer Transaktionslast oder zusätzlichem Nutzerverkehr zusammenbrechen, können Betriebsstörungen und Notfallausgaben die erwarteten Synergien zunichte machen.

Für Laravel-Anwendungen gehören zur Infrastrukturprüfung: Gibt es eine saubere Trennung zwischen Entwicklungs-, Staging- und Produktivumgebung? Sind automatisierte Deployments vorhanden? Werden Logs strukturiert erfasst? Ist ein Monitoring-System aktiv? Wie sehen Backup- und Recovery-Strategien aus? Backup-Frequenzen, Speicherorte kritischer Daten und Recovery-Protokolle müssen dokumentiert und prüfbar sein.

Dokumentation und Wissenstransfer

Technische Qualität endet nicht beim Code. Die technologische Due Diligence hilft auch, frühe Prioritäten für die Ausrichtung des Tech-Teams, die Ressourcenallokation und die Roadmap-Rationalisierung zu definieren. Indem geklärt wird, was verändert werden muss und was bereits funktioniert, ermöglicht sie eine realistischere Integrationsplanung, reduziert Ausführungsrisiken und beschleunigt die Zeit bis zur Synergierealisierung.

Konkret: Ist die Architektur dokumentiert? Kann ein neuer Entwickler ohne Wochen-Onboarding produktiv werden? Ist Wissen auf mehrere Personen verteilt – oder hängt die gesamte Anwendung am Wissen einer einzigen Person?

Praktische Checkliste für die technologische Due Diligence

Die folgende Checkliste fasst die wichtigsten Prüfpunkte zusammen. Sie ist als strukturierter Ausgangspunkt gedacht – je nach Komplexität der Anwendung werden einzelne Bereiche vertieft.

Technologie-Stack & Versionen

• [ ] Laravel-Version: aktuell und innerhalb des Support-Fensters? (ab Laravel 12 für aktiven Support)
• [ ] PHP-Version: PHP 8.3+ für Laravel 13, mindestens PHP 8.2 für Laravel 12?
• [ ] Alle Composer-Abhängigkeiten auf bekannte Sicherheitslücken geprüft (composer audit)?
• [ ] Webserver-Version (Nginx/Apache) und Betriebssystem dokumentiert und aktuell?
• [ ] Datenbank-Version und Konfiguration nachvollziehbar?

Codequalität & Architektur

• [ ] PSR-Standards und Laravel-Konventionen eingehalten?
• [ ] Klare Trennung von Verantwortlichkeiten – keine Logik-Anhäufungen in Controllern?
• [ ] Test-Suite vorhanden (Unit Tests, Feature Tests, ggf. Browser Tests)?
• [ ] Statische Codeanalyse durchgeführt (PHPStan / Larastan)?
• [ ] Architektur und kritische Entscheidungen dokumentiert?

Sicherheit & Compliance

• [ ] Authentifizierung und Autorisierung korrekt implementiert?
• [ ] Keine sensiblen Daten im Repository (API-Keys, Credentials, Passwörter)?
• [ ] HTTPS und aktuelle TLS-Version durchgängig konfiguriert?
• [ ] DSGVO-Anforderungen adressiert (Datenschutzerklärung, Löschkonzepte, AVV)?
• [ ] Sicherheitsrelevante Laravel-Features aktiv (CSRF-Schutz, XSS-Prävention, SQL-Injection-Schutz)?

Abhängigkeiten & Lizenzen

• [ ] Alle eingesetzten Pakete aktiv gepflegt und ohne bekannte CVEs?
• [ ] Lizenzkompatibilität geprüft – insbesondere bei kommerzieller Nutzung?
• [ ] Keine unnötigen oder redundanten Abhängigkeiten, die Angriffsfläche erhöhen?

Infrastruktur & Deployment

• [ ] Staging-Umgebung vorhanden und produktionsähnlich konfiguriert?
• [ ] CI/CD-Pipeline eingerichtet und automatisierte Tests integriert?
• [ ] Backup- und Recovery-Strategie dokumentiert, getestet und regelmäßig ausgeführt?
• [ ] Monitoring und Alerting aktiv (Fehlertracking, Performance-Metriken)?
• [ ] Environment-Variablen sauber verwaltet, kein Hardcoding sensibler Werte?

Dokumentation & Prozesse

• [ ] Technische Dokumentation aktuell und für neue Entwickler zugänglich?
• [ ] Onboarding neuer Entwickler ohne monatelange Einarbeitung möglich?
• [ ] Wissen auf mehrere Personen verteilt – kein kritischer Bus-Faktor?
• [ ] Klare Branching- und Release-Strategie dokumentiert?

Was eine strukturierte Prüfung konkret bewirkt

In einem konkreten Fall führte eine Software-Due-Diligence zur Erkenntnis, dass die zu übernehmende Plattform wesentliche Design-Paradigmen für Skalierbarkeit vermissen ließ und erhebliche Investitionen erfordert hätte. Das Ergebnis: Das Unternehmen verhandelte den Kaufpreis auf ein Fünftel des ursprünglich geschätzten Preises herunter.

Solche Szenarien sind keine Ausnahme. Unternehmen, die frühzeitig auf strukturierte technische Prüfungen gesetzt haben, konnten vermeiden, dass versteckte Schulden erst nach Vertragsabschluss sichtbar wurden – zu einem Zeitpunkt, an dem die Verhandlungsposition längst verloren war.

Auf der anderen Seite gilt: Für Verkäufer und Auftraggeber kann eine gut vorbereitete technische Due Diligence Glaubwürdigkeit schaffen. Eine sauber dokumentierte, strukturiert aufgebaute Laravel-Anwendung ist ein messbarer Wettbewerbsvorteil – nicht nur technisch, sondern auch wirtschaftlich. Sie validiert, ob die Technologie den Geschäftsplan tragen, mit dem Wachstum skalieren und einer Prüfung aus Risiko-, Betriebs- und IP-Perspektive standhalten kann.

Wie wir Due-Diligence-Prüfungen angehen

Bei mindtwo führen wir technologische Due Diligences sowohl für eigene Neuprojekte als auch im Rahmen von Laravel-Projektübernahmen durch. Unser Ansatz kombiniert automatisierte Analyse – statische Codeanalyse, Dependency-Audits, Sicherheitsscans – mit manueller Bewertung durch erfahrene Entwickler, die das Laravel-Ökosystem von Grund auf kennen.

Wir prüfen nicht nur, ob eine Anwendung funktioniert. Wir analysieren, ob sie zukunftsfähig ist: Kann sie unter Last skalieren? Kann sie in zwei Jahren noch von einem neuen Team übernommen werden? Und was kostet es realistisch, identifizierte Schwächen zu beheben?

Am Ende einer Due Diligence sollte keine bloße Liste von Problemen stehen, sondern eine fundierte Entscheidungsgrundlage: mit konkreten Risikobewertungen, realistischen Aufwandsschätzungen und einer klaren Empfehlung, ob und unter welchen Bedingungen eine Investition oder Übernahme sinnvoll ist.

Als Digitalagentur mit langjähriger Erfahrung in der Laravel-Entwicklung kennen wir die typischen Muster gewachsener Systeme – und wissen, wo die wirklichen Risiken liegen: nicht im offensichtlichen, sondern im Verborgenen.