ELKE CLOUD → STACKIT · CHECKLIST

STACKIT-migratiechecklist voor cloudarchitecten

Een checklist is alleen nuttig als elk vakje naar bewijs verwijst. Deze checklist telt zes fasen, van inventarisatie tot uitfasering, en elke controle noemt het bestand van een StackToIT-run waarin het antwoord staat. De aangehaalde bestanden komen uit een run op een kleine AWS-omgeving die voor deze pagina is opgezet: een netwerk, een webserver, een PostgreSQL-database, een bucket en een secret.

Wat de run voor uw checklist schrijft

Beoordeeld door StackToIT op 4 november 2026. Links: de golfvolgorde die de run berekende uit de afhankelijkheden tussen de zeven resources. Rechts: de eerste regels van de controlelijst die de run schreef, klaar om af te vinken.

Golfvolgorde van de runmigration/technical-sequencing.md
## 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 |
Af te vinken controlesexecution/verify/checks.md
## 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.
  • Golven zijn een startpunt

    De run zegt het zelf: eenheden in dezelfde golf kunnen parallel worden verplaatst, en de volgorde is een startpunt voor uw golfplanning, geen schema.

  • Controles zijn gegenereerd, niet generiek

    Elk vakje noemt een stap van het plan en de voorwaarde die vooraf moet gelden, bijvoorbeeld dat de variabele project_id een waarde heeft.

1. Inventarisatie

Stel vast wat er bestaat en hoeveel ervan de tool kon zien.

  • Maak de bron compleet

    De run meldde VARIABLE_UNRESOLVED omdat de variabele db_password geen waarde had. Geef het variabelenbestand mee met --var-file voordat u op de aantallen vertrouwt. Controle: de consolesamenvatting en summary.source_inputs in assessment.json.

  • Lees de klasse van elke eenheid

    Zeven resources werden zeven eenheden: één DIRECT, vijf RECONFIGURE en één REPLATFORM, geen REDESIGN. De klasse benoemt het soort werk, maar geeft er geen toestemming voor. Controle: assessment.json, engineering/architect-report.md.

  • Open de lijst met niet overgenomen eigenschappen

    engineering/not-carried-summary.csv telt de eigenschappen van een eenheid die het concept niet overneemt. In deze run: twee voor de database (het wachtwoord en skip_final_snapshot), één voor het secret, één voor het subnet. Regel elk punt met de eigenaar van de eenheid.

  • Zoek de stateful eenheden

    migration/data-movement.md noemt de database en de bucket stateful, met het mechanisme UNKNOWN en de status DECISION REQUIRED. Het vermeldt ook wat de bron u niet vertelt: datavolume, wijzigingssnelheid, toegestane downtime, recovery point.

2. Ontwerp

Zet open vragen om in vastgelegde antwoorden.

  • Beantwoord het beslissingsregister

    De console meldde 6 beslissingen om te nemen en 3 standaardwaarden om te bevestigen. De bestanden tellen anders: decisions.json van dezelfde run bevat 19 open records, dus vink elk record af in het bestand, niet aan de hand van het cijfer uit de console. Voorbeelden uit deze run: hoe de databasegegevens worden verplaatst, of een publiek endpoint acceptabel is voor PostgreSQL Flex, voor welke flavor de afgeleide omvang staat. Controle: executive/decisions.md, decisions.json.

  • Beoordeel elke wijziging in blootstelling

    Niet aangetoond is dat de brondatabase publiek bereikbaar was; de STACKIT-instance heeft daarentegen een openbaar endpoint dat alleen door de clientlijst wordt beperkt. De run signaleert ook dat het subnet geen internetroute had, terwijl het netwerk in het concept via STACKIT source NAT naar buiten gaat. Beide zijn architectuurwijzigingen die u accepteert of anders ontwerpt.

  • Bevestig afgeleide omvang

    Het concept koppelt db.m5.large (2 vCPU, 8 GiB) aan de flavor 2.16-replica (2 vCPU, 16 GiB), de kleinste replica-flavor die dit dekt, en rekent 100 GiB opslag om naar 108. De run noemt dit een voorstel. Bevestig het of kies een andere omvang.

  • Controleer de landing zone

    migration/landing-zone-requirements.md noemt wat de organisatie en het project moeten leveren vóór de eerste apply, en de waarden die een persoon aanlevert.

3. Bouw

Bereid het doel voor en pas het concept in de juiste volgorde toe.

  • Lever de open waarden aan

    Hier wachten 15 van de 15 geautomatiseerde stappen zonder beslissingen nog op een waarde: project_id, orders_access_scope, orders_allowed_cidrs en postgresflex_storage_class. Schrijf ze in review/target-values.tfvars en draai opnieuw.

  • Benoem het image en het machinetype

    Het bootimage is een variabele die een persoon instelt, nooit een image-ID die de tool raadt. Hetzelfde geldt voor het machinetype en de grootte van het bootvolume van de webserver.

  • Volg execution/terraform/apply.md

    OpenTofu past het hele concept in één keer toe en dwingt geen handmatige stappen of API-aanroepen af. Het bestand noemt wat vóór de apply moet zijn afgerond en, waar nodig, een eerste apply van geselecteerde blokken met -target.

  • Beslis over de API-opt-in

    Het secret wordt geschreven via een STACKIT-API die niet als algemeen beschikbaar is gedocumenteerd. Het plan doet zo'n aanroep niet totdat de Platform Architect de opt-in-beslissing in executive/decisions.md beantwoordt; de console noemt dit als eerste blokkade.

4. Data

