CUTOVER → STACKIT · CHECKLISTE
Checkliste für Cutover, Rollback und Stilllegung bei STACKIT
Wenn Sie diese Prüfungen der Reihe nach abhaken, kommt der einzige unumkehrbare Moment der Migration, die Stilllegung der Quell-Datenspeicher, erst nach einem festgehaltenen GO und mit aufbewahrtem Backup. Die Liste folgt dem Ausführungsplan, den StackToIT für ein Portal auf AWS geschrieben hat: PostgreSQL-Datenbank, Objekt-Bucket, Server mit öffentlicher Adresse, Zertifikat und DNS-Eintrag, zusammen 78 Schritte, davon 64 manuell. Jede Prüfung nennt die Datei mit der Antwort, gegliedert nach Phase: Design, Build, Daten, Cutover, Rollback und Nachbereitung.
1 · Design: bevor etwas gebaut wird
Antworten stehen in migration/technical-sequencing.md (die drei Kästchen unter „Before wave 1“), decisions.json und engineering/architect-report.md.
Jede Einheit ohne Entwurf hat einen Verantwortlichen
migration/technical-sequencing.md verlangt, jede REDESIGN-, MANUAL_REVIEW- und BLOCKED-Einheit zu prüfen; dieser Lauf hat keine. Seine einzige Lücke ist das Zertifikat: RECONFIGURE, mit stackit_alb_certificate als Ziel, das dieser Entwurf aber nicht schreibt; terraform/README.md führt es deshalb als Aufgabe, die beim Architekten bleibt.
STACKIT-Organisation, Ordner und Projekte sind angelegt
Ein Projekt je Umgebung ist laut Plan der übliche Start. Alles Spätere setzt voraus, dass das Projekt existiert.
Übertragungsmethode und Fenster sind je Dateneinheit vereinbart
Der Lauf führt Datenbank und Bucket als Dateneinheiten mit je mehreren möglichen Methoden. Keine Methode gilt, bis die Entscheidung beantwortet ist.
Die Version des Quell-Providers ist festgelegt
Committen Sie die Lock-Datei, die der Lauf verlangt. Bis dahin trägt jede Einheit dieses Providers einen offenen Punkt.
Wiederanlaufpunkt und tolerierte Ausfallzeit sind aufgeschrieben
Der Lauf nennt beides nicht: Der Plan führt sie als nicht angegeben. Ohne sie lässt sich das Schreibstopp-Fenster nicht begründen.
2 · Build: das Ziel existiert und ist geprüft
Dateien: terraform/, execution/terraform/apply.md und execution/verify/checks.md, deren Listen „vor jedem Schritt“ und „nach jedem Schritt“ Kästchen zum Abhaken sind.
Variablen ohne Standardwert haben einen Wert
In diesem Lauf acht: project_id, Zugriffsbereich, erlaubte Adressbereiche und Storage-Klasse der Datenbank, Image, Maschinentyp und Boot-Volume-Größe des Servers sowie die DNS-Zonenkennung. Die Prüfdatei führt jede als Vorab-Prüfung.
Der Entwurf ist in einem Testprojekt validiert und geplant
Das README im terraform-Ordner verlangt zuerst tofu init, validate und plan gegen ein Testprojekt. Die Engine wendet nie an.
Die STACKIT-Dienste sind aktiviert, der State ist geschützt
terraform/README.md nennt die Dienste, die vor dem Apply im Projekt und in der Region aktiviert sein müssen (DNS, IaaS, Object Storage, PostgreSQL Flex), und warnt, dass der State das erzeugte Datenbankpasswort und das Bucket-Secret im Klartext enthält; das State-Backend muss also verschlüsselt und im Zugriff beschränkt sein.
Neue Datenbank, Bucket, Server und öffentliche Adresse existieren
Jeder Terraform-Schritt hat eine Nachprüfung „existiert im STACKIT-Projekt“.
Die DNS-Zone ist gebunden
Wählen oder erstellen Sie die STACKIT-Zone, die die Route-53-Zone ersetzt, und setzen Sie die Zonenvariable. Der Lauf prüft nicht, ob die Zone die richtige Domain enthält. Die STACKIT-Dokumentation beschreibt ein Skript, das die Record Sets von Route-53-Zonen nach STACKIT DNS kopiert und die NS- und SOA-Einträge am Zonen-Apex auslässt.
Die Zertifikatsfrage ist beantwortet
Die Quelle deklariert ein Zertifikat; ob es die umziehenden Namen abdeckt, bewertet der Lauf nicht. Entscheiden Sie: neu ausstellen, importieren oder ersetzen.
3 · Daten: kopieren, proben, belegen
Dateien: migration/data-movement.md und terraform/handover/database-portal/data-move.md.
Preflight schließt jede offene Prüfung
Versionen, Erweiterungen, Rollen, Netzwerk und TLS, durch rein lesende Abfragen auf Quelle und Ziel.
Eine Generalprobe in eine Scratch-Datenbank ist gemessen
Das Schreibstopp-Fenster wird aus diesen Zeiten vereinbart, nicht geschätzt.
Erstkopie und Delta-Syncs laufen
Für den Bucket kommen unter anderem AWS-CLI-Sync und rclone in Frage, für die Datenbank logische Replikation oder Dump und Restore.
Zeilenzahlen, Prüfsummen, Sequenzen und eine Anwendungsabfrage stimmen überein
Das ist der Abgleichschritt bei gestoppten schreibenden Clients. Er endet in einem festgehaltenen GO oder NO-GO.
4 · Cutover: eine Umstellung nach der anderen
Dateien: der Cutover-Abschnitt C1 bis C5 in migration/technical-sequencing.md und die MAN/cutover-Schritte in execution-plan.json.
TTLs sind vor der Umstellung gesenkt
Der Plan liest die TTL jedes Eintrags aus der Quelle (hier 60 s, dieser Eintrag ist also schon kurz) und schlägt 60 s als Ziel vor. Er verlangt, Änderungszeit und alte TTL festzuhalten und vor der Umstellung die Dauer einer alten TTL abzuwarten.
Die Cutover-Bereitschaft ist bestätigt
Jeder Workload-Schritt und jeder Datenumzug ist erledigt. Der Plan weiß nicht, welcher Einstiegspunkt welchen Speicher bedient; deshalb wartet jede Umstellung auf alle.
Schreibende Clients sind aufgelistet und dann gestoppt
Auflisten, wer schreibt, die Verbindungseinstellungen jedes Clients festhalten, dann Dienste, Jobs und Migrationen stoppen. Die Quelle bleibt beschreibbar und unberührt.
Letzter Sync und Abgleich laufen im Schreibstopp durch
Weicht eine Zahl oder die Anwendungsabfrage ab, stoppen Sie und nehmen den Rollback, ohne etwas umzustellen.
Die Connection Strings aller Clients sind umgestellt
Host, Port, Datenbank, Zugangsdaten und TLS-Modus für die Datenbank; Endpunkt, Bucket-Name und Schlüssel für den Bucket. Die Anwendungen liegen außerhalb der Quelle; ihre Verantwortlichen listen sie deshalb auf.
Der DNS-Eintrag zeigt auf die neue öffentliche Adresse
Der Eintragswert wechselt von der AWS- zur STACKIT-Adresse. Prüfen Sie vorher durch eine direkte Abfrage an einem STACKIT-Nameserver und vergleichen Sie mit der alten Antwort.
Anfragen erreichen die neue Adresse, die alte erhält keine
Die Prüfung liest Zugriffslogs oder Metriken beider Seiten.
5 · Rollback: entschieden, bevor das Fenster öffnet
Dateien: der Rollback-Eintrag jedes Schritts in execution-plan.json und der Abschnitt Rollback im Handover zum Datenumzug.
Alte Verbindungseinstellungen sind festgehalten und aufbewahrt
Der Rollback braucht sie. Das Handover weist an, bei der Umstellung die alten Werte zu behalten.
Rollback-Auslöser und Aufbewahrungsdatum der Quelle sind benannt
Beides führt der Plan als unbekannt, geliefert vom Migrationsverantwortlichen. Niemand kann es für Sie erfinden.
Der Rollback der Traffic-Umstellung ist bekannt
DNS-Eintrag zurück auf die AWS-Adresse ändern. Die TTL im Rollback-Fenster niedrig lassen, damit eine zweite Umstellung schnell wirkt.
Für Schreibvorgänge auf STACKIT nach der Umstellung gibt es einen Plan
Sie liegen nicht in der Quelle. Kopieren Sie sie mit derselben Methode in Gegenrichtung zurück, nach einer eigenen Probe, oder nehmen Sie den Verlust schriftlich in Kauf.
Die AWS-Ressourcen bleiben bis zum GO bestehen
Der Plan legt vor dem festgehaltenen GO des Rollback-Entscheidungsschritts nichts still.
6 · Nachbereitung: prüfen, entscheiden, aufräumen, stilllegen
Dateien: die MAN/verify- und MAN/decommission-Schritte in execution-plan.json; execution/manual/actions.md.
Eine Wiederherstellung wird auf STACKIT getestet
Die PostgreSQL-Flex-Instanz auf einen Zeitpunkt nach dem Datenumzug klonen, lesen und vergleichen, Dauer festhalten, Klon löschen. Halten Sie auch das Datum fest, bis zu dem die automatischen AWS-Backups bleiben.
GO oder ROLLBACK ist mit dem Ergebnis jeder Prüfung festgehalten
Der Entscheidungsschritt hängt von jedem Prüfschritt ab. Bei GO die normale DNS-TTL wiederherstellen.
Reste der Replikation sind entfernt
Subscription, Publication und Slot, Dump-Dateien, der Umzugs-Host in der Zugriffsliste. Zugangsdaten des Umzugs rotieren.
Ein letztes Backup jedes Quellspeichers bleibt erhalten
Die Stilllegung von Datenbank oder Bucket kann der Plan nicht rückgängig machen; nur das letzte Backup stellt die Daten wieder her, in eine neue Ressource. Die Quelle nennt keinen final_snapshot_identifier; deshalb warnt der Plan, dass das Löschen der RDS-Instanz über die Konfiguration scheitert, bis ein Snapshot-Name gesetzt ist.
Quellressourcen werden in Abhängigkeitsreihenfolge stillgelegt
Zum Beispiel Subnetze vor der VPC. Entfernen Sie sie aus der Quellkonfiguration und wenden Sie diese an, statt gezielt zu zerstören, denn das würde auch abhängige Ressourcen löschen.
Wo das Fenster beginnt und wo der Rückweg endet
Wörtliche Zeilenbereiche aus execution-plan.json des Laufs, am 4. November 2026 für eine für diese Seite gebaute Umgebung geschrieben: Vorgang, Risiken und Rollback zweier Schritte. Links die TTL-Senkung, mit der der Cutover beginnt. Rechts die Stilllegung der Datenbank, der Schritt ohne Rückweg.
"operation": {
"manual": {
"what": "Lower the TTL of the DNS names the clients of aws_eip.portal (aws_eip) resolve, ahead of its traffic switch: the source holds 1 Route 53 record that point to it: \"portal.example.com\" (aws_route53_record.portal): the source states a TTL of 60 s. Lower each TTL that is not an alias record's to a short value the person chooses (the plan suggests 60 s, which is also the lowest TTL STACKIT DNS takes for a record set; it is a suggestion, not a fact of the source)",
"why": "a resolver keeps the answer it holds for one TTL: a switch of aws_eip.portal made while resolvers still hold an answer cached under the old TTL leaves part of the clients on the AWS address until that answer expires, and lowering the TTL first shortens that tail to the lowered TTL",
"owner_role": "Network Architect",
"when": "at least 60 s (the longest TTL the source states) before the maintenance window of the traffic switch of aws_eip.portal, because resolvers keep the old answer for up to one TTL: a change made later does not reach the resolvers that already hold the old answer",
"required_input": "the old TTL of each name (stated above, or read with the command named), the TTL to lower it to (the owner's choice; the plan suggests 60 s), and a person who can change the record sets in Route 53",
"success_condition": "the record set of each name that has a TTL of its own shows the lowered TTL (`aws route53 list-resource-record-sets`), the TTL a resolver is given for each alias name is read and recorded, and one old TTL has passed since the change (the time of the change and the old TTL are recorded)"
}
},
"postconditions": [],
"decisions": [],
"risks": [],
"rollback": [
{
"capability": "MANUAL",
"how": "restore the old TTL of each name after the GO recorded at the rollback decision step; on a ROLLBACK leave it lowered during the rollback window, so that a second switch (back to AWS, then again) takes effect within the lowered TTL, and restore it when the owner decides to stay on AWS"
}
], "operation": {
"manual": {
"what": "Retire aws_db_instance.portal (aws_db_instance) in the AWS account after the GO: delete it the way it is managed (remove it from the source configuration and apply that, or delete it in the AWS console), once the resources that depend on it are retired (the steps it follows); a targeted destroy of the source configuration would also delete what depends on it",
"why": "aws_db_instance.portal keeps costing money and can still take traffic or writes after the cutover, so the two copies drift apart; StackToIT deletes nothing (it is read-only): a person retires it",
"owner_role": "Data Architect",
"when": "after the GO recorded at the rollback decision step",
"required_input": "the final backup of aws_db_instance.portal, kept for a number of days the owner decides (the plan states no default), and the GO recorded at the rollback decision step",
"success_condition": "aws_db_instance.portal no longer exists in the AWS account and its charges stop on the bill"
}
},
"postconditions": [],
"decisions": [],
"risks": [
"StackToIT performs none of this: it deletes nothing in any cloud, and no step of this plan automates the retirement",
"the source states no final_snapshot_identifier and not skip_final_snapshot = true: the provider documents the identifier as required when skip_final_snapshot is false (its default), so deleting the instance as managed fails until a name is stated; state it, and the snapshot it names is the final backup this step needs"
],
"rollback": [
{
"capability": "IMPOSSIBLE",
"how": "the plan cannot bring aws_db_instance.portal back: only the final backup the owner kept restores its data, into a new resource"
}
],Zwei Rollback-Fähigkeiten
Der TTL-Schritt ist MANUAL: Nach dem GO die alte TTL wiederherstellen, bei einem Rollback die TTL niedrig lassen, damit eine zweite Umstellung schnell wirkt. Die Stilllegung ist IMPOSSIBLE: Nur das letzte Backup bringt die Daten zurück, in eine neue Ressource.
Verantwortliche sind Rollen
Der Lauf nennt Rollen wie Migration Owner, Data Architect und Network Architect; ordnen Sie sie vor dem Fenster Personen zu.
Fragen vor dem Fenster
Führt StackToIT den Cutover durch?
Nein. Es schreibt Schritte, Verantwortliche, Prüfungen und Rollback-Hinweise; Personen oder OpenTofu führen sie aus. Die Sequenzdatei sagt ausdrücklich, dass sie keine Zeitschätzung abgibt.
Welche Schritte lassen sich nicht zurücknehmen?
In diesem Lauf die Stilllegung von Datenbank und Bucket: Der Plan hält fest, dass nur das von der verantwortlichen Person aufbewahrte letzte Backup die Daten wiederherstellt, in eine neue Ressource. VPC, Zertifikat und DNS-Eintrag lassen sich aus der Quellkonfiguration neu erzeugen; was sie darüber hinaus enthielten, wird aber nicht wiederhergestellt.
Wie lange bleibt die Quelle bestehen?
Der Plan lässt das offen und fragt den Migrationsverantwortlichen nach einem Datum. Behalten Sie sie bis zum festgehaltenen GO, und länger, wenn Ihre Wiederanlaufziele es verlangen.
Warum die DNS-TTL senken?
Damit die Umstellung und eine Rückumstellung innerhalb der gesenkten TTL wirken. Der Plan schlägt 60 Sekunden vor und behandelt es als Vorschlag, nicht als Tatsache Ihrer Quelle.
Quellen
Ihr nächster Schritt: STACKIT.
Erzählen Sie uns von Ihrer Umgebung. Wir zeigen Ihnen, was StackToIT dafür liefert: Zielarchitektur, Terraform-Artefakte und einen strukturierten Migrationsplan.