Aus der Garage: Eine Live-Website umziehen, Seite für Seite

Der Umzug einer Live-Website hat einen gefürchteten Moment: die Nacht, in der man umschaltet. Alter Server aus, neuer an, DNS umgebogen, Daumen drücken. Wir haben diesen Moment abgeschafft. Der Umzug lief Seite für Seite, im laufenden Betrieb, ohne einen einzigen Stichtag.

Aufgebockt

Für ein Kundenprojekt sollten wir eine bestehende Unternehmens-Website ablösen. Weg vom alten, extern gehosteten CMS, hin zu einer eigenen Anwendung auf Payload CMS und Next.js, komplett serverless bei Scaleway. Die alte Seite war live, mit echtem Traffic, echten Kund:innen und Dutzenden über Jahre gewachsenen URLs. Sie durfte zu keiner Sekunde ausfallen. Die neue Seite entstand parallel, Block für Block. Gut ein Dutzend Seiten waren fertig, der Rest noch nicht.

Wo’s klemmt

Der Standardweg für so einen Umzug ist der Stichtag. Man baut die neue Seite komplett fertig, friert die alte ein, wählt eine Nacht mit wenig Verkehr, biegt DNS oder Proxy um und hofft. Geht etwas schief, nimmt man alles zurück und versucht es nächste Woche erneut.

Das Problem ist die Bündelung des Risikos. Alles hängt an einem Moment. Ein Fehler auf einer einzigen Seite stellt die ganze Umschaltung in Frage. Dazu der Druck: Die neue Seite muss vollständig fertig sein, bevor auch nur eine einzige Seite live gehen darf. Man kann nicht die paar fertigen Seiten ausliefern und an den übrigen weiterbauen. Ganz oder gar nicht.

Der Dreh

Die Lösung war ein vorgeschalteter Proxy, der pro Seite entscheidet. Vor beiden Systemen sitzt ein nginx. Jede Anfrage geht zuerst an die neue Anwendung. Antwortet die sauber, sehen die Besucher:innen die neue Seite. Antwortet sie mit einem Fehler, fällt der Proxy still auf das alte System zurück und liefert die alte Seite. Die Besucher:innen merken davon nichts.

In nginx ist das eine Handvoll Zeilen. Der Kern:

error_page 404 500 502 503 504 = @failover;

location @failover {
    proxy_pass https://alte-seite;
}

Die neue Anwendung kennt eine Seite noch nicht? Sie gibt einen 404, der Proxy holt die Seite vom alten System. Die neue Anwendung ist fertig für diese Seite? Sie antwortet mit 200, das alte System wird gar nicht erst gefragt. Der Migrationsstand ist damit keine Liste, die jemand pflegt. Er ist schlicht die Frage: Welche Seiten liefert die neue Anwendung schon erfolgreich aus. Jede fertige Seite gewinnt automatisch, in dem Moment, in dem sie deployt ist.

Damit verschwindet der Stichtag. Es gibt keine Umschalt-Nacht, weil ständig umgeschaltet wird, seitenweise und unsichtbar. Eine einzelne Seite zurückzunehmen heißt: die Seite aus der neuen Anwendung nehmen, der Proxy fällt von selbst aufs Alte zurück. Kein Drama, kein Deploy um drei Uhr morgens.

Was hält

So elegant das ist, es hat zwei Kanten, die man kennen muss.

Erstens maskiert das Failover echte Fehler. Der Rückfall greift bei jedem Fehlercode der neuen Anwendung, auch bei einem echten Bug. Wirft die neue Seite wegen eines Programmierfehlers einen 500, bekommen die Besucher:innen klaglos die alte Seite, und niemand sieht das Problem. Bei uns kam der Cold-Start des Serverless-Containers dazu: Skaliert er von null hoch, gibt er kurz einen 502, und auch der löst still den Rückfall aus. Gut für die Besucher:innen, tückisch für uns. Die Konsequenz: Überwacht die neue Anwendung direkt. Der Proxy allein zeigt euch ihre Fehler nicht, er versteckt sie hinter der alten Seite.

Zweitens erfindet der Proxy keine Seite. Was beide Systeme nicht kennen, bleibt ein 404. Bei uns waren das alte Footer-Links wie /impressum oder /jobs, die keines der beiden Systeme mehr bediente. Der Proxy wählt nur zwischen zwei Backends, eine dritte Antwort zaubert er nicht herbei. Solche toten Links muss man getrennt aufräumen.

Die Handreichung, falls ihr eine Live-Seite ablösen müsst:

• Setzt einen Failover-Proxy davor, statt einen Stichtag zu planen. Neue Anwendung zuerst, bei Fehler zurück aufs alte System.
• In nginx reicht error_page mit einer benannten @failover-Location. Wenige Zeilen.
• Zieht Seite für Seite um. Jede fertige Seite geht sofort live, der Rest bleibt beim Alten.
• Überwacht die neue Anwendung direkt. Das Failover versteckt ihre Fehler, das ist Segen und Falle zugleich.
• Räumt tote Alt-Links separat auf. Der Proxy heilt nur, was mindestens eines der beiden Systeme kennt.

Der Reflex bei einem Website-Umzug ist, alles fertigzubauen und dann umzuschalten. Wir haben es umgedreht und ausgeliefert, was fertig war, während der Rest weiter beim Alten lief. Das nimmt dem Umzug die eine gefährliche Nacht und ersetzt sie durch Dutzende unspektakuläre Deploys. Langweilig ist hier genau das Ziel.