AZURE → STACKIT · CHECKLISTE
Checkliste für die Migration von Azure zu STACKIT
Vierunddreißig Prüfpunkte in sechs Phasen, jeder an die Datei gebunden, in der ein StackToIT-Lauf die Antwort hält. Zahlen und Dateinamen stammen aus der Bewertung einer kleinen Azure-Umgebung (Scale Set, PostgreSQL, Redis, Storage-Konto, Key Vault und Netzwerk) vom 4. November 2026; Ihre Umgebung hat eigene Zahlen und dieselben Dateien.
Was ein Lauf Ihnen vor der ersten Prüfung sagt
Links: drei Zeilen der Konsolenzusammenfassung der Demo-Umgebung. Rechts: zwei Zeilen aus execution/verify/checks.md, der Datei, die den Plan in abhakbare Prüfungen übersetzt: die erste aus der Liste „Before each step“, die zweite aus „After each step“.
Source 9 resources · 7 units · visibility: Complete
Migration 6 drafted · 1 need no resource (of 7 units the draft considered)
Attention 7 units to review · 6 open requests (1 block the draft, marked in inputs-template.yaml)- [ ] `TF/stackit_valkey_instance.erp` · `variable-supplied` `variable=erp_cache_allowed_cidrs` — The variable `erp_cache_allowed_cidrs` has a value.
- [ ] `TF/stackit_valkey_instance.erp` · `resource-exists` `address=stackit_valkey_instance.erp` — `stackit_valkey_instance.erp` exists in the STACKIT project (OpenTofu's state lists it).Sieben Einheiten aus neun Ressourcen
Neun Terraform-Ressourcen wurden zu sieben Einheiten. Container und Anbindungen werden mit der Einheit gelesen, zu der sie gehören; Einheiten- und Ressourcenzahl unterscheiden sich daher gewollt.
Eine Anfrage blockiert den Entwurf
Der Lauf führt sechs offene Anfragen und markiert eine als blockierend. Beantworten Sie diese zuerst: Sie steht in review/inputs.yaml.
Die Prüfungen sind der Plan zum Abhaken
execution/verify/checks.md hat eine Zeile für jede Variable, die vor einem Schritt einen Wert haben muss, und eine für jede Ressource, die danach existieren muss.
Phase 1: Bestandsaufnahme
Was hineingeht und was der Lauf nicht sehen kann.
Jedes Terraform-Root-Modul liegt im bewerteten Ordner
Der Lauf liest azurerm- und azapi-Code und verbindet sich nie mit Azure. Was von Hand oder außerhalb des Ordners entstanden ist, sieht er nicht. Prüfung: engineering/architect-report.md nennt den Quellstatus und die gelesenen Ressourcen.
Die Provider-Lock-Datei ist eingecheckt
Ohne .terraform.lock.hcl begrenzt der Lauf die Einheiten dieses Providers auf Konfidenz MEDIUM und stuft keine als geeignet für automatisierte Schritte ein. Prüfung: der Provider-Hinweis am Anfang von engineering/architect-report.md.
Jede Variable hat einen Wert
Eine Einheit, die eine ungesetzte Variable liest, erhält keinen Entwurf, und der Lauf nennt die Variable. Prüfung: die Zeile „Next“ in der Konsolenausgabe und der erste Abschnitt des Architekturberichts.
Zustandsbehaftete Einheiten sind aufgeführt
migration/data-movement.md nennt die Einheiten mit Daten: hier PostgreSQL, Redis und das Storage-Konto. Key Vault gehört nicht dazu; erfassen Sie Secrets und Schlüssel daher gesondert.
Von Hand erstellte Ressourcen sind ergänzt
Ressourcengruppen, Richtlinien, Rollenzuweisungen und Entra-Objekte außerhalb von Terraform brauchen ein eigenes Inventar; exportieren Sie sie als Code oder führen Sie sie von Hand auf.
Phase 2: Design
Die Entscheidungen, die ändern, was gebaut wird.
Die Zielregion ist festgelegt
target.region ist die einzige Anfrage, die den Entwurf blockiert. Beantworten Sie sie in review/inputs.yaml und führen Sie den Lauf mit demselben Ausgabeordner erneut aus.
Ressourcengruppen werden Projekten zugeordnet
STACKIT kennt keine Ressourcengruppen. Die Arbeitspakete in migration/work-packages.csv tragen die Entscheidung je Einheit; legen Sie einen Projektaufbau fest und beantworten Sie alle damit.
Das Netzwerkdesign ist gewählt
Das virtuelle Netzwerk wird ohne eigene Ressource entworfen; Adressraum und die Frage der Network Area sind offene Einstellungen. Prüfung: das Paket des Network Architect.
Jede REDESIGN- und MANUAL_REVIEW-Einheit wird zuerst gelesen
Diese Demo hat keine: fünf Einheiten sind RECONFIGURE und zwei REPLATFORM, alle mit Konfidenz MEDIUM. Umgebungen mit Entra-ID-Gruppen oder Cosmos DB können in REDESIGN landen; lesen Sie diese Zeilen in engineering/review.csv vor allem anderen.
Die Datenbank-Erreichbarkeit ist entschieden
Bei der PostgreSQL-Quelle war der öffentliche Netzwerkzugriff aktiviert. Bei STACKIT erreichen Clients die Instanz über ihre Zugriffsliste (ACL); die Variable mit den erlaubten CIDRs ist daher die eigentliche Stellschraube. Sie hat keinen Standardwert.
Secrets und Schlüssel haben einen Verantwortlichen
Key Vault wird zu einer Secrets-Manager-Instanz, mit KMS für Schlüssel. Das Paket des Identity Architect enthält die offenen Einstellungen.
Entscheidungen sind festgehalten
Tragen Sie die Prüfung in review/decisions.yaml ein. Ein Eintrag besagt, dass jemand hingesehen hat, und ändert den Entwurf nicht.
Phase 3: Aufbau
Den Entwurf so weit bringen, dass ein Plan fehlerfrei durchläuft.
Variablen sind belegt
Der Entwurf deklariert 12 Variablen. review/target-values.tfvars führt die 9 ohne Standardwert auf, je eine Vorlagezeile: Projekt-ID, Image, Maschinentyp, Größe des Boot-Volumes, Valkey-Plan und -Version, Storage-Klasse für PostgreSQL und die beiden Listen erlaubter CIDRs. Region, Availability Zone und Nameserver haben Standardwerte (eu01, eu01-1, die Adressen des STACKIT-Resolvers), die Sie bestätigen.
Die Kommentare zu nicht übernommenen Einstellungen sind gelesen
Jeder Block in terraform/ hat Kommentare zu den Einstellungen, die er nicht übernehmen konnte. engineering/not-carried.csv führt sie in einer Tabelle.
Die Provider-Version entspricht der bewerteten
terraform/terraform.tf legt den STACKIT-Provider fest, gegen den der Entwurf geschrieben wurde. Behalten Sie ihn, bis die Prüfung abgeschlossen ist.
Scale Sets sind verstanden
Das Scale Set wurde zu einer festen Gruppe aus zwei Servern mit count. STACKIT hat kein Scale-Set-Objekt; die Kapazität ändert sich also durch Ändern von count. Eine Affinitätsgruppe ist optional.
Images sind vorhanden
Die Azure-Image-Referenz wird nicht übernommen. Wählen Sie ein öffentliches STACKIT-Image oder importieren Sie ein konvertiertes (raw, qcow2 oder iso).
Noch wird nichts angewendet
Der Entwurf dient der Prüfung. Der Lauf wendet nie etwas an; das Anwenden ist ein Schritt, den eine Person mit OpenTofu ausführt.
Phase 4: Daten
Der Lauf führt auf, was Daten hält. Er überträgt sie nicht.
Ein Verfahren je zustandsbehafteter Einheit
Alle drei Einheiten zeigen in migration/data-movement.md das Verfahren UNKNOWN und den Zustand DECISION_REQUIRED.
RPO, Ausfallzeit und Datenklasse sind festgehalten
RTO, RPO und tolerierte Ausfallzeit übernimmt der Lauf aus einer Anwendungsdatei (--applications), genau so, wie sie dort stehen. Fehlen sie, zeigt die Tabelle zum Datenumzug NOT_PROVIDED für Datenklasse, RPO und Ausfallzeit, und der Lauf nimmt nichts an.
PostgreSQL hat einen Dump-und-Restore- oder Replikationsplan
Zum Beispiel pg_dump und pg_restore für eine kleine Datenbank, logische Replikation für einen kurzen Cutover. Größe, Änderungsrate und tolerierte Ausfallzeit entscheiden.
Objektdaten haben einen Kopierplan, bei Bedarf mit zweiter Kopie
Das Quell-Storage-Konto ist georedundant. STACKIT Object Storage hat keine verwaltete regionsübergreifende Replikation; eine zweite Kopie braucht einen eigenen Sync-Job.
Die Redis-Entscheidung ist ausdrücklich getroffen
Cache neu aufbauen oder Daten mitnehmen. Azure exportiert RDB-Snapshots nur in den Stufen Premium und Enterprise; der Standard-Cache dieser Demo hat also keinen Exportweg. Das STACKIT-Backup stellt in dieselbe Instanz wieder her; ein Backup für eine andere Instanz laden Sie herunter (dafür ist ein Verschlüsselungsschlüssel nötig) und spielen es von Hand ein.
Datenträger werden exportiert, bevor die VM angefasst wird
Eine VHD lässt sich nicht von einem Datenträger herunterladen, der an einer laufenden VM hängt; halten Sie die VM an oder erstellen Sie einen Snapshot. STACKIT importiert raw, qcow2 und iso.
Phase 5: Cutover
Reihenfolge, Namen und der Weg zurück.
Die Wellenfolge ist akzeptiert
migration/technical-sequencing.md setzt Key Vault, PostgreSQL, Redis, Storage und Netzwerk zuerst, das Subnetz an zweite und die Server an dritte Stelle. Eine Welle ist ein Ausgangspunkt für einen Zeitplan.
Namen, Adressen und Zertifikate sind aufgeführt
Der Lauf fand in dieser Quelle keine DNS- oder Zertifikatsfakten. Das heißt nicht, dass es keine gibt: Führen Sie jeden Namen, jede Adresse und jedes Zertifikat auf, die Clients nutzen.
Clients haben ihre neuen Zugangsdaten
STACKIT erzeugt das Passwort der Valkey-Zugangsdaten; der Entwurf stellt es als sensible Ausgabe erp_valkey_credential_password bereit, und im State steht es im Klartext. Der PostgreSQL-Benutzer ist nicht Teil dieses Entwurfs; legen Sie ihn samt Passwort selbst an. Geben Sie beides vor dem Cutover an die Clients.
Für jeden Schritt ist ein Rückweg geschrieben
Der Plan sagt zu seinen manuellen Schritten, dass er nicht weiß, wie sie rückgängig gemacht werden. Schreiben Sie den Rückweg samt Verantwortlichem, bevor das Fenster öffnet.
Praxis: DNS-TTLs vorab senken
Eine allgemeine Maßnahme, keine Ausgabe des Laufs: Verkürzen Sie die TTL der Einträge einige Tage vor dem Cutover, damit ein Rückweg schnell greift.
Phase 6: Nachbereitung
Nachweis, Protokoll und Stilllegung.
Die Prüfungen nach den Schritten sind abgehakt
Jede Ressource in execution/verify/checks.md existiert im STACKIT-Projekt, und der OpenTofu-State führt sie.
Der Fortschritt ist protokolliert
In review/progress.yaml halten Sie jeden Schritt als in Arbeit, erledigt, fehlgeschlagen oder verzichtet fest. Die Datei protokolliert, was Sie getan haben; bewiesen wird damit nichts.
Der Zugriff ist je Rolle getestet
Melden Sie sich mit je einem Prinzipal pro Rolle an und bestätigen Sie, was funktioniert und was abgelehnt wird.
Die Azure-Seite bleibt, bis die Prüfungen bestanden sind
Betreiben Sie die Quelle für eine vereinbarte Überlappung weiter und legen Sie sie dann mit einem eigenen Ticket still.
Der Lauf wird auf dem Endstand wiederholt
Bewerten Sie nach Änderungen am Terraform erneut, damit der Bericht dem tatsächlichen Stand entspricht.
Welche Datei beantwortet welche Frage
| Frage | Datei im Lauf | Was Sie finden |
|---|---|---|
| Was wurde gelesen, was wurde daraus? | assessment.json, migration/source-target.csv | Einheit, Klasse, Konfidenz, STACKIT-Ziel |
| Was braucht eine Person? | engineering/architect-report.md, migration/work-packages.csv | Prüfwarteschlange und Arbeitspakete mit verantwortlichen Rollen |
| Was wurde nicht übernommen? | engineering/not-carried.csv | Einstellung für Einstellung, mit Begründung |
| In welcher Reihenfolge? | migration/technical-sequencing.md, migration/waves.csv | Wellen aus Abhängigkeiten |
| Wo werden Daten übertragen? | migration/data-movement.md | Zustandsbehaftete Einheiten und offenes Verfahren |
| Was hake ich ab? | execution/verify/checks.md | Vor und nach jedem Schritt |
Dateinamen aus dem Demo-Lauf. Welche Dateien entstehen, hängt von der Eingabe und den Laufoptionen ab.
Fragen zur Checkliste
Ist diese Checkliste ein Plan?
Sie ist die Liste der Prüfungen rund um einen Plan. Der Plan selbst, mit geordneten Schritten und Verantwortlichen, ist execution-plan.json und die Datei mit dem Migrationsplan im Lauf.
Brauche ich einen Lauf, um sie zu nutzen?
Nein, aber jede Zeile verweist auf eine Datei, die ein Lauf schreibt. Ohne Lauf beantworten Sie dieselben Fragen von Hand und halten die Antworten in Ihrem eigenen Tracker fest.
Warum fragt der Lauf nach dem Verantwortlichen einer Entscheidung?
Jedes Arbeitspaket nennt eine Rolle, etwa Identity Architect oder Network Architect, damit eine Prüfung von Anfang an einen Verantwortlichen hat.
Was steht nicht auf dieser Checkliste?
Verträge, Mitarbeiterschulungen und Anwendungstests. Sie liegen außerhalb dessen, was eine Terraform-Bewertung sehen kann.
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.