Eine Migration ist ein Vertrauensproblem

Bei einer Migration kann man fast alles messen — außer der einen Sache, auf die es am Ende ankommt: ob man wirklich an alles gedacht hat. Diese Geschichte handelt von dieser Lücke. Sie ist bewusst allgemein gehalten — ohne Kunden, ohne Anbieter, ohne Zeitpunkt.

Situation

Eine große Infrastruktur sollte umziehen: mehrere Server, Datenbanken, Sicherungen, dazu ein Wechsel des Anbieters. Jedes einzelne Stück war für sich verstanden und beherrschbar. Die Aufgabe war nicht, etwas Neues zu erfinden, sondern Vorhandenes vollständig und unversehrt an einen neuen Ort zu bringen.

Ausgangsannahmen

Die naheliegende Annahme war, dass eine Migration eine technische Aufgabe ist: Man kopiert, stellt um, prüft, dass es läuft. Jeder Schritt war bekannt, keiner besonders schwer. Unter dieser Annahme schien der Erfolg eine Frage sorgfältiger Ausführung zu sein.

Problem

Die eigentliche Schwierigkeit lag woanders. Es war nicht schwer, einen Server umzuziehen — es war schwer, sicher zu sein, dass man alle Server, alle Datenbanken, alle Sicherungen, alle stillen Abhängigkeiten erfasst hatte. Über die Zeit sammeln sich in einer gewachsenen Infrastruktur Dinge an, die niemand mehr vollständig im Kopf hat: ein selten genutzter Dienst, eine Sicherung an unerwartetem Ort, eine Abhängigkeit, die nur einmal im Monat sichtbar wird. Die Frage war nicht „läuft es am neuen Ort?", sondern „ist wirklich alles mitgekommen?" — und diese Frage lässt sich nicht durch bloßes Umziehen beantworten.

Ursache

Die Ursache dieser Schwierigkeit war, dass Vollständigkeit sich nicht beweisen lässt, indem man das Vorhandene betrachtet — man sieht nur, was man kennt, nicht, was man vergessen hat. Eine Migration ist deshalb ihrem Wesen nach kein technisches, sondern ein Vertrauensproblem: Der Erfolg hängt daran, ob man der Aussage „es ist alles da" wirklich glauben darf. Und Glauben ohne Beleg ist Hoffnung.

Entscheidung

Die Entscheidung war, das Vertrauen nicht zu hoffen, sondern herzustellen — die Migration so anzulegen, dass man ihre Vollständigkeit belegen kann, statt sie zu behaupten. Nicht die Umstellung selbst stand im Mittelpunkt, sondern die Fähigkeit, am Ende sicher zu sagen: Nichts fehlt.

Umsetzung

Das hieß, den alten und den neuen Zustand vergleichbar zu machen und den Umzug umkehrbar zu halten. Bevor etwas abgeschaltet wurde, wurde geprüft, dass das Neue dem Alten entspricht — Bestand gegen Bestand, nicht Stichprobe gegen Gefühl. Das Alte blieb erreichbar, bis das Neue belegt trug, sodass ein Fehler ein Zurück erlaubte statt eines Ausfalls. Jeder Schritt war so gebaut, dass sein Erfolg nachweisbar war, nicht nur wahrscheinlich.

Trade-offs

Diese Gründlichkeit kostet Zeit und Geduld: Belegen ist langsamer als Umziehen, und den alten Zustand parallel zu halten, bindet Ressourcen, die man scheinbar schon nicht mehr braucht. Der Preis ist die Versicherung gegen den einen vergessenen Teil, der sich erst Wochen später meldet, wenn das Alte längst abgeschaltet ist. Anders würden wir es nur bei einer kleinen, überschaubaren Umgebung handhaben, deren Vollständigkeit ein Mensch noch sicher überblickt — dort ist der volle Beleg-Aufwand überzogen.

Was wir gelernt haben

Eine Migration ist ein Vertrauensproblem, bevor sie ein technisches ist. Das Umziehen beherrscht man; die Gewissheit, nichts vergessen zu haben, muss man sich aktiv verdienen. Deshalb ist die zentrale Arbeit nicht das Verschieben, sondern das Belegen — den neuen Zustand gegen den alten prüfbar zu machen und den Rückweg offen zu halten, bis der Beleg steht. Wer nur umzieht und hofft, hat die eigentliche Aufgabe nicht erledigt.

Wie das Batunet verändert hat

Seither behandeln wir Migrationen zuerst als Frage des Vertrauens: Wie beweisen wir, dass alles mitgekommen ist? Wir bauen den Nachweis der Vollständigkeit ein, statt am Ende darauf zu vertrauen, und halten den alten Zustand erreichbar, bis der neue belegt trägt. Aus „es müsste alles da sein" ist „wir können zeigen, dass alles da ist" geworden.

Weiterführend

• Guide: Zero-Downtime-Datenbankmigrationen — dieselbe Disziplin der Umkehrbarkeit und Prüfung, auf Datenbanken angewandt.
• Guide: Observability ist Architektur — warum man nur beurteilen kann, was man messbar macht.
• Guide: Software, die in zehn Jahren noch läuft — warum Betreibbarkeit über die Lebensdauer entscheidet.
• Leistung: Cloud-Software und Software-Wartung — Infrastruktur bauen und verlässlich betreiben.

Grundlage ist die Batunet Engineering Method: für den Fehlerfall entwerfen, in umkehrbaren Schritten arbeiten, Vollständigkeit belegen statt hoffen.

Bei einer Migration ist die schwerste Frage nicht, ob das Neue läuft, sondern ob man dem Satz „es ist alles da" glauben darf. Vertrauen entsteht aus Beleg, nicht aus Hoffnung.