Was wir übernehmen

Versionssprünge

PHP 5.x und 7.x auf 8.3 oder 8.4.

Framework-Upgrades

Symfony 2 bis 6, dazu ältere Zend- und CakePHP-Projekte.

Anwendungen ohne Framework

Über Jahre gewachsener Code, gebaut von wechselnden Entwicklern.

Die Infrastruktur drumherum

Server, Deployment und Testumgebung gehören dazu.

Wodurch das Risiko sinkt

„Risikoarme Migration“ steht auf jeder Anbieterseite. Hier steht, was wir konkret dafür tun.

Erst das Netz, dann der Sprung

Vor der ersten Code-Änderung bauen wir Tests für die Abläufe, an denen bei Ihnen Geld hängt: Bestellung, Login, Rechnungslauf. Erst wenn die laufen, fassen wir den Code an. Wer ohne Tests migriert, erfährt von Fehlern durch Kundenanrufe.

Statische Analyse, bevor irgendetwas läuft

PHPStan findet Typfehler, tote Aufrufe und kaputte Vergleiche, ohne den Code auszuführen. Ein großer Teil der Probleme ist damit erledigt, bevor etwas deployed wird.

Automatisiert umbauen, wo es sicher geht

Rector schreibt wiederkehrende Muster maschinell um. Das geht schneller als Handarbeit und macht weniger Flüchtigkeitsfehler. Was sich nicht sicher automatisieren lässt, machen wir von Hand. Sie erfahren vorher, welcher Teil das ist.

Umschalten erst, wenn es grün ist

Ihr Livesystem läuft weiter, wir migrieren daneben. Der Wechsel passiert, wenn die Tests durchlaufen.


Was das kostet

Wir nennen keinen Preis, bevor wir den Code gesehen haben. Wer das tut, rechnet entweder einen Risikoaufschlag ein oder verhandelt später nach.

  1. 01

    Versionsabstand

    Von 7.4 auf 8.3 ist etwas anderes als von 5.3 auf 8.3.

  2. 02

    Testabdeckung

    Vorhandene Tests sparen einen erheblichen Teil der Arbeit.

  3. 03

    Fremdabhängigkeiten

    Bibliotheken, die es nicht mehr gibt, müssen ersetzt werden.

  4. 04

    Code-Qualität

    Sauber geschichtet oder über Jahre gewachsenes Geflecht.

  5. 05

    Umfang

    Zeilen, Module, Schnittstellen.

Deshalb arbeiten wir zweistufig. Zuerst eine Analyse, die den Aufwand belastbar macht, danach ein Angebot mit klarem Rahmen. Mehr dazu im Ratgeber: Was kostet eine PHP-Migration?

Was uns meistens entgegengehalten wird

Drei Sätze hören wir in fast jedem Erstgespräch. Alle drei sind nachvollziehbar.

„läuft doch“

Es funktioniert ja

Stimmt, bis es das nicht mehr tut. PHP 7.4 bekommt seit dem 28. November 2022 keine Sicherheitsupdates. Bei einem Datenleck über eine bekannte Lücke steht die DSGVO-Frage nach dem Stand der Technik im Raum, und eine seit Jahren abgekündigte Version lässt sich vor einer Aufsichtsbehörde schlecht als angemessene Schutzmaßnahme darstellen.

„zu teuer“

Das Budget fehlt

Eine Migration ist heute keine endlose Handarbeit mehr. PHPStan findet die kritischen Stellen vorab, Rector schreibt die wiederkehrenden Muster maschinell um. Dazu kommt: PHP 8 läuft durch JIT und viele kleine Optimierungen spürbar schneller als 7.4. Auf derselben Hardware heißt das entweder weniger Serverkosten oder mehr Luft bei Lastspitzen.

„keine Zeit“

Gerade passt es nicht

Der Aufwand wächst, während Sie warten. Je größer der Versionsabstand, desto teurer der Sprung. Und irgendwann entscheidet der Hoster: Abschaltungen alter PHP-Versionen kommen teils mit wenigen Wochen Vorlauf. Wer dann anfängt, migriert unter Zeitdruck. Das ist die teuerste Variante.


