Ablösung in einem Jahr: Lohnt sich das PHP-Upgrade noch?

Die Frage klingt nach Technik, ist aber eine Rechnung mit drei Unbekannten: Wie lange läuft dein Altsystem wirklich noch, bleibt es bis dahin abgesichert, und was steht auf dem Spiel, wenn in dieser Zeit etwas passiert? Stand dieses Artikels: 6. November 2026.

Vier Wege für das letzte Jahr

• Investieren. PHP und, falls nötig, Framework oder CMS auf eine unterstützte Version bringen. Das Altsystem bleibt bis zum letzten Tag abgesichert, auch wenn sich die Ablösung verschiebt.
• Minimal halten. Nur noch Sicherheitsupdates, Fehlerkorrekturen und Pflichtänderungen, etwa bei QR-Rechnung oder Mailversand. Keine neuen Funktionen mehr.
• Einfrieren. Ab einem Stichtag keine Änderungen mehr, ausser Sicherheits- und Notfallkorrekturen. Neue Wünsche gehen nur noch ins neue System. Einfrieren ist nur sicher, solange von irgendwoher Sicherheitsupdates kommen.
• Umstellen. Endet die Absicherung früher als das Altsystem, ziehst du die Umstellung vor oder löst einzelne Teile zuerst ab, etwa den öffentlich erreichbaren Bereich. Wie das schrittweise geht, zeigt das Strangler-Fig-Prinzip im Artikel Modernisieren oder neu bauen.

Die Wege schliessen sich nicht aus. Typisch ist die Reihenfolge: zuerst investieren oder eine Brücke schlagen, dann minimal halten, rund drei Monate vor der Umstellung einfrieren.

Investitionsmatrix nach Restlaufzeit

Die Matrix ist eine Faustregel für den häufigsten Fall: Deine PHP-Version läuft vor dem Abschalttermin aus oder ist schon ausgelaufen, wie PHP 8.1 am 31. Dezember 2025. PHP 8.2 folgt am 31. Dezember 2026. Bleibt deine Version bis zur Abschaltung abgesichert, brauchst du kein Upgrade: minimal halten und rechtzeitig einfrieren genügt.

Restlaufzeit heisst dabei: bis zu dem Tag, an dem das Altsystem abgeschaltet wird, nicht bis zum Go-live des neuen. Dazwischen liegen Parallelbetrieb und Hypercare.

Restlaufzeit bis zur Abschaltung	Kleiner Schritt, z. B. PHP 8.1 oder 8.2 auf 8.4	Grosser Schritt, z. B. PHP 7.4 auf 8.4 samt Framework
Unter 6 Monaten	Upgrade, wenn es vor dem Freeze fertig wird. Sonst einfrieren und eine Brücke bis zur Abschaltung nutzen	Einfrieren, Brücke, Zugriff einschränken. Ein Upgrade wäre vor der Abschaltung kaum fertig
6 bis 12 Monate	Upgrade, es dauert oft nur wenige Tage. Danach minimal halten	Brücke, wenn eine belegt bis nach der Abschaltung reicht. Sonst Upgrade oder Teile früher umstellen
12 bis 24 Monate	Upgrade	Upgrade, ausser eine belegte Brücke reicht sicher bis nach der Abschaltung
Über 24 Monate oder kein fester Termin	Upgrade, wie ohne Ablösung	Upgrade, wie ohne Ablösung

Drei Dinge verschieben die Rechnung:

• Verzögerung. Rechne mit dem Abschalttermin plus Reserve. Reicht eine Brücke genau bis zum geplanten Termin, reicht sie bei der ersten Verschiebung nicht mehr.
• Was auf dem Spiel steht. Ein öffentlich erreichbarer Shop mit Kundenkonten und Zahlungen ist ein anderes Risiko als ein internes Werkzeug, das nur im Firmennetz läuft.
• Was ohnehin entsteht. Tests für die wichtigsten Abläufe, die du für ein Upgrade brauchst, helfen später im Parallelbetrieb, das neue System mit dem alten zu vergleichen.

