Serverumzug ohne Downtime: Wie man eine Legacy-Anwendung migriert
Der alte Server muss weg. Vielleicht läuft der Vertrag aus. Vielleicht ist die Hardware am Ende. Vielleicht will der neue Hoster einfach mehr bieten für weniger Geld. Der Grund ist selten das Problem. Das Problem ist die Frage danach: Wie bekommt man eine Anwendung, die seit zehn Jahren läuft und niemand mehr komplett versteht, auf einen neuen Server, ohne dass die Kunden etwas merken?
Ein Serverumzug ohne Downtime klingt für viele Entscheider wie ein Widerspruch. Entweder die Anwendung läuft, oder sie wird umgezogen. Bei Legacy-Software mit ihren gewachsenen Abhängigkeiten und fehlender Dokumentation wirkt die Vorstellung besonders unrealistisch. Zu Recht, wenn man den Umzug wie einen einmaligen Kraftakt am Wochenende plant. Mit der richtigen Reihenfolge ist er trotzdem machbar.
Was passiert, wenn der Umzug schiefgeht
Ein missglückter Serverumzug ist selten ein stiller Fehler. Er zeigt sich sofort und öffentlich.
Die Website ist nicht erreichbar, während DNS-Einträge sich weltweit unterschiedlich schnell aktualisieren. Formulare schreiben in die falsche Datenbank, weil zwei Systeme gleichzeitig aktiv waren. Bestellungen gehen verloren, weil die letzte Datenkopie vor dem Umschalten nicht mehr synchron war. Bei Anwendungen, die Kundendaten verarbeiten, ist das nicht nur ärgerlich, sondern auch ein Thema für die DSGVO.
Am teuersten wird ein missglückter Umzug meistens dann, wenn niemand einen Rückweg vorbereitet hat. Wer keinen Rollback-Plan hat, muss den fehlerhaften Zustand live reparieren, während Kunden zuschauen. Das kostet Nerven, Vertrauen und häufig auch Umsatz.
Warum Legacy-Anwendungen besondere Vorsicht brauchen
Bei einer modernen, containerisierten Anwendung ist ein Serverwechsel oft eine Frage von Minuten. Bei einer Legacy-Anwendung nicht.
Ältere Systeme haben häufig fest verdrahtete Pfade, Konfigurationen, die nur auf dem alten Server stimmen, oder Abhängigkeiten zu einer bestimmten PHP- oder Java-Version. Manche greifen auf lokale Dateien zu, die bei einer sauberen Migration ebenso mitwandern müssen wie die Datenbank. Ohne genaue Bestandsaufnahme übersieht man leicht eine Komponente, die erst nach dem Umschalten ausfällt, wenn schon niemand mehr genau hinsieht.
Deshalb beginnt jeder saubere Serverumzug mit einer Migrationscheckliste, die alle Komponenten der Anwendung erfasst: Dateien, Datenbanken, Cronjobs, externe Schnittstellen, Zertifikate.
So läuft ein Umzug ohne Ausfall in der Praxis ab
Ein Serverumzug ohne Downtime folgt keinem Zaubertrick. Er folgt einer Reihenfolge, die verhindert, dass der alte und der neue Server sich gegenseitig ins Gehege kommen.
Schritt 1: Parallelinfrastruktur aufbauen
Der neue Server wird aufgesetzt, während der alte weiterläuft. Betriebssystem, Webserver, PHP- oder Java-Version, alle Konfigurationen werden nachgebaut oder, wo sinnvoll, modernisiert. Wichtig ist dabei, dass die neue Umgebung noch nicht öffentlich erreichbar ist. Sie läuft still im Hintergrund und wird ausführlich getestet, bevor auch nur ein einziger Nutzer sie zu sehen bekommt.
Schritt 2: Daten synchronisieren
Jetzt beginnt der heikelste Teil. Die Datenmigration läuft in zwei Phasen. Zuerst wird eine vollständige Kopie der Datenbank und aller Dateien auf den neuen Server übertragen. Das kann je nach Datenmenge Stunden dauern und passiert ohne Zeitdruck, weil der alte Server dabei ungestört weiterarbeitet.
In der zweiten Phase folgt eine laufende Synchronisation der Änderungen, die zwischen der ersten Kopie und dem eigentlichen Umschalten noch passieren. Bestellungen, neue Nutzer, hochgeladene Dateien, alles muss auf dem neuen Server ankommen, bevor er live geht. Erst wenn beide Server denselben Datenstand haben, ist der nächste Schritt sicher.
Schritt 3: DNS-Umschaltung vorbereiten
DNS-Einträge bestimmen, welcher Server bei einem Seitenaufruf tatsächlich antwortet. Die Umschaltung selbst dauert nur Sekunden, aber sie verbreitet sich nicht überall gleichzeitig. Manche Nutzer landen noch stundenlang auf dem alten Server, weil ihr Internetanbieter alte DNS-Einträge zwischenspeichert.
Deshalb wird die sogenannte Time to Live (TTL), also die Speicherdauer eines DNS-Eintrags, schon Tage vor dem eigentlichen Umzug heruntergesetzt. Das sorgt dafür, dass die Umschaltung später schneller bei allen Nutzern ankommt. Zusätzlich bleibt der alte Server nach der Umschaltung noch eine Zeit lang aktiv und synchronisiert Daten zurück, damit Nutzer, die noch auf ihm landen, nicht mit veralteten Ständen arbeiten.
Schritt 4: Rollback vorbereiten
Bevor die Umschaltung passiert, steht fest, wie ein Rückzug aussehen würde. Der alte Server bleibt erreichbar, bis der neue sich über mehrere Tage im echten Betrieb bewährt hat. Sollte etwas auffallen, wird die DNS-Umschaltung einfach rückgängig gemacht, und der alte Server übernimmt wieder.
Ein Rollback-Plan ist kein Zeichen von Unsicherheit. Er ist der Unterschied zwischen einem kontrollierten Vorgehen und einer Hoffnung, dass schon nichts passiert.
Schritt 5: Nach dem Umzug beobachten
Direkt nach der Umschaltung braucht die Anwendung volle Aufmerksamkeit. Fehler-Logs, Ladezeiten, Formulareingänge und Zahlungsprozesse werden geprüft, nicht nur einmal, sondern über mehrere Tage. Erst wenn sich zeigt, dass alles stabil läuft, wird der alte Server abgeschaltet und die letzten Backups gesichert. An dieser Stelle zahlt sich eine solide Backup-Strategie nach der 3-2-1-Regel aus, weil eine letzte, unabhängige Sicherung des alten Systems immer sinnvoll ist, egal wie gut der Umzug lief.
Was den Aufwand bestimmt
Wie lange ein Serverumzug ohne Downtime dauert, hängt vor allem von der Codebasis ab. Eine Anwendung mit sauberer Trennung von Code, Konfiguration und Daten lässt sich in wenigen Tagen umziehen. Ein gewachsenes System mit fest verdrahteten Pfaden, fehlender Dokumentation und Jahre alten Abhängigkeiten braucht deutlich mehr Vorbereitung.
Wer sein System für einen Umzug auf einen Managed Server vorbereitet, sollte deshalb genug Zeit für die Bestandsaufnahme einplanen. Diese Phase entscheidet, ob der eigentliche Umzug ein ruhiger Vorgang wird oder eine Nacht voller Überraschungen.
Auch die Größe des Teams spielt eine Rolle. Ein Umzug lässt sich nicht nebenbei erledigen, während gleichzeitig der Tagesbetrieb weiterläuft. Jemand muss die Parallelinfrastruktur aufsetzen, die Datenübertragung überwachen und in der kritischen Phase rund um die Umschaltung erreichbar sein. Wer intern niemanden dafür freistellen kann, sollte diese Zeit bei einem externen Dienstleister fest einplanen, statt sie am Ende als Randnotiz zu behandeln.
Ein weiterer Faktor wird oft unterschätzt: die Kommunikation mit Kunden und Nutzern. Selbst ein technisch sauberer Umzug kann kurze Verzögerungen mit sich bringen, etwa wenn Caches sich neu aufbauen oder einzelne Funktionen in der Übergangsphase langsamer reagieren. Ein kurzer Hinweis vorab nimmt viel Druck aus der Situation, falls doch einmal etwas auffällt.
Ein Serverumzug muss nicht mit einem Ausfall bezahlt werden. Er braucht Vorbereitung, eine saubere Datensynchronisation und einen Rollback-Plan, der nie gebraucht werden soll, aber immer bereitsteht.
Sprechen Sie uns an. Das Erstgespräch ist kostenlos. Wir schauen uns Ihre Anwendung an und sagen Ihnen ehrlich, was ein Umzug ohne Ausfall für Ihr System bedeuten würde.
