Checkliste für die Migration von Google Cloud zu STACKIT

Die Demo-Umgebung und die Entscheidungen des Laufs

Aus zehn Ressourcen wurden neun Einheiten: Die Subscription geht in ihrem Topic auf. Die Konfidenz ist bei jeder Einheit MEDIUM, weil die Quelle google 8.4.0 ohne Lock-Datei deklariert. Der Lauf entstand am 4. November 2026.

1. Bestandsaufnahme

• Das Scan-Ergebnis ist vollständig

  Öffnen Sie assessment.json und lesen Sie summary.source_status und source_validation. COMPLETE mit bestandenen eingebauten Prüfungen heißt: Alle Dateien wurden gelesen. Ein fehlendes Modul oder eine unlesbare Datei zeigt sich hier, nicht erst später.

• Die Provider-Version ist festgelegt

  Committen Sie .terraform.lock.hcl und starten Sie erneut. Ohne festgelegten Provider kommt keine Einheit über die Konfidenz MEDIUM hinaus; der Demo-Lauf vermerkt das für alle neun.

• Was Terraform nicht kennt, ist aufgeführt

  In der Konsole angelegte Ressourcen, Organisationsrichtlinien und anderswo verwaltete gemeinsame Netzwerke stehen nicht im Scan. migration/technical-sequencing.md sagt ausdrücklich, dass Namen, Adressen oder Zertifikate außerhalb der gescannten Quelle nicht erfasst werden. Halten Sie fest, wer für welche Lücke zuständig ist.

• Zustandsbehaftete Einheiten sind benannt

  migration/data-movement.md führt sie auf: zwei in der Demo, die Datenbank und den Bucket, beide mit unbekanntem Verfahren.

2. Design

• Die Zielregion ist beantwortet

  inputs-template.yaml enthält eine Anfrage, die den Entwurf blockiert: target.region. Beantworten Sie sie zuerst, denn regionsabhängige Anfragen werden für die gewählte Region neu gestellt.

• Jede Klasse ist geprüft

  engineering/architect-report.md enthält die Prüfwarteschlange. In der Demo: ein DIRECT, sechs RECONFIGURE, zwei REPLATFORM, kein REDESIGN oder BLOCKED. Alles mit REDESIGN braucht eine eigene Designseite, kein Ticket.

• Kritische Einstellungen haben eine verantwortliche Rolle

  decisions.json gruppiert sie: in der Demo sechs Einheiten und fünfzehn kritische Einstellungen. Weisen Sie jede einer Rolle zu; execution/manual/actions.md schlägt bereits Verantwortliche vor.

• Die Landing Zone steht

  migration/landing-zone-requirements.md nennt, was Organisation und Projekt vor dem ersten Anwenden bereitstellen müssen, und führt die Werte auf, die Sie liefern. Legen Sie das Projekt zuerst an.

Beleg: eine Cloud-SQL-Instanz, geprüft

Aus demselben Lauf. Links die Instanz, wie die Eingabe sie deklariert. Rechts der PostgreSQL-Flex-Block, den die Engine geschrieben hat; die Prüfkommentare darüber sind hier weggelassen. Die Prüfpunkte der Datenphase unten gehen von diesem Block aus.

resource "google_sql_database_instance" "core" {
  name             = "core-pg"
  region           = "europe-west3"
  database_version = "POSTGRES_15"

  settings {
    tier    = "db-custom-2-7680"
    disk_size = 100
  }
}

resource "stackit_postgresflex_instance" "core" {
  project_id = var.project_id
  name       = "core-pg"
  version    = "15"
  flavor_id  = "2.16"
  storage = {
    class = var.postgresflex_storage_class
    size  = 100
  }
  backup_schedule = "0 2 * * *"
  network = {
    acl = var.core_allowed_cidrs
  }
  retention_days = 32
}

• Flavor aus dem Katalog

  2.16 ist der kleinste Single-Node-Flavor, der die Quellstufe mit 2 vCPU und 7,5 GiB abdeckt.

• Zugriffsliste statt Netzwerk

  Die Quelle nennt keine autorisierten Netzwerke; die STACKIT-Instanz wird über core_allowed_cidrs erreicht, das keinen Standardwert hat und das Sie mit den Präfixen der Clients füllen.

• Aufbewahrung ist eine Untergrenze, keine Kopie

  Die Aufbewahrung der Quelle ist statisch nicht sichtbar, daher setzt der Entwurf 32 Tage an, das Minimum bei STACKIT.

3. Aufbau

• Jede Variable ohne Standardwert hat einen Wert

  In der Demo: project_id, batch_image_id, batch_machine_type, batch_boot_volume_size_gb, core_allowed_cidrs, postgresflex_storage_class und drei RabbitMQ-Werte (Plan, Version, zugelassene CIDRs). terraform/variables.tf beschreibt jede.