Wie gross dein Schritt ist, ordnet der Artikel PHP-Upgrade planen je Ausgangsversion und Framework ein. Welche Fristen bis 2029 anstehen, zeigt der End-of-Life-Kalender.

Welche Brücken gibt es bis zur Umstellung?

Eine Brücke verlängert die Sicherheitsupdates für eine Version, die offiziell ausgelaufen ist. Für PHP 8.1 und älter erscheinen keine offiziellen Releases mehr. Korrekturen kommen nur noch als Backports, je nachdem, was dein Hoster, deine Linux-Distribution oder ein kommerzieller Anbieter einspielt. Bei den kritischen PHP-Lücken vom Oktober 2026 hing genau daran, ob eine Anwendung auf PHP 8.1 geschützt war. Wie lange dein Hoster alte Versionen anbietet und ob er dafür einen Aufpreis verlangt, steht in der Hoster-Tabelle.

Die Angaben stammen von den Herstellern und Projekten selbst, abgerufen am 6. November 2026. Die Links stehen in den Quellen unten.

Brücke	Für wen	Frist laut Hersteller	Quelle
Alte PHP-Version beim Hoster, teils mit Backports oder gegen Aufpreis	Shared Hosting	Je nach Hoster sehr unterschiedlich. Für PHP 8.1 und älter nur geschützt, wenn der Hoster Backports einspielt	Hoster-Tabelle im Artikel PHP End of Life
PHP 8.1 aus Ubuntu 22.04 LTS	Eigener Server mit Ubuntu 22.04	Standard-Sicherheitswartung bis Mai 2027, mit Ubuntu Pro (ESM) bis Mai 2032. Die Oktober-Lücken hat Canonical am 21. Oktober 2026 auch für PHP 8.1 geschlossen (USN-8948-1)	Canonical
PHP 8.2 aus Debian 12	Eigener Server mit Debian 12	Debian LTS bis 30. Juni 2028. Die Oktober-Lücken hat das LTS-Team mit DLA-4848-1 geschlossen	Debian
Zend PHP LTS	Eigener Server	PHP 7.4 bis Dezember 2026, PHP 8.1 bis Dezember 2027. Für PHP 8.2 angekündigt, ohne Enddatum. Kostenpflichtig	Zend by Perforce
TuxCare Endless Lifecycle Support	Eigener Server	PHP 5.2 bis 7.4, ohne festes Enddatum. Lässt die Nachfrage nach, kündigt TuxCare das Ende ein Jahr im Voraus an. Kostenpflichtig	TuxCare
TYPO3 ELTS	TYPO3 10.4, 11.5 und 12.4	10.4 bis 30.04.2027, 11.5 bis 31.10.2028, 12.4 bis 30.04.2030. Das vierte Jahr gibt es jeweils nur über TYPO3-Partner, für 10.4 läuft es seit 1. Mai 2026. ELTS für 9.5 ist am 30.09.2025 ausgelaufen. Kostenpflichtig	TYPO3 GmbH
OpenMage LTS	Magento 1	Kein festes Enddatum: Version 20.x bekommt Patches bis zwei Jahre nach Erscheinen von 21.x. Ende Oktober 2026 ist 21.0 als dritte Beta erschienen. Ab 20.14 PHP 8.1 und neuer, PHP 8.4 und 8.5 mit Warnungen	OpenMage
Drupal 7 Extended Security Support	Drupal 7	Kein festes Enddatum. Die Drupal Association zertifiziert dafür HeroDevs und Tag1 Consulting, Tag1 sagt Updates zu, solange es möglich ist. Kostenpflichtig	Drupal Association, Tag1
Abschotten	Interne Anwendungen	Keine Frist, ersetzt aber keine Updates. Laut BACS den Zugriff auf die tatsächlich benötigten Personen und Systeme beschränken, bei kritischen Anwendungen eine vorübergehende Trennung vom Internet prüfen	BACS

Drei Dinge gehen bei Brücken oft vergessen:

