CLOUD-MIGRATION · BESTANDSAUFNAHME UND INVENTAR
Bestandsaufnahme für die Cloud-Migration: das Infrastrukturinventar aufbauen
Ein Migrationsplan ist nur so gut wie sein Inventar. Statt einer Tabelle aus Konsolen-Screenshots baut StackToIT das Inventar aus dem Code, der die Umgebung definiert: was existiert, was existieren kann, welches Modul es besitzt, was wovon abhängt und welche Dienste Daten halten. Dieser Leitfaden zeigt das Inventar, das ein echter Lauf für eine kleine Umgebung erzeugt hat.
Was existiert und was nur existieren kann
Eine für diesen Leitfaden geschriebene Demo-Umgebung, von StackToIT am 4. November 2026 bewertet: eine Datenbank, eine Queue, eine Bucket-Map, ein optionales Replikat und ein Modul. Links die Zeilen der Eingabe, die die Existenz unsicher machen, rechts die vollständige Liste summary.conditional_units aus assessment.json, formatiert, weil die Datei aus einer einzigen Zeile besteht; kein Feld ist weggelassen.
variable "enable_replica" {
type = bool
default = false
}
resource "aws_s3_bucket" "data" {
for_each = var.buckets
bucket = "acme-${each.key}-${data.aws_caller_identity.current.account_id}"
}
resource "aws_db_instance" "orders_replica" {
count = var.enable_replica ? 1 : 0
identifier = "orders-replica"
replicate_source_db = aws_db_instance.orders.identifier
instance_class = "db.m6g.large"
skip_final_snapshot = true
}[
{
"id": "aws_db_instance.orders_replica",
"source_type": "aws_db_instance",
"presence_cause": {
"kind": "root-variable-overridable",
"where": "count",
"expr": "var.enable_replica ? 1 : 0",
"variables": [
"var.enable_replica"
]
},
"would_be_class": "MANUAL_REVIEW",
"would_be_confidence": "LOW",
"state": "DISABLED_ON_DEFAULTS_BUT_OVERRIDABLE",
"state_inputs": [
"var.enable_replica"
],
"overridden_by": [
"-var-file",
"-var",
"TF_VAR_enable_replica"
]
},
{
"id": "aws_s3_bucket.data",
"source_type": "aws_s3_bucket",
"presence_cause": {
"kind": "root-variable-overridable",
"where": "for_each",
"expr": "var.buckets",
"variables": [
"var.buckets"
]
},
"would_be_class": "DIRECT",
"would_be_confidence": "MEDIUM",
"target": "STACKIT Object Storage",
"state": "PRESENT_ON_DEFAULTS",
"state_inputs": [
"var.buckets"
],
"overridden_by": [
"-var-file",
"-var",
"TF_VAR_buckets"
]
}
]Ein count von null ist eine Antwort
Das Replikat hat count = var.enable_replica ? 1 : 0. Mit dem Standardwert der Variable ist es abgeschaltet; der Lauf führt es daher als bedingt, vermerkt, dass eine Variable es einschalten kann, und hält daneben die Klasse fest, die es sonst hätte: MANUAL_REVIEW.
Eine Map aus Buckets ist eine Anzahl Buckets
Das for_each über var.buckets erzeugt je Schlüssel einen Bucket. Der Lauf führt die Einheit als mit Standardwerten vorhanden, mit zwei Instanzen, und nennt die Variable, die die Anzahl bestimmt. Eine andere Variablendatei ändert das Inventar; übergeben Sie also die, die Ihre Pipeline nutzt.
Nichts fällt stillschweigend weg
Einheiten, die abgeschaltet, unentschieden oder erst zur Plan-Zeit entschieden sind, werden gezählt und benannt. So vermeidet ein Inventar den üblichen Fehler, aufzulisten, was heute läuft, und zu vergessen, was ein Schalter morgen hinzuholt.
Das Inventar in Zahlen und in Abhängigkeitsreihenfolge
Aus demselben Lauf. Links die Zusammenfassung, die die Engine ausgibt, rechts die ersten Zeilen von migration/waves.csv, die die Einheiten nach ihren Abhängigkeiten ordnet.
────────────────────────────────────────────
Source: input
Source files: 2
Resources scanned: 11 (8 in the root module · 3 inside 1 module call)
support resources: 1 (+0 Terraform helpers, out of scope; 1 + 0 = the 1 support node of summary.support.nodes in assessment.json)
Migration units: 7 known-present (7 instances) · 2 conditional
Unit dependencies: 6
Modules: 1 module call (0 external, 1 local): 1 loaded, 0 not downloaded, 0 invalid
module.worker ./modules/queue_worker 2 units (RECONFIGURE 1 · REDESIGN 1) · 3 resources
Source checks: Built-in source checks passed — OpenTofu validation of the source was not run
Source completeness: RUNTIME_TOPOLOGY_PARTIAL — 2 unit(s) have a count/for_each that is not known statically; whether and how often they exist is decided at plan timewave,wave_state,unit,type,module_call,presence,class,confidence,application,application_status,proposed_group
1,MEMBER,aws_sqs_queue.jobs,aws_sqs_queue,,KNOWN_PRESENT,REPLATFORM,MEDIUM,,PROPOSED,jobs-worker
1,MEMBER,aws_vpc.main,aws_vpc,,KNOWN_PRESENT,RECONFIGURE,MEDIUM,,UNASSIGNED,
1,MEMBER,module.worker.aws_cloudwatch_log_group.worker,aws_cloudwatch_log_group,module.worker,KNOWN_PRESENT,RECONFIGURE,MEDIUM,,UNASSIGNED,
2,MEMBER,aws_subnet.db_a,aws_subnet,,KNOWN_PRESENT,RECONFIGURE,MEDIUM,,UNASSIGNED,
2,MEMBER,aws_subnet.db_b,aws_subnet,,KNOWN_PRESENT,RECONFIGURE,MEDIUM,,UNASSIGNED,
2,MEMBER,module.worker.aws_lambda_function.worker,aws_lambda_function,module.worker,KNOWN_PRESENT,REDESIGN,LOW,,PROPOSED,jobs-worker
3,MEMBER,aws_db_instance.orders,aws_db_instance,,KNOWN_PRESENT,REPLATFORM,MEDIUM,,UNASSIGNED,
0,NOT_A_MEMBER,aws_db_instance.orders_replica,aws_db_instance,,CONDITIONAL,MANUAL_REVIEW,LOW,,UNASSIGNED,
0,NOT_A_MEMBER,aws_s3_bucket.data,aws_s3_bucket,,CONDITIONAL,DIRECT,MEDIUM,,UNASSIGNED,Ressourcen und Einheiten sind verschiedene Zahlen
Elf Ressourcen ergeben neun Einheiten: sieben sicher vorhandene und zwei bedingte. Die übrigen zwei sind ebenfalls erfasst: Die DB-Subnetzgruppe ist die eine Support-Ressource, die die Konsole nennt, und assessment.json ordnet das Lambda-Event-Source-Mapping als Bestandteil der Einheit der Funktion zu. Die drei Ressourcen des Modulaufrufs zählen mit denen des Root-Moduls.
Das Modul gehört zum Inventar
Das lokale Modul queue_worker wird geladen, seine drei Ressourcen werden module.worker zugeordnet, und seine Einheiten liegen in denselben Wellen wie die des Root-Moduls. Ein Modul, das sich nicht laden lässt, wird als nicht heruntergeladen gemeldet, nie wortlos übersprungen.
Wellen sind eine Reihenfolge, kein Terminplan
Welle 1 enthält, was von nichts abhängt; Welle 3 die Datenbank, die beide Subnetze braucht. Die Einheiten, die erst existieren, wenn OpenTofu plant, haben noch keine Welle. So zeigt der Lauf offen, was er noch nicht einordnen kann.
Wo die Daten liegen
Der nützlichste Teil eines Inventars für eine Migrationsleitung ist die Liste der Dienste, die Daten halten. Der Lauf schreibt sie als migration/data-movement.md. Hier die ersten Zeilen für die Demo-Umgebung.
## Stateful source units
| 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_db_instance.orders_replica | aws_db_instance | NO_TARGET_PROPOSED | | UNKNOWN | DECISION_REQUIRED | NOT_PROVIDED | NOT_PROVIDED | NOT_PROVIDED |
| aws_s3_bucket.data | aws_s3_bucket | STACKIT Object Storage | | UNKNOWN | DECISION_REQUIRED | NOT_PROVIDED | NOT_PROVIDED | NOT_PROVIDED |Zustandsbehaftete Einheiten werden benannt, nicht übertragen
Drei Einheiten halten Daten: die Datenbank, das Replikat und die Bucket-Map. StackToIT überträgt nie Daten; es stellt fest, dass eine Person für jede ein Verfahren wählen muss. Das allocated_storage = 200 der Datenbank steht dort als bereitgestellte Kapazität, nicht als Datenmenge.
Was der Code nicht sagt, bleibt leer
Datenklasse, RPO und Ausfalltoleranz stehen auf NOT_PROVIDED. RPO und Ausfalltoleranz tragen Sie in die Anwendungsdatei ein; die Datenklasse liefern die Datenverantwortlichen. Eine Lücke ist ehrlicher als ein erfundener Standardwert.
Welche Frage wo beantwortet wird
| Inventarfrage | Datei des Laufs | Inhalt |
|---|---|---|
| Was existiert heute? | assessment.json | Jede Einheit mit Klasse, Konfidenz, Ziel, Begründung und Quellzeile |
| Was kann existieren? | assessment.json (bedingte Einheiten) | count- und for_each-Ausdrücke, die entscheidenden Variablen, der Zustand mit Standardwerten |
| Was gehört zu welchem Modul? | assessment.json, migration/technical-sequencing.md | Modulaufrufe, wie sie geladen wurden, Einheiten je Modul und Welle |
| Was hängt wovon ab? | migration/waves.csv, architecture/dependencies.mmd | Abhängigkeitsreihenfolge und der Graph dahinter |
| Wo liegen Daten? | migration/data-movement.md | Zustandsbehaftete Einheiten, Zieldienst, bereitgestellte Kapazität, offene Datenfragen |
| Was ist noch unbekannt? | decisions.json, migration/prerequisites.md | Entscheidungen, zu bestätigende Standardwerte und Einheiten, die auf eine Antwort warten |
Dateinamen, wie der Lauf sie schreibt.
Eine Abfolge für die Bestandsaufnahme, die trägt
Allgemeine Praxis, aufgebaut auf den obigen Artefakten.
1 · Die relevanten Root-Module wählen
Richten Sie die Engine auf das Verzeichnis, das die Infrastruktur deklariert, nicht auf ein Unterverzeichnis einer größeren Konfiguration. Behalten Sie die Lock-Datei und die Variablendateien Ihrer Pipeline.
2 · Dort ausführen, wo der Code liegt
Eine Standardbewertung läuft auf Ihrem Rechner und lädt das Repository nicht hoch. Fügen Sie --offline hinzu, wenn der Rechner kein Netzwerk hat; fehlende Module werden dann als fehlend gemeldet.
3 · Zuerst die Zahlen lesen
Ressourcen, Einheiten, Module, bedingte Einheiten und Vollständigkeit der Quelle zeigen, ob das Inventar vollständig oder lückenhaft ist, bevor Sie eine Zeile lesen.
4 · Die bedingten Einheiten klären
Legen Sie die Variablen fest, die Ressourcen ein- oder ausschalten, oder übergeben Sie eine Variablendatei, und führen Sie erneut aus. Jede bedingte Einheit ist eine Frage an den Plattformverantwortlichen.
5 · Ergänzen, was Code nicht wissen kann
Geben Sie Anwendungen, Verantwortliche, RTO, RPO und Ausfalltoleranz an und holen Sie die Datenklasse bei den Datenverantwortlichen ein. Die Anwendungsdatei gruppiert Ressourcen zu den Anwendungen, die das Unternehmen kennt.
6 · Mit der Realität vergleichen
Code ist nicht die Umgebung. Von Hand erzeugte Ressourcen stehen nicht darin. Für AWS kann ein optionaler discover-Befehl ein Inventar einbringen, das Sie mit Ihren eigenen CLI-Zugangsdaten sammeln, sodass der Lauf es mit der Quelle vergleichen kann.
Drei Arten von Quellen
Terraform und OpenTofu
Root-Module mit lokalen und entfernten Modulen und Variablen. Das ist die reichste Eingabe: Sie trägt Konfiguration, Referenzen und Anzahlen.
VMware RVTools
Ein Export von virtuellen Maschinen, Datenträgern und Netzwerken (etwa die Tabs vInfo, vDisk und vNetwork). Die Engine liest nur die Datei und verbindet sich nicht mit vCenter. RVTools enthält keine Subnetzmasken und kein Anwendungsverhalten; beides liefern Sie separat.
Ein SourceBundle-Archiv
Ein Archiv, das ausdrücklich über eine Eingabeoption gewählt wird, für Quellen, die als Bundle vorbereitet wurden.
Fragen, die Migrationsleitungen stellen
Braucht die Bestandsaufnahme Zugriff auf unser Cloud-Konto?
Nein. Eine Standardbewertung liest nur Code und Variablen, braucht keine Cloud-Zugangsdaten und lädt das Repository nicht hoch. Der optionale AWS-Vergleich nutzt die Zugangsdaten Ihrer eigenen AWS CLI.
Was, wenn Ressourcen außerhalb von Terraform entstanden sind?
Sie stehen nicht im Code und damit nicht im Inventar. Vergleichen Sie mit einem aus dem Konto gesammelten Inventar oder nehmen Sie sie vor der Bewertung in den Code auf.
Warum fehlen manche Einheiten in der Abhängigkeitsreihenfolge?
Einheiten, deren Existenz erst entschieden wird, wenn OpenTofu plant, haben keine Welle. Klären Sie die Variablen oder Daten, von denen sie abhängen, und der Lauf ordnet sie ein.
Wie hängt das mit dem STACKIT Migration Framework zusammen?
Das Framework beginnt mit einer Bewertungsphase, die eine faktenbasierte Ausgangslage schafft. Das obige Inventar ist diese Ausgangslage, aus dem Code gewonnen.
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.