Kies het mechanisme, verplaats, bewijs.

  • Kies een methode per stateful eenheid

    Voor de database houdt het plan twee methoden open: een dump die binnen de schrijfstop wordt teruggezet, of logische replicatie. Op Amazon RDS vereist logische replicatie dat de statische parameter rds.logical_replication op 1 staat en dat de broninstance opnieuw wordt opgestart, dus het is een wijziging aan de bron. Voor de bucket: een kopie met rclone, of de AWS CLI via een staging-map. Kies op basis van datavolume, wijzigingssnelheid en toegestane downtime.

  • Geef het nieuwe databasewachtwoord door

    Het bronwachtwoord wordt niet gekopieerd. STACKIT genereert er een voor de gemigreerde gebruiker en het concept toont het als sensitive output. Geef het vóór de cutover aan elke client; de Terraform-state bevat het in platte tekst.

  • Plan de reconcile

    Drie handmatige reconcile-stappen vergelijken bron en doel terwijl de schrijfprocessen zijn gestopt. De controles voor de database omvatten onder meer rijaantallen, tabelchecksums en sequences.

  • Exporteer voordat u vernietigt

    De brondatabase gebruikt skip_final_snapshot, en de instance in het concept heeft ook geen instelling voor een laatste back-up. Exporteer de gegevens eerst als ze behouden moeten blijven.

5. Cutover

Schakel over op basis van een beslissing, met een weg terug.

  • Leg de cutoverfeiten zelf vast

    De run vond geen DNS-recordset, certificaat of publiek adres om opnieuw te binden en zegt dat dit niets bewijst over namen en adressen buiten de gescande bron. Maak er zelf een lijst van.

  • Leg de rollbackgrens vast

    De reconcile-stap bevat een controle met de naam rollback-limit, het punt waarna een rollback gegevens verliest. De eigenaar legt die vast vóór het venster. Tot de overschakeling wijzen clients nog naar de bron.

  • Sluit de egress-beslissing af

    STACKIT maakt op de security group een allow-all-IPv4-egressregel aan die het concept niet beheert, terwijl de bron alleen de egress toestond die erin stond. Beslis of u die na de apply verwijdert.

  • Benoem wie over go of rollback beslist

    Het plan wijst de controle van de gemigreerde omgeving en de go- of rollback-beslissing toe aan rollen, onder andere een Migration Owner. Koppel de rollen aan personen.

6. Nazorg

Rond af en bewaar het dossier.

  • Verifieer de gepubliceerde map

    stacktoit verify controleert de runmap aan de hand van het manifest en de artefacten onderling. Het is geen handtekening en geen bewijs dat er iets in een cloud is gewijzigd.

  • Draai opnieuw na elk antwoord

    Antwoorden gaan in review/inputs.yaml en review/decisions.yaml, en de volgende run leest ze. Let op antwoorden die de run als ongeldig of verouderd meldt.

  • Bewaar de bron tot de acceptatie

    De stappen voor het kopiëren van gegevens zeggen dat de bronbucket en de toegang ongemoeid blijven totdat het doel is geverifieerd. Uitfaseringspakketten voor de bron komen als laatste in het plan.

  • Houd de voortgang bij

    review/progress.yaml is de template voor een voortgangsjournaal dat een latere run kan lezen met --progress.

Welk bestand beantwoordt welke vraag

Open ze in deze volgorde wanneer u een run beoordeelt.

VraagBestandWat u daar leest
Is de bron compleet?console.txt, assessment.jsonBronstatus en ontbrekende invoer
Wat is de klasse van elke eenheid?engineering/architect-report.mdEenhedentabel met klasse, zekerheidsniveau en redenen
In welke volgorde verhuizen de eenheden?migration/technical-sequencing.mdGolven berekend uit afhankelijkheden
Wat moet worden beslist?executive/decisions.mdBeslissingen met opties en de stappen die ze tegenhouden
Wat wordt niet overgenomen?engineering/not-carried.csvEigenschappen die het concept weglaat, per eenheid
Wat lever ik aan?review/target-values.tfvarsOpen variabelen van het concept
Wie doet wat?migration/work-packages.csvWerkpakketten met eigenaarsrol en status
Hoe worden gegevens verplaatst?migration/data-movement.mdStateful eenheden, mechanisme en controles

Een run is een voorstel. Niets daarin is goedgekeurd totdat uw architecten de beslissingen vastleggen.

Vragen van architecten over de checklist

Vervangt deze checklist ons eigen wijzigingsproces?

Nee. De checklist levert uw proces het bewijs om mee te werken. De run is een voorstel, en elke beslissing, goedkeuring en uitvoeringsstap blijft bij uw mensen.

Waarom wachten zoveel stappen nog?

Omdat de bron niet alles vermeldt. In de demorun wachten stappen op een project-ID, een toegangslijst, een opslagklasse en een handvol beslissingen. Die beantwoorden is het werk van de ontwerpfase.

Staat de volgorde van de fasen vast?

De fasen volgen de volgorde van de afhankelijkheden: u kunt een flavor niet dimensioneren voordat u de klasse kent, en u kunt niet overschakelen voordat de datamethode is gekozen. Binnen een fase bepaalt u zelf de volgorde.

Waar komen de Terraform-bestanden vandaan?

StackToIT schrijft een STACKIT-Terraform-concept in de map terraform van de run voor de resources die het kan uitwerken. Beoordeel het met het team van het doelplatform vóór een apply.

Bronnen

Uw volgende stap: STACKIT.

Vertel ons over uw omgeving, dan laten wij zien wat StackToIT daarvoor oplevert: doelarchitectuur, Terraform-artefacten en een gestructureerd migratieplan.

Laat uw gegevens achter, onze specialisten nemen contact met u op.

Liever zelf een e-mail sturen? connect@stacktoit.com

Wij gebruiken uw gegevens alleen om dit verzoek te beantwoorden en een mogelijke pilot te bespreken. Privacyverklaring