• Eine Brücke deckt nur ihre Schicht ab. TYPO3 ELTS sichert TYPO3, nicht PHP. TYPO3 10.4 läuft laut TYPO3 auch mit ELTS nur auf PHP 7.2 bis 7.4, und PHP 7.4 bekommt seit dem 28. November 2022 keine offiziellen Updates mehr. Ohne Backports für PHP bleibt die Lücke darunter offen. TYPO3 11.5 läuft bis PHP 8.3, TYPO3 12.4 bis PHP 8.4.
• Ein Container ist keine Brücke. Korrigierte offizielle Docker-Images gab es nach den Oktober-Lücken nur für PHP 8.2 bis 8.5. Ein Container auf PHP 8.1 bleibt verwundbar, auch wenn er neu gebaut wird.
• Jede Brücke hat ein Datum. Trag ihr Ende in denselben Kalender wie den Abschalttermin. Verschiebt sich die Umstellung, siehst du sofort, ob die Brücke noch reicht.

Fahrplan: 12 Monate vor bis 12 Monate nach der Umstellung

T steht für den Umstellungstag, an dem das neue System die Arbeit übernimmt. Der Fahrplan beschreibt, was in dieser Zeit mit dem Altsystem passiert. Wie die Daten vollständig mitkommen, steht im Artikel Daten aus dem Altsystem mitnehmen.

Zeitpunkt	Was am Altsystem passiert
T−12 bis T−9 Monate	Entscheiden. Abschalttermin festlegen, PHP-, Framework- und Hoster-Fristen danebenlegen, Upgrade oder Brücke wählen. Klären, wer bis zur Abschaltung für das Altsystem zuständig ist
T−9 bis T−6 Monate	Absichern. Upgrade oder Brücke umsetzen, Backups ausserhalb des Servers ablegen, die Wiederherstellung einmal testen, Zugänge einsammeln. Alle Abläufe, Schnittstellen und Cronjobs auflisten, die das neue System übernehmen muss
T−6 bis T−3 Monate	Minimal halten und proben. Nur noch Sicherheitsupdates und Pflichtänderungen. Probeläufe der Datenmigration, Kriterien für Go oder No-Go festlegen, das Umstellungs-Runbook schreiben
Ab T−3 Monate	Freeze. Keine Änderungen mehr am Altsystem, ausser Sicherheits- und Notfallkorrekturen. Jede Ausnahme festhalten und im neuen System nachziehen
T−6 Wochen bis T	Parallelbetrieb und Generalprobe. Das neue System mit einer aktuellen Kopie der Daten laufen lassen und die Ergebnisse vergleichen. Das Runbook einmal vollständig durchspielen, mit Zeitmessung und Rückweg
T	Umstellung nach Runbook. Go oder No-Go, Altsystem auf Nur-Lesen, letzter Datenabgleich, umschalten, prüfen. Bis zu einem festgelegten Zeitpunkt bleibt der Rückweg offen
T bis T+4 Wochen	Hypercare. Fehlerlogs, Bestellungen, Mails und Schnittstellen täglich prüfen, Meldungen aus dem Team sofort aufnehmen. Das Altsystem bleibt schreibgeschützt und abgesichert verfügbar
T+1 bis T+3 Monate	Stabilisieren. Restfehler beheben, den ersten Monatsabschluss im neuen System begleiten, Weiterleitungen und Schnittstellen kontrollieren
T+3 bis T+12 Monate	Abschalten. Sobald die wichtigen Abschlüsse im neuen System gelaufen sind: lesbares Archiv anlegen, Altsystem abschalten, seine Zugänge sperren, sein Hosting kündigen, nicht mehr benötigte Kopien löschen

Freeze: was eingefroren wird und was nicht

Freeze heisst: keine neuen Funktionen, keine Umbauten, keine Experimente im Altsystem. Es heisst nicht: keine Sicherheitsupdates. Wird während des Freeze eine kritische Lücke bekannt, gehört sie trotzdem geschlossen, sonst friert die Lücke mit ein. Leg fest, wer eine Ausnahme freigibt, und halte jede Ausnahme fest, damit sie im neuen System nicht fehlt.

