BELIEBIGE CLOUD → STACKIT · CHECKLISTE
STACKIT-Migrations-Checkliste für Cloud-Architekten
Eine Checkliste taugt nur, wenn jedes Kästchen auf einen Beleg zeigt. Diese ist in sechs Phasen gegliedert, von der Bestandsaufnahme bis zur Stilllegung, und jede Prüfung nennt die Datei eines StackToIT-Laufs, in der die Antwort steht. Die gezeigten Dateien stammen aus einem Lauf über eine kleine AWS-Umgebung, die für diese Seite geschrieben wurde: ein Netzwerk, ein Webserver, eine PostgreSQL-Datenbank, ein Bucket und ein Secret.
Was der Lauf für Ihre Checkliste schreibt
Von StackToIT am 4. November 2026 bewertet. Links die Reihenfolge der Wellen, die der Lauf aus den Abhängigkeiten der sieben Ressourcen berechnet hat. Rechts die ersten Zeilen der Prüfliste, die er zum Abhaken geschrieben hat.
## Wave 1 — 4 unit(s)
| Unit | Class | Target |
|---|---|---|
| `aws_db_instance.orders` | REPLATFORM / MEDIUM | STACKIT PostgreSQL Flex |
| `aws_s3_bucket.uploads` | DIRECT / MEDIUM | STACKIT Object Storage |
| `aws_secretsmanager_secret.db` | RECONFIGURE / MEDIUM | STACKIT Secrets Manager |
| `aws_vpc.main` | RECONFIGURE / MEDIUM | STACKIT project networking / Network Area (SNA) |
## Wave 2 — 2 unit(s)
| Unit | Class | Target |
|---|---|---|
| `aws_security_group.web` | RECONFIGURE / MEDIUM | STACKIT security group |
| `aws_subnet.app` | RECONFIGURE / MEDIUM | STACKIT network |## Before each step
- [ ] `TF/stackit_network.app` · `variable-supplied` `variable=project_id` — The variable `project_id` has a value.
- [ ] `TF/stackit_secretsmanager_instance.migrated_secrets` · `variable-supplied` `variable=project_id` — The variable `project_id` has a value.
- [ ] `TF/stackit_secretsmanager_user.migration` · `variable-supplied` `variable=project_id` — The variable `project_id` has a value.Wellen sind ein Ausgangspunkt
Der Lauf sagt es selbst: Einheiten derselben Welle können parallel umziehen, und die Reihenfolge ist ein Ausgangspunkt für Ihre Wellenplanung, kein Terminplan.
Prüfungen sind erzeugt, nicht generisch
Jedes Kästchen nennt einen Schritt des Plans und die Bedingung, die davor gelten muss, zum Beispiel dass die Variable project_id einen Wert hat.
1. Bestandsaufnahme
Klären Sie, was existiert und wie viel davon das Werkzeug sehen konnte.
Quelle vollständig machen
Der Lauf meldete VARIABLE_UNRESOLVED, weil die Variable db_password keinen Wert hatte. Übergeben Sie die Variablendatei mit --var-file, bevor Sie einer Zahl trauen. Prüfen: Konsolenzusammenfassung und summary.source_inputs in assessment.json.
Klasse jeder Einheit lesen
Sieben Ressourcen wurden zu sieben Einheiten: eine DIRECT, fünf RECONFIGURE und eine REPLATFORM, keine REDESIGN. Die Klasse benennt die Art der Arbeit; sie genehmigt sie nicht. Prüfen: assessment.json, engineering/architect-report.md.
Liste der nicht übernommenen Eigenschaften öffnen
engineering/not-carried-summary.csv zählt die Eigenschaften einer Einheit, die der Entwurf nicht übernimmt. In diesem Lauf: zwei bei der Datenbank (das Passwort und skip_final_snapshot), eine beim Secret, eine beim Subnetz. Klären Sie jede davon mit dem Verantwortlichen der Einheit.
Zustandsbehaftete Einheiten finden
migration/data-movement.md führt Datenbank und Bucket als zustandsbehaftet auf, mit Mechanismus UNKNOWN und Status DECISION REQUIRED. Die Datei nennt auch, was die Quelle nicht verrät: Datenmenge, Änderungsrate, tolerierte Ausfallzeit, Wiederherstellungspunkt.
2. Design
Offene Fragen in dokumentierte Antworten überführen.
Entscheidungsregister beantworten
Die Konsole meldete 6 zu treffende Entscheidungen und 3 zu bestätigende Voreinstellungen. Die Dateien zählen anders: decisions.json desselben Laufs enthält 19 offene Datensätze. Haken Sie daher jeden Datensatz in der Datei ab, nicht die Zahl der Konsole. Beispiele aus diesem Lauf: wie die Daten der Datenbank umziehen, ob ein öffentlicher Endpunkt für PostgreSQL Flex akzeptabel ist und welcher Flavor der abgeleiteten Größe entspricht. Prüfen: executive/decisions.md, decisions.json.
Jede Änderung der Erreichbarkeit prüfen
Für die Quelldatenbank ist kein öffentlicher Zugang belegt, die STACKIT-Instanz erhält dagegen einen eigenen Endpunkt, den nur eine Client-Liste begrenzt. Außerdem weist der Lauf darauf hin, dass das Subnetz keine Route ins Internet hatte, das entworfene Netzwerk aber über die Source-NAT von STACKIT nach außen kommt. Beides sind Architekturänderungen, die Sie akzeptieren oder neu entwerfen.
Abgeleitete Größen bestätigen
Der Entwurf ordnet db.m5.large (2 vCPU, 8 GiB) dem Flavor 2.16-replica (2 vCPU, 16 GiB) zu, dem kleinsten Replica-Flavor, der diese Werte abdeckt, und rechnet 100 GiB Speicher auf 108 um. Der Lauf nennt das einen Vorschlag. Bestätigen Sie ihn oder wählen Sie eine andere Größe.
Landing Zone prüfen
migration/landing-zone-requirements.md führt auf, was Organisation und Projekt vor dem ersten Anwenden bereitstellen müssen und welche Werte eine Person liefert.
3. Aufbau
Zielumgebung vorbereiten und den Entwurf in der richtigen Reihenfolge anwenden.
Offene Werte liefern
Hier warten 15 von 15 automatisierten Schritten, die frei von Entscheidungen sind, noch auf einen Wert: project_id, orders_access_scope, orders_allowed_cidrs und postgresflex_storage_class. Tragen Sie sie in review/target-values.tfvars ein und starten Sie den Lauf erneut.
Image und Maschinentyp benennen
Das Boot-Image ist eine Variable, die eine Person setzt, nie eine Image-ID, die das Werkzeug errät. Dasselbe gilt für Maschinentyp und Größe des Boot-Volumes des Webservers.
execution/terraform/apply.md befolgen
OpenTofu wendet den ganzen Entwurf auf einmal an und erzwingt weder manuelle Schritte noch API-Aufrufe. Die Datei führt auf, was vor dem Anwenden zu erledigen ist, und nennt bei Bedarf ein erstes Anwenden ausgewählter Blöcke mit -target.
Über das API-Opt-in entscheiden
Das Secret wird über eine STACKIT-API geschrieben, die nicht als allgemein verfügbar dokumentiert ist. Der Plan führt keinen solchen Aufruf aus, bis der Platform Architect die Opt-in-Entscheidung in executive/decisions.md beantwortet; die Konsole nennt sie als ersten Blocker.
4. Daten
Mechanismus wählen, Daten übertragen, Ergebnis belegen.
Pro zustandsbehafteter Einheit eine Methode wählen
Für die Datenbank hält der Plan zwei Methoden offen: einen Dump, der während des Schreibstopps eingespielt wird, oder logische Replikation. Auf Amazon RDS setzt logische Replikation voraus, dass der statische Parameter rds.logical_replication auf 1 steht und die Quellinstanz neu startet; sie ist also eine Änderung an der Quelle. Für den Bucket: eine Kopie mit rclone oder mit der AWS CLI über ein Staging-Verzeichnis. Entscheiden Sie nach Datenmenge, Änderungsrate und tolerierter Ausfallzeit.
Neues Datenbankpasswort übergeben
Das Quellpasswort wird nicht kopiert. STACKIT erzeugt eines für den migrierten Benutzer, der Entwurf gibt es als sensible Ausgabe aus. Geben Sie es vor dem Cutover an jeden Client weiter; der Terraform-State enthält es im Klartext.
Abgleich planen
Drei manuelle Abgleichschritte vergleichen Quelle und Ziel bei gestoppten Schreibern. Zu den genannten Prüfungen der Datenbank gehören Zeilenzahlen, Tabellenprüfsummen und Sequenzen.
Exportieren, bevor Sie löschen
Die Quelldatenbank setzt skip_final_snapshot, und die entworfene Instanz hat ebenfalls keine Einstellung für eine abschließende Sicherung. Exportieren Sie die Daten vorher, wenn sie erhalten bleiben müssen.
5. Cutover
Auf Grundlage einer Entscheidung umstellen, mit einem Rückweg.
Cutover-Fakten selbst festhalten
Der Lauf fand keinen DNS-Eintrag, kein Zertifikat und keine öffentliche Adresse, die umzubinden wären, und sagt ausdrücklich, dass das nichts über Namen und Adressen außerhalb der gelesenen Quelle aussagt. Führen Sie diese auf.
Rollback-Grenze festhalten
Der Abgleichschritt enthält die Prüfung rollback-limit, den Zeitpunkt, ab dem ein Rollback Daten verliert. Der Verantwortliche hält sie vor dem Fenster fest. Bis zur Umstellung zeigen die Clients weiter auf die Quelle.
Egress-Entscheidung abschließen
STACKIT legt in der Security Group eine Egress-Regel an, die jeden ausgehenden IPv4-Verkehr erlaubt und die der Entwurf nicht verwaltet; die Quelle erlaubte nur den aufgeführten Egress. Entscheiden Sie, ob Sie die Regel nach dem Anwenden entfernen.
Verantwortlichen für Go oder Rollback benennen
Der Plan weist die Prüfung der migrierten Umgebung und die Entscheidung über Go oder Rollback Rollen zu, darunter einem Migration Owner. Ordnen Sie die Rollen Personen zu.
6. Nachbereitung
Abschluss sichern und den Nachweis aufbewahren.
Veröffentlichten Ordner verifizieren
stacktoit verify prüft den Lauf-Ordner gegen sein Manifest und die Artefakte gegeneinander. Das ist keine Signatur und kein Beweis, dass sich in einer Cloud etwas geändert hat.
Nach jeder Antwort erneut ausführen
Antworten gehören in review/inputs.yaml und review/decisions.yaml; der nächste Lauf liest sie. Achten Sie auf Antworten, die er als ungültig oder veraltet meldet.
Quelle bis zur Abnahme behalten
Die Schritte zum Kopieren der Daten verlangen, den Quell-Bucket und den Zugriff darauf unangetastet zu lassen, bis das Ziel verifiziert ist. Die Arbeitspakete zur Stilllegung der Quelle stehen im Plan zuletzt.
Fortschritt protokollieren
review/progress.yaml ist die Vorlage für ein Fortschrittsprotokoll, das ein späterer Lauf mit --progress lesen kann.
Welche Datei beantwortet welche Frage
Öffnen Sie diese Dateien in dieser Reihenfolge, wenn Sie einen Lauf prüfen.
| Frage | Datei | Was dort steht |
|---|---|---|
| Ist die Quelle vollständig? | console.txt, assessment.json | Quellstatus und fehlende Eingaben |
| Welche Klasse hat jede Einheit? | engineering/architect-report.md | Einheitentabelle mit Klasse, Konfidenz und Begründung |
| In welcher Reihenfolge ziehen die Einheiten um? | migration/technical-sequencing.md | Wellen aus den Abhängigkeiten |
| Was ist zu entscheiden? | executive/decisions.md | Entscheidungen mit Optionen und den Schritten, die an ihnen hängen |
| Was wird nicht übernommen? | engineering/not-carried.csv | Eigenschaften, die der Entwurf auslässt, je Einheit |
| Was muss ich liefern? | review/target-values.tfvars | Offene Variablen des Entwurfs |
| Wer macht was? | migration/work-packages.csv | Arbeitspakete mit verantwortlicher Rolle und Status |
| Wie ziehen die Daten um? | migration/data-movement.md | Zustandsbehaftete Einheiten, Mechanismus und Prüfungen |
Ein Lauf ist ein Vorschlag. Nichts darin ist genehmigt, bis Ihre Architekten die Entscheidungen festhalten.
Fragen von Architekten zur Checkliste
Ersetzt diese Checkliste unseren eigenen Änderungsprozess?
Nein. Sie gibt Ihrem Prozess Belege an die Hand. Der Lauf ist ein Vorschlag, und jede Entscheidung, Freigabe und Ausführung bleibt bei Ihren Leuten.
Warum warten so viele Schritte?
Weil die Quelle nicht alles verrät. Im Demo-Lauf warten Schritte auf eine Projekt-ID, eine Zugriffsliste, eine Storage-Klasse und einige Entscheidungen. Sie zu beantworten, ist die Arbeit im Design.
Ist die Reihenfolge der Phasen fest?
Die Phasen folgen der Reihenfolge der Abhängigkeiten: Einen Flavor dimensionieren Sie erst, wenn die Klasse feststeht, und umstellen können Sie erst, wenn die Datenmethode gewählt ist. Innerhalb einer Phase bestimmen Sie die Reihenfolge.
Woher stammen die Terraform-Dateien?
StackToIT schreibt für die Ressourcen, die es entwerfen kann, einen STACKIT-Terraform-Entwurf in den Ordner terraform des Laufs. Prüfen Sie ihn mit dem Zielplattform-Team, bevor Sie etwas anwenden.
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.