Was Sie selbst günstiger machen können

Drei der fünf Kostentreiber haben Sie in der Hand. Das sagen wir vorher, nicht in der Schlussrechnung.

Früh anfangen

Der Versionsabstand ist der größte einzelne Hebel. Von 7.4 auf 8.3 ist ein anderes Vorhaben als von 5.3 auf 8.3. Jedes Jahr Warten macht den Sprung größer.

Wissen zugänglich machen

Wenn jemand bei Ihnen erklären kann, warum eine Sonderregel im Code steht, sparen wir das Rätselraten. Bei gewachsenem Code ist das ein spürbarer Teil des Aufwands.

Vorhandene Tests nennen

Auch unvollständige Tests helfen. Sie zeigen uns, welche Abläufe schon abgesichert sind und wo wir das Netz erst bauen müssen.

Abhängigkeiten kennen

Eine Liste der eingebundenen Pakete und Eigenbauten hilft früh. Bibliotheken, die es nicht mehr gibt, sind oft der größte Kostentreiber, und das klärt man besser vorher als mittendrin.



Unser Vorgehen

  1. 01

    Ersteinschätzung

    Kostenlos. Auch dann, wenn die ehrliche Antwort „lohnt sich nicht“ lautet.

  2. 02

    Analyse

    Abhängigkeiten, Testlage und Migrationsaufwand.

  3. 03

    Plan

    Schriftlich, mit Meilensteinen und Kosten.

  4. 04

    Umsetzung

    In Abschnitten, jeweils mit Tests.

  5. 05

    Übergabe

    Mit Dokumentation, auf Wunsch mit weiterlaufendem Support.

Häufig gestellte Fragen

Können Sie auch nur beraten, ohne die Migration zu übernehmen?

Ja. Manche Kunden wollen nur wissen, woran sie sind, und machen den Rest selbst.

Was, wenn wir mittendrin abbrechen wollen?

Wir arbeiten in Abschnitten. Nach jedem Abschnitt ist der Code lauffähig, Sie sitzen also nie auf einer halben Baustelle.

Übernehmen Sie Projekte, die schon jemand anderes angefangen hat?

Ja, das kommt häufiger vor als man denkt.

Wie lange dauert eine Migration?

Von wenigen Wochen bis mehrere Monate, je nach Versionsabstand, Testabdeckung, Fremdabhängigkeiten, Code-Qualität und Umfang.

Was passiert mit Bibliotheken, die es nicht mehr gibt?

Jedes eingebundene Paket muss den Sprung auf PHP 8 mitmachen. Wird eines nicht mehr gepflegt, ersetzen wir es durch einen aktuellen Nachfolger oder übernehmen die benötigte Funktion in Ihren Code. Solche Abhängigkeiten sind oft der größte Kostentreiber, deshalb klären wir sie ganz am Anfang.

Reicht ein Zwischenschritt auf PHP 8.0 oder 8.1?

Nein. Beide Versionen haben ihr Support-Ende bereits erreicht. Sie hätten die Arbeit gemacht und stünden trotzdem wieder ohne Sicherheitsupdates da. Sinnvolles Ziel ist eine aktuell gepflegte 8.x-Version.

Sollen wir zuerst den Server wechseln oder zuerst den Code migrieren?

Bei alten PHP-5-Projekten hängt beides zusammen, weil aktuelle Distributionen kein PHP 5 mehr ausliefern. Wir klären die Reihenfolge in der Analyse, damit Sie nicht zweimal umziehen.

Wir haben gar keine Tests. Geht das trotzdem?

Ja, das ist eher die Regel als die Ausnahme. Fehlende Tests machen eine Migration nicht unmöglich, sondern riskanter. Deshalb bauen wir zuerst eine Absicherung für die Abläufe, an denen bei Ihnen Geld hängt, und fassen erst danach den Code an.

PHP-Projekt zu migrieren?

Wir schätzen Ihr Vorhaben kostenlos ein, ehrlich und ohne Verpflichtung.

Ersteinschätzung anfragen