Parallelbetrieb: vergleichen statt hoffen

Im Parallelbetrieb laufen beide Systeme mit denselben Daten. Entscheidend ist nicht, dass das neue System startet, sondern dass es dieselben Ergebnisse liefert: Rechnungsbeträge, Lagerbestände, Exporte, Mails an Kunden. Jede Abweichung ist entweder ein Fehler im neuen System oder ein Sonderfall im alten, den niemand aufgeschrieben hat. Meist genügt es, Kopien der echten Daten durch beide Systeme laufen zu lassen, statt dein Team alles doppelt erfassen zu lassen. Ein Umstieg ohne Parallelbetrieb verlagert alle Risiken auf einen einzigen Tag.

Umstellungs-Runbook: der Tag auf einer Seite

Das Runbook beschreibt den Umstellungstag Schritt für Schritt, jeweils mit Uhrzeit, zuständiger Person und Prüfung:

1. Go oder No-Go nach den vorher festgelegten Kriterien.
2. Kunden und Mitarbeitende informieren, Altsystem auf Nur-Lesen stellen.
3. Letztes Backup des Altsystems ziehen, letzten Datenabgleich fahren.
4. Umschalten: DNS, Weiterleitungen, Schnittstellen, geplante Aufgaben.
5. Prüfen: Anmeldung, Bestellung, Formulare, Mailversand, Zahlungen.
6. Spätester Zeitpunkt für den Rückweg, und wer ihn auslöst.

Was nicht im Runbook steht, wird am Umstellungstag improvisiert.

Hypercare: die ersten Wochen danach

In der Hypercare begleitet jemand das neue System enger als im Alltag. Manche Fehler zeigen sich erst in seltenen Abläufen, etwa beim ersten Monatsabschluss oder bei einer Schnittstelle, die nur nachts läuft. Kläre vorher, wer in dieser Zeit erreichbar ist, und lass das Altsystem schreibgeschützt und abgesichert stehen, bis der Rückweg nicht mehr gebraucht wird.

Darf das Altsystem bis zur Ablösung ungepatcht weiterlaufen?

Solange das Altsystem Personendaten bearbeitet, etwa von Kunden, Bestellungen oder Mitarbeitenden, gilt das Datenschutzgesetz bis zum letzten Tag. Art. 8 DSG verlangt von deiner Firma und von allen, die in ihrem Auftrag Daten bearbeiten, eine «dem Risiko angemessene Datensicherheit». Die Datenschutzverordnung konkretisiert das in Art. 1 bis 3: Die Massnahmen sind über die gesamte Bearbeitungsdauer zu überprüfen (Art. 1 Abs. 5 DSV), und Art. 3 Abs. 2 lit. f DSV nennt ausdrücklich, dass Betriebssysteme und Anwendungssoftware «stets auf dem neusten Sicherheitsstand gehalten und bekannte kritische Lücken geschlossen werden». Der Entscheid für ein neues System ändert daran nichts, solange das alte noch Personendaten bearbeitet. Was das für deinen Fall konkret heisst, klärst du mit einer Fachperson für Datenschutz. Dieser Abschnitt ist keine Rechtsberatung.

Wer kümmert sich bis zur Abschaltung?

Im letzten Jahr fühlt sich oft niemand mehr für das Altsystem zuständig: Der neue Anbieter baut das neue System, der bisherige Entwickler ist weg oder hat das Projekt schon abgegeben. Kläre deshalb früh, wer Updates einspielt, die Mails des Hosters liest und am Umstellungstag den Rückweg auslösen darf. Wie sich das zwischen Hoster, Entwickler und deiner Firma aufteilt, zeigt der Artikel Wer ist zuständig. Fehlt dir die Grundlage für den Entscheid zwischen Upgrade und Brücke, klärt das Übernahme-Assessment, wie gross der Schritt für deine Anwendung wirklich ist.