Betriebssystem-Migration: Windows Server und Linux sicher modernisieren
Ihr Server läuft. Die Anwendungen laufen. Niemand beschwert sich. Warum also etwas ändern?
Weil das Betriebssystem darunter seit Monaten oder Jahren keine Sicherheits-Updates mehr erhält. Windows Server 2012, CentOS 7, Ubuntu 18.04 LTS: Alles End of Life. Eine Betriebssystem-Migration ist kein optionales Projekt. Sie ist ein Sicherheitsthema.
Dieser Artikel erklärt, welche Risiken entstehen, wenn Sie weiter warten, und wie eine Migration konkret aussieht.
Warum das Betriebssystem wichtiger ist als viele denken
Das Betriebssystem ist die Grundlage für alles, was auf einem Server läuft. Jede Anwendung, jede Datenbank, jedes Backup-Skript setzt auf dem Betriebssystem auf.
Wenn dieses Fundament nicht mehr gepflegt wird, entsteht ein Problem. Nicht sofort. Nicht laut. Aber verlässlich.
Sicherheitslücken im Betriebssystem werden öffentlich dokumentiert. In Datenbanken wie der NVD (National Vulnerability Database) können Angreifer nachlesen, welche Lücken in welcher Version stecken. Und welche Systeme deshalb angreifbar sind.
Die Frage ist nicht ob jemand diese Informationen nutzt, sondern wann.
Welche Betriebssysteme sind betroffen?
Die wichtigsten End-of-Life-Betriebssysteme, die heute noch produktiv laufen:
Windows Server 2012 / 2012 R2: Der erweiterte Support endete im Oktober 2023. Microsoft liefert keine kostenlosen Sicherheits-Updates mehr.
CentOS 7: Das beliebte Linux-System der Red-Hat-Familie erreichte im Juni 2024 sein End of Life. Millionen Server laufen weltweit noch darauf.
Ubuntu 18.04 LTS: Der Standardsupport lief im April 2023 aus. Wer keinen kostenpflichtigen Extended Security Maintenance Vertrag hat, läuft ohne Updates.
Debian 10 (Buster): Der reguläre Support endete im Juni 2024.
Wenn Ihre Infrastruktur eines dieser Systeme nutzt, haben Sie ein konkretes Sicherheitsproblem. Nicht theoretisch, sondern praktisch.
Was passiert wenn Sie die Migration aufschieben?
Ungepatchte Sicherheitslücken häufen sich an
Jeden Monat werden neue Schwachstellen in Betriebssystemkomponenten entdeckt. Für unterstützte Versionen werden Patches bereitgestellt. Für End-of-Life-Systeme nicht.
Die Lücken werden trotzdem dokumentiert. Angreifer scannen das Internet systematisch nach Systemen, die anfällig sind. Ein ungepatchtes CentOS-7-System ist gut sichtbar.
DSGVO-Verstöße durch veraltete Infrastruktur
Die DSGVO verlangt technische Schutzmaßnahmen, die dem Stand der Technik entsprechen. Ein Betriebssystem ohne Sicherheits-Updates entspricht nicht mehr dem Stand der Technik.
Im Fall eines Vorfalls werden Datenschutzbehörden genau diese Frage stellen: Warum lief das System auf einem nicht mehr unterstützten Betriebssystem? Eine überzeugende Antwort gibt es nicht.
Anwendungen werden instabil
Neue Softwareversionen setzen oft eine aktuelle Systemumgebung voraus. Wer PHP 8, Node.js oder Python in aktuellen Versionen auf CentOS 7 betreiben will, stößt schnell an Grenzen.
Der Kreislauf beginnt: Das System kann nicht aktualisiert werden, weil das Betriebssystem zu alt ist. Das Betriebssystem kann nicht migriert werden, weil dafür keine Ressourcen eingeplant sind. Während dessen wachsen die technischen Schulden.
Support-Verträge greifen nicht mehr
Viele Managed-Hosting-Anbieter und Softwarehersteller schließen Support für End-of-Life-Betriebssysteme aus ihren Verträgen aus. Wenn etwas schiefgeht, sind Sie allein.
Die drei Optionen bei veralteten Betriebssystemen
Option 1: In-Place-Upgrade
Manche Betriebssysteme unterstützen ein direktes Upgrade auf die nächste Version. Ubuntu 18.04 lässt sich beispielsweise auf 20.04 oder 22.04 upgraden, ohne den Server neu aufzusetzen.
Das klingt einfach. Ist es oft auch. Aber es gibt Risiken: Abhängigkeiten die nach dem Upgrade nicht mehr funktionieren, Konfigurationsdateien die überschrieben werden, Dienste die nicht automatisch starten.
Ein In-Place-Upgrade ohne vorheriges Testing ist keine gute Idee. Mit einer Testumgebung ist es ein vertretbarer Weg.
Option 2: Neuen Server aufsetzen und Migration planen
Der sicherere Weg: Einen neuen Server mit dem aktuellen Betriebssystem aufsetzen, alle Anwendungen dorthin übertragen, testen, und dann umschalten.
Das dauert länger als ein In-Place-Upgrade. Dafür ist das Risiko geringer. Wenn etwas schiefgeht, läuft der alte Server noch. Sie haben Zeit zu korrigieren.
Dieser Ansatz passt besonders gut für komplexe Anwendungsumgebungen. Er erlaubt eine kontrollierte Migration ohne Produktionsrisiko.
Option 3: Cloud-Migration nutzen
Ein Wechsel des Betriebssystems ist oft der richtige Moment, um auch die Infrastruktur zu überdenken. Manche Legacy-Workloads passen gut in eine Cloud-Umgebung. Andere nicht.
Was für Ihre Situation sinnvoll ist, hängt von den Anforderungen Ihrer Anwendungen ab: Datenschutz, Latenz, Kosten, Compliance. Eine pauschale Empfehlung gibt es hier nicht.
Lesen Sie dazu auch unseren Artikel über Weiterbetrieb oder Migration bei End-of-Life-Servern.
Wie eine Betriebssystem-Migration konkret abläuft
Phase 1: Inventarisierung und Analyse
Bevor irgendetwas migriert wird, muss klar sein, was auf dem Server läuft. Welche Anwendungen, welche Dienste, welche Abhängigkeiten.
Diese Liste ist die Grundlage für alles weitere. Wer sie überspringt, merkt das spätestens wenn nach der Migration ein kritischer Dienst nicht mehr startet.
Phase 2: Testumgebung aufbauen
Ein identisches oder möglichst ähnliches Zielsystem aufsetzen. Alle Anwendungen und Dienste dort installieren und konfigurieren. Alles testen.
Automatisierte Tests helfen dabei. Falls keine Tests vorhanden sind, sollten zumindest die kritischsten Funktionen manuell geprüft werden.
Phase 3: Datenmigration
Datenbanken, Konfigurationsdateien, Uploads, Logs: Alles was auf dem alten System liegt und auf dem neuen gebraucht wird, muss übertragen werden.
Fuer Datenbanken gibt es standardisierte Export- und Import-Wege. Fuer Konfigurationsdateien gilt: Nie blind kopieren. Die neue Betriebssystemversion kann andere Standardpfade oder Syntax-Anforderungen haben.
Phase 4: DNS-Umstellung und Cutover
Der Moment der Umstellung ist der kritischste Punkt. Mit einer Modernisierung ohne Betriebsausfall lässt sich dieser Moment entschärfen: DNS-TTL vorher niedrig setzen, beide Systeme parallel betreiben, erst nach erfolgreicher Überprüfung auf das neue System umschalten.
Phase 5: Monitoring nach der Migration
Nach dem Cutover beginnt die kritische Beobachtungsphase. Gibt es unerwartete Fehler? Laufen alle Dienste stabil? Werden Logs korrekt geschrieben?
Mindestens 48 Stunden erhöhte Aufmerksamkeit nach einer Migration ist keine Übertreibung. Es ist gute Praxis.
Versteckte Abhängigkeiten bei Legacy-Systemen
Das größte Risiko bei Betriebssystem-Migrationen von Legacy-Systemen sind nicht die bekannten Anwendungen. Es sind die vergessenen.
Auf einem Server, der seit Jahren produktiv läuft, findet man oft: Cron-Jobs die niemand dokumentiert hat. Skripte die automatisch E-Mails versenden oder Backups anlegen. Dienste die beim Start des Betriebssystems mitgestartet werden, aber in keiner Dokumentation auftauchen.
Diese Abhängigkeiten sieht man nur, wenn man sich die Zeit nimmt, den laufenden Server gründlich zu analysieren. Ein ps aux, ein crontab -l, ein Blick in /etc/cron.d und die Systemd-Units: Das dauert ein paar Stunden. Es verhindert Wochen an Fehlersuche.
Wenn Sie dabei Unterstützung brauchen, lesen Sie mehr über unser Angebot im Bereich Managed Hosting für Legacy-Projekte.
Windows Server Migration: Was anders ist
Bei Windows Server Migrationen gelten andere Spielregeln als bei Linux.
Active Directory, Gruppenrichtlinien, SQL-Server-Instanzen, IIS-Konfigurationen: Diese Komponenten haben ihre eigenen Migrations-Anforderungen. Ein Domänencontroller kann nicht einfach kopiert werden.
Microsoft bietet für Windows Server 2012-Nutzer eine kostenpflichtige Option: Extended Security Updates (ESU) bis Oktober 2026. Das kauft Zeit, loest das Problem aber nicht dauerhaft.
Wer Windows Server migriert, sollte außerdem prüfen, ob die laufenden Anwendungen mit der neuen Version kompatibel sind. Aeltere .NET-Anwendungen können auf Windows Server 2022 andere Anforderungen haben als erwartet.
Betriebssystem-Migration: Häufige Fehler
Kein Rollback-Plan: Wenn die Migration auf dem neuen System scheitert, muss man auf das alte zurueck können. Wer den alten Server vorher abschaltet, hat diesen Plan nicht.
Kein Testlauf: Direkt in der Produktion zu migrieren ist das größte Risiko. Ein Testlauf auf einem Spiegelsystem kostet Zeit, spart aber Nerven.
Falsche Priorisierung: Nicht alles muss gleichzeitig migriert werden. Unkritische Dienste zuerst, kritische Anwendungen zuletzt. So sammelt man Erfahrung, bevor es darauf ankommt.
SSL-Zertifikate vergessen: Neue Server brauchen neue Zertifikate oder müssen bestehende übernehmen. Ein abgelaufenes Zertifikat nach der Migration ist ein häufiger und ärgerlicher Fehler.
Wann ist der richtige Zeitpunkt für die Migration?
Jetzt. Falls Sie noch auf einem End-of-Life-Betriebssystem laufen.
Der Aufwand ist planbar. Die Risiken durch eine Migration sind beherrschbar. Die Risiken durch Nichtstun wachsen jeden Tag.
Lesen Sie mehr dazu in unserem Artikel über die End-of-Life-Risiken veralteter Server-Betriebssysteme.
Fazit: Betriebssystem-Migration ist kein IT-Luxus
Es ist Grundpflege. Wer ein Haus hat, ersetzt irgendwann das Dach. Nicht weil es akut tropft, sondern weil man weiß, dass es irgendwann tropfen wird.
Ein Betriebssystem ohne Support ist ein Dach mit bekannten Schwachstellen. Und einer öffentlichen Liste, wo die Löcher sind.
Die gute Nachricht: Eine Betriebssystem-Migration ist ein lösbares Problem. Mit guter Planung, einer Testumgebung und dem richtigen Ablauf geht sie ohne Überraschungen durch.
Sprechen Sie uns an. Das Erstgespräch ist kostenlos. Wir schauen uns Ihre Infrastruktur an und sagen Ihnen, was als nächstes sinnvoll ist.
