Wir heben Runtime, Betriebssystem oder Datenbank auf eine aktuelle Version an oder ersetzen einzelne Teile. Für jeden Change planen wir vorher den Rückweg.
Rückweg bereit
- Test auf einer Kopie
- Rollback geplant
- Wartungsfenster
Was wir modernisieren
Runtime
PHP, Node.js und Java bekommen regelmäßig neue Versionen, ältere fallen aus dem Support. Für PHP 8.2 enden die Sicherheitsupdates am 31.12.2026, für Node.js 22 der Support am 30.04.2027. Mit der Runtime heben wir auch die Abhängigkeiten an und passen den Code an. Ein Umstieg von PHP 7 auf PHP 8 betrifft meist auch Framework und Bibliotheken.
Betriebssystem
Ein Release Upgrade planen wir als Neuaufbau. Der neue Server mit dem aktuellen Release entsteht neben dem alten, dann ziehen wir die Dienste um. Der alte Server bleibt als Rückweg stehen, bis der neue läuft.
Datenbank
PostgreSQL, MySQL/MariaDB und MongoDB haben eigene Supportenden, PostgreSQL 14 zum Beispiel am 12.11.2026. Bevor wir ein Upgrade in Produktion ausführen, testen wir es auf einer Kopie der Daten.
Einzelne Teile ablösen
Manche Teile lassen sich nicht mehr sinnvoll warten, etwa ein Modul ohne Hersteller oder eine Bibliothek ohne Nachfolger. Diese Teile ersetzen wir einzeln. Der Rest des Systems bleibt.
Alle Termine finden Sie im EOL Kalender.
Wie wir einen Change planen
Änderungen planen wir nach dem ITIL® Framework. Jeder Change geht je nach Risiko einen von drei Wegen.
- Standard Changes wiederholen sich und sind per Vorlage vorab genehmigt.
- Bei einem normalen Change bewerten wir das Risiko, planen den Rollback, holen die Freigabe der Change Authority ein und spielen ihn im Wartungsfenster ein.
- Im Notfall spielen wir den Change nach einer Eilfreigabe sofort ein und machen Review und Dokumentation danach.
Upgrades von Runtime, Betriebssystem oder Datenbank sind immer normale Changes. Den Rollback legen wir vorher fest. Mehr dazu auf der Seite Arbeitsweise.
Fahren Sie mit der Maus über einen Schritt oder tippen Sie ihn an. Hervorgehoben bleibt, was davor passiert und wie es danach weitergeht.
Behalten oder ablösen
Nicht jedes Altsystem braucht eine Ablöse. Wir entscheiden das mit Ihnen anhand von vier Punkten.
- ob es für Runtime, Framework und Betriebssystem noch Updates gibt, auch gegen Bezahlung
- wie oft Sie das System fachlich anpassen müssen
- ob Code und Betrieb dokumentiert sind oder nur noch im Kopf einer Person existieren
- was die Wartung in den nächsten Jahren kostet, verglichen mit einer Ablöse
Oft bleibt der Kern, und wir ersetzen einzelne Teile. Für diese Entscheidung empfehlen wir einen Legacy Check als Grundlage.
Daten migrieren
Große Datenbestände kopieren wir in Zeitfenstern und mit Wiederaufsetzpunkten. So können wir einen Lauf anhalten und später an derselben Stelle fortsetzen.
Danach vergleichen wir pro Tag, wie viele Datensätze im alten und im neuen System liegen. Eine passende Gesamtzahl allein beweist nichts, deshalb vergleichen wir auch die Inhalte.
Beim Löschen gehen wir in Batches vor, die ältesten Daten zuerst. So kommt die Replikation mit.
Erfahrung
Upgrades wie diese spielen wir laufend bei den 50+ IT Services ein, die wir betreuen. Welche Versionen bei unseren Kunden laufen, bleibt vertraulich.