AWS → STACKIT · CHECKLISTE
Checkliste für die Migration von AWS zu STACKIT
Mit dieser Liste bringen Sie eine AWS-Umgebung zu STACKIT, ohne den Überblick zu verlieren. Jeder Punkt nennt die Datei im Ausgabeordner von StackToIT, in der die Antwort steht; ein Reviewer hakt also anhand von Belegen ab statt aus dem Gedächtnis. Die Beispiele stammen aus einer Demo-Umgebung mit neun AWS-Einheiten und aus dem veröffentlichten Retail-Store-Lauf.
Wie die Checkliste aufgebaut ist
Sechs Phasen in der Reihenfolge, in der die Arbeit anfällt. Die Dateinamen sind Pfade im Ausgabeordner einer Bewertung.
Belege statt Meinung
Ein Punkt ist erledigt, wenn die daneben genannte Datei es sagt oder eine Person die Antwort in den Review-Dateien festgehalten hat. StackToIT liest und schreibt Dateien und ändert nichts in einer Cloud.
An einem echten Lauf bemessen
Der Retail-Store-Lauf umfasst 282 Terraform-Ressourcen und 44 Migrationseinheiten. Ihre Umgebung hat eigene Zahlen; die Punkte bleiben gleich.
Entscheidungen gehören zur Liste
Offene Entscheidungen blockieren Schritte des Plans. Wer sie überspringt, hakt Punkte ab, die der Plan nicht anerkennt.
Phase 1 · Bestandsaufnahme
| Prüfpunkt | Wo die Antwort steht | Erledigt, wenn |
|---|---|---|
| Die ganze Umgebung wurde gelesen: jedes Root- und Child-Modul und jede Variablendatei | console.txt und assessment.json (gelesene Ressourcen, Migrationseinheiten) | Die Zahl der Einheiten passt zur Erwartung Ihres Teams; fehlende Module sind erklärt |
| Variablen, die über die Existenz einer Ressource entscheiden, sind bekannt | console.txt (Zeile zur Sichtbarkeit), assessment.json (bedingte Einheiten) | Keine Einheit bleibt durch eine Variable offen, die Sie benennen können; der Retail-Store-Lauf verzeichnet 41 abgeschaltete Einheiten und 8 bedingte Einheiten, über die erst ein Plan entscheidet |
| Die Quelle besteht ihre eigenen Prüfungen | console.txt (Quellprüfungen) | Die Validierung lief, oder Sie wissen, warum nicht (etwa fehlende Lock-Datei) |
| Ressourcen außerhalb von Terraform sind aufgeführt | Ihr Inventar; der optionale discover-Befehl ergänzt eine schreibgeschützte Erfassung | Per Konsole angelegte Ressourcen sind von Hand ergänzt, denn eine Bewertung sieht nur, was in den Dateien steht |
Phase 2 · Design
| Prüfpunkt | Wo die Antwort steht | Erledigt, wenn |
|---|---|---|
| Jede Einheit hat Klasse und Ziel | assessment.json, migration/source-target.csv | Keine Einheit ist unerklärt; REDESIGN- und MANUAL_REVIEW-Einheiten haben einen Verantwortlichen |
| Offene Entscheidungen sind aufgeführt und zugeordnet | executive/decisions.md, decisions.json, review/decisions.yaml | Jede Entscheidung, die einen Planschritt blockiert, hat eine Antwort oder ein Datum |
| Vom Entwurf gewählte Vorgaben sind bestätigt oder geändert | executive/decisions.md (zu bestätigende Vorgaben) | Öffentlicher Endpunkt, Dimensionierung und Egress haben je eine festgehaltene Antwort |
| Was der Entwurf nicht übernimmt, ist verstanden | engineering/not-carried.csv, engineering/architect-report.md | Zu jeder nicht übernommenen Eigenschaft gibt es eine Entscheidung oder einen akzeptierten Verlust |
| Die Landing Zone ist definiert | migration/landing-zone-requirements.md | Organisation, Projekt, Region und Netzwerkbereiche sind abgestimmt |
So sieht „nicht übernommen“ aus
engineering/not-carried-summary.csv des Demo-Laufs: eine Zeile je Einheit mit der Zahl der Eigenschaften, die der Entwurf nicht übernehmen konnte. Ein Wert über null ist ein Prüfpunkt für das Design, kein Fehler.
unit,type,class,confidence,counted,properties_not_carried
aws_db_instance.orders,aws_db_instance,REPLATFORM,MEDIUM,yes,3
aws_instance.app,aws_instance,RECONFIGURE,MEDIUM,yes,2
aws_s3_bucket.uploads,aws_s3_bucket,RECONFIGURE,MEDIUM,yes,1
aws_secretsmanager_secret.api_key,aws_secretsmanager_secret,RECONFIGURE,MEDIUM,yes,1
aws_subnet.app_a,aws_subnet,RECONFIGURE,MEDIUM,yes,1
aws_subnet.app_b,aws_subnet,RECONFIGURE,MEDIUM,yes,1
aws_vpc.app,aws_vpc,RECONFIGURE,MEDIUM,no,Phase 3 · Aufbau
| Prüfpunkt | Wo die Antwort steht | Erledigt, wenn |
|---|---|---|
| Benötigte Dienste sind im Zielprojekt und in der Region aktiviert | terraform/README.md (Dienste zuerst aktivieren) | Die vom Entwurf genutzten Dienste sind aktiviert; das Portal zeigt einen deaktivierten Dienst als „in Ihrer Region nicht aktiviert“ an |
| Variablen ohne Standardwert haben Werte | review/target-values.tfvars (die Kopie von target-values-template.tfvars), terraform/variables.tf | project_id, Zugriffsbereiche, Client-CIDRs, Maschinentypen und Storage-Klassen sind gesetzt |
| Der Entwurf validiert gegen ein Testprojekt | terraform/README.md (init, validate, plan) | Ein Plan läuft im Testprojekt sauber durch; StackToIT führt nie apply aus |
| Der State wird wie ein Secret behandelt | terraform/README.md (Secrets, die der Provider in den State schreibt) | Speicherort und Zugriff auf den State sind vor dem ersten Apply entschieden |
| Apply-Reihenfolge und Vorschritte werden eingehalten | execution/terraform/apply.md | Manuelle Schritte und API-Aufrufe, die zuerst kommen müssen, sind abgehakt |
| Opt-in-API-Aufrufe sind entschieden | executive/decisions.md, execution/api/ | Jeder Aufruf einer API ohne genannten Reifegrad ist aktenkundig erlaubt oder abgelehnt |
Phase 4 · Daten
| Prüfpunkt | Wo die Antwort steht | Erledigt, wenn |
|---|---|---|
| Jede Einheit mit Zustand hat eine gewählte Umzugsmethode | migration/data-movement.md | Keine Einheit steht auf DECISION_REQUIRED |
| Größe, Änderungsrate und Ausfalltoleranz sind genannt | review/inputs.yaml (Datenmenge, Ausfallzeit, RPO), migration/data-movement.md (Liste „Not known“) | Die Unbekannten des Berichts sind durch Ihre Zahlen ersetzt |
| Die Methode wurde geprobt | Schritt „data rehearsal“ in execution/manual/actions.md | Die Dauer jedes Teilschritts ist festgehalten, das Schreibstopp-Fenster daraus abgeleitet |
| Secrets überträgt eine Person | Secrets-Manager-Schritte in execution/manual/actions.md | Die Werte liegen im STACKIT Secrets Manager; der Entwurf hält sie nie |
| Die Vergleichsprüfungen sind vereinbart | migration/data-movement-plan.json (checks je Datenbestand) | Zahlen, Listen oder Prüfsummen sind je Speicher benannt, mit einem Verantwortlichen für GO oder NO-GO |
Die Datentabelle und die Vorab-Prüfungen
Links migration/data-movement.md: Jede Einheit steht auf DECISION_REQUIRED, Datenklasse, RPO und Ausfalltoleranz auf NOT_PROVIDED, bis Sie sie nennen. Rechts die ersten Zeilen von execution/verify/checks.md, einer aus dem Plan erzeugten abhakbaren Liste. Die Dateiinhalte sind englisch.
| Unit | Source service | Target service | Application | Mechanism | State | Data class | RPO | Downtime tolerance |
|---|---|---|---|---|---|---|---|---|
| aws_db_instance.orders | aws_db_instance | STACKIT PostgreSQL Flex | | UNKNOWN | DECISION_REQUIRED | NOT_PROVIDED | NOT_PROVIDED | NOT_PROVIDED |
| aws_s3_bucket.uploads | aws_s3_bucket | STACKIT Object Storage | | UNKNOWN | DECISION_REQUIRED | NOT_PROVIDED | NOT_PROVIDED | NOT_PROVIDED |## Before each step
- [ ] `TF/stackit_network.app_a` · `variable-supplied` `variable=project_id` — The variable `project_id` has a value.
- [ ] `TF/stackit_network.app_b` · `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.Phase 5 · Cutover
| Prüfpunkt | Wo die Antwort steht | Erledigt, wenn |
|---|---|---|
| Die Anwendungen je Speicher sind aufgeführt | Cutover-Schritte in execution/manual/actions.md | Der Plan liest nicht, welche Anwendungen einen Speicher nutzen; deren Verantwortliche führen sie auf |
| Wartungsfenster und Schreibstopp sind vereinbart | Schritte zum Schreibstopp; Eingabe zum Wartungsfenster in review/inputs.yaml | Der Verantwortliche nennt ein Fenster; der Plan erfindet keines |
| DNS hat eine gesenkte TTL und einen Rollback | migration/technical-sequencing.md (Schritte zur Zonen-Delegation) | TTL gesenkt und abgelaufen, Antworten an den Ziel-Nameservern geprüft |
| Der Schritt der Rollback-Entscheidung hat einen Verantwortlichen | Schritt „Rollback-Entscheidung“ in execution/manual/actions.md | Eine benannte Person hält GO oder ROLLBACK fest |
| Die geordneten Schritte stehen im Cutover- und Rollback-Runbook | Cutover- und Rollback-Runbook | Jeder Schritt hat Verantwortlichen, Prüfung und Rückweg |
Phase 6 · Nachbereitung
| Prüfpunkt | Wo die Antwort steht | Erledigt, wenn |
|---|---|---|
| Der Fortschritt ist festgehalten | review/progress.yaml | Jeder Schritt ist DONE, FAILED oder WAIVED, mit Verantwortlichem und Datum |
| Der Restore ist nachgewiesen | Schritt zur Restore-Prüfung je Datenbank | Ein Point-in-Time-Klon wurde vor dem GO gelesen und verglichen |
| Die Quelle wird in geordneter Reihenfolge stillgelegt | Decommission-Schritte (Stilllegung) in execution/manual/actions.md | Die Stilllegung begann erst nach dem GO; letzte Backups bleiben für den von Ihnen festgelegten Zeitraum erhalten |
| Das Ergebnis ist unverändert archiviert | Ausgabeordner und seine manifest.json | Der Ordner besteht die Prüfung mit dem verify-Befehl, bevor er geteilt oder archiviert wird |
Wo Sie den Fortschritt festhalten
review/progress.yaml beginnt als progress-template.yaml. Jeder Eintrag ist per Hash an den Schritt gebunden; ändert ein späterer Lauf den Schritt, erscheint Ihr Eintrag als veraltet, statt stillschweigend übernommen zu werden.
entries:
# MANUAL critical-semantic - aws_subnet.app_a
- action_id: "MAN/semantic/aws_subnet.app_a/availability-zone"
contract_sha256: "sha256:466db94bafa1a6993c03688825aff955665d3be7fa1f3d4387e6c6a0c7d4ac72"
state: NOT_STARTED
# MANUAL critical-semantic - aws_subnet.app_a
- action_id: "MAN/semantic/aws_subnet.app_a/effective-route-table"Fragen aus den Teams
Lässt sich die Checkliste allein aus dem Bericht abhaken?
Nur die Designphasen. Aufbau, Daten, Cutover und Nachbereitung brauchen Arbeit in Ihrer Umgebung; die Dateien sagen, was zu tun ist und was als erledigt gilt, und das Ergebnis halten Sie in den Review-Dateien fest.
Brauche ich vorab ein vollständiges AWS-Inventar?
Die Bewertung liest Terraform. Für den Vergleich mit dem laufenden Konto erfasst der discover-Befehl ein schreibgeschütztes Inventar mit Ihren lokalen AWS-Zugangsdaten; die Bewertung selbst verbindet sich nie mit AWS.
Wo zeigen verwaltete Datenbanken und Buckets ihre Risiken?
In den Dateien zum Datenumzug und in der Liste nicht übernommener Eigenschaften: Engine-Versionen, öffentliche oder private Endpunkte, Bucket-Einstellungen, die über eine API statt über Terraform laufen, und unbekannte Aussagen zur Verschlüsselung.
Ist jedes Kästchen Pflicht?
Nein. Im Fortschrittsjournal gibt es WAIVED aus gutem Grund, doch ein Verzicht braucht eine Notiz, damit die Auslassung sichtbar bleibt.
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.