Es gibt eine Sorte Software, über die niemand Konferenzvorträge hält: die Warenwirtschaft von 2009, das Kundenportal von 2011, der Shop, den eine Agentur gebaut hat, die es nicht mehr gibt. Ein erstaunlicher Teil davon läuft auf Zend Framework 1. Heute, in Produktion, mit Umsatz dahinter.
Zend Framework 1 hat am 28. September 2016 sein Supportende erreicht. Seit fast zehn Jahren erscheinen keine Korrekturen mehr, auch keine sicherheitsrelevanten. Dieser Artikel ist für alle, die so ein System verantworten und wissen wollen, wo sie stehen: was das Supportende wirklich bedeutet, was Community-Forks leisten, warum es kein Migrationswerkzeug gibt und welche drei Wege ehrlich sind. Wer schon weiß, dass er weg will, findet auf der Seite zur Zend-Framework-Migration den konkreten Einstieg.
Ich schreibe das nicht als Zaungast: Ich habe Zend Framework zu der Zeit eingesetzt, als es aktuell war, und löse heute Systeme ab, die darauf gebaut wurden.
Warum das 2026 noch läuft
Zend Framework 1 erschien 2007 und war für Jahre eine der naheliegendsten Antworten auf die Frage, wie man in PHP professionell baut. Agenturen und interne Teams haben darauf Buchungssysteme, Portale, Shops und Verwaltungen gesetzt. Das waren keine Experimente, sondern Geschäftsanwendungen, und genau deshalb leben sie noch: Sie funktionieren. Software stirbt nicht am Alter, sie stirbt an fehlender Nachfrage, und die Nachfrage nach einer funktionierenden Warenwirtschaft endet nicht mit dem Framework darunter.
Dazu kommt der menschliche Teil. Die Agentur von damals existiert nicht mehr oder macht längst etwas anderes. Die Entwickler, die das System kannten, sind zwei Arbeitgeber weiter. Was bleibt, ist ein System mit einem Bus-Faktor nahe null, das niemand mehr anfassen will. „Never touch a running system" wird zur Strategie, ohne dass sie je jemand beschlossen hätte.
Ein Missverständnis hält das oft zusätzlich am Leben. Wer heute nach Zend Framework sucht, liest vom Übergang zu Laminas: Das Projekt wird seit Anfang 2020 unter neuem Namen fortgeführt, und für die Versionen 2 und 3 gibt es dorthin einen geordneten Weg. Das klingt beruhigend, gilt aber nur für ZF2 und ZF3. Zend Framework 1 war zu diesem Zeitpunkt schon über drei Jahre am Ende seines Supports angekommen. Der Laminas-Übergang hat für ZF1 nichts verbessert und nichts verschlechtert; er hat damit schlicht nichts zu tun.
Was seit dem 28. September 2016 fehlt
Am 29. September 2016 war keine ZF1-Anwendung unsicherer als am Tag davor. So funktioniert ein Supportende nicht. Es bedeutet etwas Schleichenderes: Jede Schwachstelle, die seither in Framework-Code gefunden wird, bleibt offen, und niemand ist mehr dafür zuständig, sie überhaupt zu suchen. Die Prüfungslast liegt seither vollständig bei Ihnen, ohne dass es jemand ausgesprochen hätte.
Das zweite Problem ist die Kopplung an die Sprache. ZF1-Anwendungen hängen fast immer an alten PHP-Versionen, oft an solchen, die selbst keine Sicherheitsupdates mehr bekommen. Das ist ein doppeltes Supportende: verwaistes Framework auf verwaister Sprachversion. Das PHP-Upgrade wäre fällig, aber das Framework steht im Weg, und so altern beide gemeinsam weiter.
Das dritte ist das Ökosystem. ZF1 stammt aus der Zeit vor Composer. Die Bibliotheken und Erweiterungen von damals sind so verwaist wie das Framework selbst, und die Konventionen, mit denen ZF1 arbeitet, gibt es später nirgends mehr. Jeder Entwickler, der das System übernimmt, lernt Dinge, die er nie wieder brauchen wird, und der Markt an Leuten, die sie schon können, schrumpft jedes Jahr.
Und schließlich der Teil, der nicht technisch ist: Irgendwann fragt jemand nach. Ein Audit, eine Cyberversicherung, ein Kunde mit Sicherheitsfragebogen, ein Käufer in einer Due Diligence. „Unser Framework hat seit 2016 keinen Support" ist dann kein Entwicklerthema mehr, sondern ein Geschäftsrisiko, wie es technische Schulden am Ende immer werden. Die unangenehmste Eigenschaft dieses Risikos: Es wird nicht durch ein Ereignis sichtbar, sondern durch eine Frage, und den Zeitpunkt der Frage bestimmen andere.
Was Community-Forks leisten und was nicht
Wer sich mit dem Thema beschäftigt, stößt schnell auf Community-Forks wie zf1-future, die den ZF1-Code auf neueren PHP-Versionen lauffähig halten. Das ist ehrenwerte und nützliche Arbeit, und sie löst ein echtes Problem: Sie entkoppelt die PHP-Frage von der Framework-Frage. Eine Anwendung, die dank Fork auf einer gepflegten PHP-Version läuft, hat eine der beiden Supportlücken geschlossen und Zeit gekauft.
Gekauft, nicht geschenkt. Ein Fork macht aus einem beendeten Framework kein gewartetes Produkt. Es gibt keine Organisation, die Sicherheitszusagen gibt, keinen Veröffentlichungszyklus, auf den man Verträge bauen kann, und keine Garantie, dass die Handvoll Freiwilliger in fünf Jahren noch da ist. Die Architektur von 2007 bleibt die Architektur von 2007, der Personalmarkt bleibt derselbe, und im Audit steht statt „Framework ohne Support" jetzt „Community-Fork eines 2016 beendeten Frameworks". Das ist besser, aber es ist keine Antwort.
Ein Fork ist ein Überbrückungskredit: genau richtig, um nicht unter Zeitdruck entscheiden zu müssen, und gefährlich, sobald man ihn für die Tilgung hält.
Warum es kein Migrationswerkzeug gibt
Für ZF2 und ZF3 existiert ein offizielles Werkzeug, das die Migration nach Laminas weitgehend mechanisch erledigt: Namensräume und Paketnamen werden im gesamten Bestand ersetzt, übrig bleibt Handarbeit an den Rändern. Das Werkzeug deckt laut seiner eigenen Dokumentation ausdrücklich die Versionen 2 und aufwärts ab.
Diese Grenze ist keine Nachlässigkeit, sie ist technisch begründet. ZF1 stammt aus der Zeit vor Composer, bringt ein eigenes MVC, eine eigene Datenbankschicht und eigene Konventionen mit, für die es in der heutigen PHP-Welt kein Gegenstück gibt. Es gibt kein Ziel, das „dasselbe in neu" wäre und in das ein Werkzeug automatisch übersetzen könnte. Deshalb ist schon das Wort „ZF1-Migration" irreführend: Was bei ZF2 eine Migration ist, ist bei ZF1 eine Ablösung. Wer Ihnen für ZF1 eine mechanische Migration verspricht, hat entweder Ihre Anwendung nicht angesehen oder benutzt das Wort anders als Sie.
Die drei ehrlichen Wege
Aus meiner Sicht gibt es genau drei Wege, mit einer ZF1-Anwendung umzugehen, die man vor sich selbst und vor einem Audit vertreten kann.
Erstens: bewusst stehen lassen. Das ist eine legitime Entscheidung, wenn sie eine Entscheidung ist und kein Zustand. Dazu gehört, das Risiko aufzuschreiben und zu mindern: die Anwendung so weit wie möglich von außen unerreichbar machen, die PHP-Frage über einen Fork oder eine Zwischenversion entschärfen, überwachen, was hineingeht und herauskommt, und Kriterien festlegen, bei deren Eintreten der Zustand endet. Der Unterschied zwischen dieser Variante und dem, was die meisten tun, ist genau ein Dokument, aber dieses Dokument ändert alles: Es macht aus einem blinden Fleck eine Risikoentscheidung mit Ablaufdatum.
Zweitens: schrittweise ablösen. Das ist in den meisten Fällen der richtige Weg, und er funktioniert nach dem Strangler-Fig-Muster: Eine Weiche vor der Anwendung leitet einen Bereich nach dem anderen auf einen gepflegten Stand um, das Alte schrumpft, bis es verschwindet. Vor dem ersten Eingriff entsteht ein Netz aus Characterization Tests, das festhält, was das System heute tut, denn Tests hat eine ZF1-Anwendung so gut wie nie. Und die PHP-Version wird getrennt vom Framework gewechselt, nie gleichzeitig: Wer beides auf einmal anfasst, weiß bei jedem Fehler nicht mehr, woher er kommt. Jeder Schritt geht einzeln produktiv und lässt sich einzeln zurückdrehen. Es gibt keinen Moment, in dem alles von einem großen Wurf abhängt.
Drittens: neu bauen, in einem Zug. Bei einer kleinen, scharf umrissenen Anwendung, deren Verhalten vollständig bekannt ist, kann das der kürzeste Weg sein. Bei allem anderen gilt, was ich über Full-Rewrites geschrieben habe: Der Neubau muss Verhalten nachbilden, das niemand vollständig kennt, er liefert monatelang nichts, und das alte System läuft währenddessen weiter und verändert sich. Die Fälle, in denen ein Neubau in einem Zug die richtige Antwort auf ZF1 ist, sind deutlich seltener als die Angebote, die ihn versprechen.
Wie der Anfang aussieht
Egal welcher der drei Wege es wird: Der erste Schritt ist derselbe, und er ist klein. Zuerst braucht es eine Einordnung. Welche Version steckt wirklich in der Anwendung, wie sauber ist die Grenze zwischen Framework-Code und eigenem Code, welche Abhängigkeiten sind verwaist, wo sitzt eigener Code auf Framework-Interna. Aus dieser Bestandsaufnahme ergibt sich, was eine Ablösung kosten würde und in welcher Reihenfolge sie liefe, mit Schritten, die einzeln produktiv gehen. Erst danach ist eine Zahl seriös. Jede Zahl davor ist geraten, denn zwischen einer sauber geschichteten ZF1-Anwendung und einer, in der Geschäftslogik in Controllern und Views verteilt liegt, liegen Größenordnungen.
Dringlicher wird die Sache immer aus denselben vier Richtungen: Die PHP-Version darunter fällt aus dem Support. Ein Audit oder eine Zertifizierung steht an. Der letzte Mensch, der das System kennt, kündigt. Oder neue Anforderungen stauen sich, weil niemand mehr wagt, das System zu ändern. Wer eine dieser vier Bewegungen bei sich beobachtet, sollte die Einordnung machen, bevor die Frage von außen kommt, denn dann bestimmt noch er selbst das Tempo.
Zend Framework 1 war gute Software. Die Anwendungen, die darauf laufen, sind es oft heute noch. Genau deshalb verdienen sie etwas Besseres als die beiden Extreme, zwischen denen sie meist hängen: jahrelanges Wegsehen oder ein Neubau-Angebot mit sieben Stellen. Der Weg dazwischen ist unspektakulär, schrittweise und seit Jahren erprobt. Er beginnt damit, dass jemand hinsieht.