• NOT-CARRIED-Zeilen sind gelesen

  Die Demo zeigt 26 geprüfte Quelleigenschaften, 20 übernommen oder erklärt, 6 als NOT CARRIED benannt und keine ungeklärt. Suchen Sie in terraform/ danach und entscheiden Sie jede, etwa den Anzeigenamen des Service Accounts.

• Maschinentypen werden nach Last gewählt

  Der Entwurf überlässt den Flavor der Variable batch_machine_type. Die Allzweckfamilie von STACKIT kombiniert 4 vCPU mit 16 GB (g2i.4); wählen Sie nach gemessener Nutzung.

• Secrets werden von Hand neu angelegt

  Der Lauf entwirft eine Secrets-Manager-Instanz, nicht das Secret. Legen Sie den Schlüssel darin an, übernehmen Sie den Wert aus Ihrem bisherigen Secret-Speicher und gewähren Sie dem Service Account Zugriff.

4. Daten

• Je zustandsbehafteter Einheit ist ein Verfahren gewählt

  Nennen Sie Größe, Änderungsrate, tolerierte Ausfallzeit und Wiederherstellungspunkt für Datenbank und Bucket. Der Lauf führt Datenklasse, Wiederherstellungspunkt und Ausfallzeit als nicht angegeben und die Größe als nicht in der Quelle; ohne sie ist kein Plan tragfähig.

• Backup und Restore der Datenbank sind getestet

  Der Entwurf plant täglich um 02:00 ein Backup. Backups bleiben 32 bis 90 Tage, und eine Point-in-Time-Wiederherstellung erzeugt eine geklonte Instanz. Üben Sie vor dem Cutover eine Wiederherstellung.

• Bucket-Versionen sind entschieden

  Der Bucket hat Versionierung, und der Lauf markiert das. Entscheiden Sie, ob alte Objektversionen mitziehen oder zurückbleiben, und nutzen Sie für das Kopieren ein S3-kompatibles Werkzeug wie rclone.

• Messaging-Clients sind eingeplant

  Pub/Sub-Publisher und -Subscriber wechseln auf AMQP. Der Entwurf legt nur die RabbitMQ-Instanz an; Exchanges und Queues entstehen von Hand.

5. Cutover

• Die Wellen passen zu Ihren Abhängigkeiten

  migration/technical-sequencing.md ordnet die Demo in drei Wellen: sieben Einheiten, dann das Subnetz, dann die Instanz. Das ist ein Ausgangspunkt, kein Zeitplan.

• Namen und Adressen außerhalb des Scans sind aufgeführt

  Der Lauf nennt keine Cutover-Fakten für DNS oder Zertifikate und ergänzt, dass das nicht heißt, es gäbe keine. Führen Sie jeden Namen auf, der auf die Umgebung zeigt.

• Der Rollback ist dokumentiert

  Jeder manuelle Schritt in execution/manual/actions.md sagt, dass der Plan nicht weiß, wie er rückgängig zu machen ist. Wer den Schritt ausführt, dokumentiert, wie er zurückgenommen wird.

• Egress und DNS-Auflösung sind belegt

  network.tf markiert den privaten Egress des Subnetzes als unbewiesen und vermerkt, dass Googles Resolver interne Namen beantwortet, die die Standard-Nameserver von STACKIT nicht auflösen.

6. Nachbereitung

• Die Prüfungen sind abgehakt

  execution/verify/checks.md führt vor und nach jedem Schritt eine Prüfung auf, etwa ob eine Variable einen Wert hat und ob eine Ressource im State existiert.

• Die Bewertung läuft erneut

  Nachdem Sie Variablen geändert oder Anfragen beantwortet haben, starten Sie die Bewertung erneut mit demselben Ausgabeordner: Der Entwurf wird neu erzeugt, der frühere Lauf wandert in einen Unterordner previous-<run id> (oder wird mit --replace entfernt), sodass Sie beide vergleichen können.

• Zugriffe sind überprüft

  Rollen weist ein Mensch dem neuen Service Account zu. Google rät in Produktion von Basisrollen ab; geben Sie dem Konto nur das Nötigste.

• Die Quelle wird nach einer ruhigen Phase stillgelegt

  Löschen Sie Ressourcen, Schlüssel und Service Accounts in Google Cloud erst, wenn sie über einen vereinbarten Zeitraum niemand aufgerufen hat, und bewahren Sie einen Export auf.

Fragen von Teams zur Checkliste

Quellen

• STACKIT: Object Storage
• STACKIT: Service Accounts
• STACKIT: Maschinentypen für Server
• Google Cloud: Übersicht über IAM-Rollen