CUTOVER → STACKIT · CHECKLIST
Checklist voor cutover, rollback en ontmanteling naar STACKIT
Vink deze controles in volgorde af, dan komt het enige onomkeerbare moment van de migratie, de uitfasering van de databronnen, pas na een vastgelegde GO met een bewaarde back-up. De lijst volgt het uitvoeringsplan dat StackToIT schreef voor een portaal op AWS met een PostgreSQL-database, een objectbucket, een server met een publiek adres, een certificaat en een DNS-record: 78 stappen, waarvan 64 handmatig. Elke controle noemt het bestand dat het antwoord bevat, gegroepeerd per fase: ontwerp, bouw, data, cutover, rollback en nazorg.
1 · Ontwerp: voordat iets wordt gebouwd
De antwoorden vindt u in migration/technical-sequencing.md (de drie vakjes onder "Before wave 1"), decisions.json en engineering/architect-report.md.
Elke eenheid die het concept niet schrijft, heeft een eigenaar
migration/technical-sequencing.md vraagt om beoordeling van elke REDESIGN-, MANUAL_REVIEW- en BLOCKED-eenheid; deze run heeft er geen. Het enige hiaat is het certificaat: RECONFIGURE, met stackit_alb_certificate als doel maar niet geschreven door dit concept, dus terraform/README.md noemt het als aan de architect overgelaten.
De STACKIT-organisatie, mappen en projecten zijn ingedeeld
Eén project per omgeving is het gebruikelijke begin, zoals het plan het formuleert. Alles wat volgt veronderstelt dat het project bestaat.
Per dataeenheid zijn een overdrachtsmethode en -venster afgesproken
De run noemt de database en de bucket als dataeenheden, elk met meerdere kandidaatmethoden. Er wordt geen methode gekozen zolang de beslissing niet is beantwoord.
De versie van de bronprovider is vastgezet
Commit het lockbestand waar de run om vraagt. Tot dan heeft elke eenheid van die provider een open punt.
Herstelpunt en toegestane downtime zijn vastgelegd
De run noemt geen van beide: het plan markeert ze als niet opgegeven. Zonder die gegevens is het venster voor de schrijfstop niet te onderbouwen.
2 · Bouw: het doel bestaat en is gecontroleerd
Bestanden: terraform/, execution/terraform/apply.md en execution/verify/checks.md, waarvan de lijsten "before each step" en "after each step" afvinkvakjes zijn.
Variabelen zonder standaardwaarde hebben een waarde
Acht in deze run: project_id, het toegangsbereik, toegestane adresbereiken en opslagklasse van de database, het image, machinetype en de grootte van het bootvolume van de server, en de identifier van de DNS-zone. Het controlebestand noemt elk als stap vooraf.
Het concept is gevalideerd en gepland in een testproject
De README van de terraform-map vraagt eerst om tofu init, validate en plan in een testproject. De engine past nooit iets toe.
De STACKIT-diensten zijn ingeschakeld en de state is beschermd
terraform/README.md noemt de diensten die vóór de apply in project en regio moeten worden ingeschakeld (DNS, IaaS, Object Storage, PostgreSQL Flex) en waarschuwt dat de state het gegenereerde databasewachtwoord en bucketsecret in leesbare tekst bevat, dus de state-backend moet versleuteld en toegangsbeperkt zijn.
De nieuwe database, bucket, server en het publieke adres bestaan
Elke Terraform-stap heeft een controle achteraf "exists in the STACKIT project".
De DNS-zone is gekoppeld
Kies of maak de STACKIT-zone die de Route 53-zone vervangt en stel de zonevariabele in. De run controleert niet of de zone het juiste domein bevat. De STACKIT-documentatie beschrijft een script dat de recordsets van Route 53-zones naar STACKIT DNS kopieert en de NS- en SOA-records van de apex overslaat.
De certificaatvraag is beantwoord
De bron declareert een certificaat; of het de namen dekt die verhuizen, beoordeelt de run niet. Kies tussen opnieuw uitgeven, importeren of vervangen.
3 · Data: kopiëren, repeteren, bewijzen
Bestanden: migration/data-movement.md en terraform/handover/database-portal/data-move.md.
De preflight sluit elke onbekende controle af
Versies, extensies, rollen, netwerk en TLS, met alleen-leesquery's op bron en doel.
De proefrun in een scratchdatabase is gemeten
Het venster voor de schrijfstop wordt uit die tijden afgesproken, niet geraden.
De eerste kopie en de delta-syncs draaien
Voor de bucket zijn de AWS CLI-sync en rclone kandidaattools; voor de database logische replicatie of dump en restore.
Rijaantallen, checksums, sequences en één applicatiequery komen overeen
Dit is de reconcile-stap met gestopte schrijvers. Die eindigt in een vastgelegde GO of NO-GO.
4 · Cutover: de ene schakeling na de andere
Bestanden: het cutoveronderdeel C1 tot en met C5 van migration/technical-sequencing.md, en de MAN/cutover-stappen van execution-plan.json.
TTL's zijn vooraf verlaagd
Het plan leest de TTL van elk record uit de bron (hier 60 s, dus dit record is al kort) en stelt 60 s voor als doel. Het vraagt u het tijdstip van de wijziging en de oude TTL vast te leggen en één oude TTL te wachten vóór de overschakeling.
De cutover-gereedheid is bevestigd
Elke workloadstap en dataverplaatsing is klaar. Het plan kan niet zien welk ingangspunt welke store bedient, dus elke overschakeling wacht op alle andere.
Schrijvers zijn opgesomd en daarna gestopt
Som op wie schrijft, leg de verbindingsinstellingen van elke client vast en stop dan diensten, jobs en migraties. Laat de bron lees- en schrijfbaar en ongewijzigd.
De laatste sync en de reconcile slagen binnen de schrijfstop
Wijkt een getal of de applicatiequery af, stop dan en voer de rollback uit zonder iets om te schakelen.
De connectiestrings van elke client zijn omgeschakeld
Host, poort, database, inloggegevens en TLS-modus voor de database; endpoint, bucketnaam en sleutels voor de bucket. De applicaties liggen buiten de bron, dus hun eigenaren sommen ze op.
Het DNS-record wijst naar het nieuwe publieke adres
De recordwaarde gaat van het AWS-adres naar het STACKIT-adres. Controleer eerst door een STACKIT-nameserver rechtstreeks te bevragen en het antwoord met het oude te vergelijken.
Aanvragen bereiken het nieuwe adres en het oude ontvangt er geen
De controle leest de toegangslogs of metrics van beide kanten.
5 · Rollback: besloten voordat het venster opent
Bestanden: de rollbackvermelding van elke stap in execution-plan.json en het onderdeel Rollback van de overdracht voor de dataverplaatsing.
De oude verbindingsinstellingen zijn vastgelegd en bewaard
De rollback heeft ze nodig. De overdracht zegt dat u de oude waarden bewaart wanneer u omschakelt.
Een rollbacktrigger en een bewaardatum voor de bron zijn benoemd
Beide staan in het plan als onbekend en worden door de migratie-eigenaar aangeleverd. Niemand kan ze voor u verzinnen.
De rollback van de verkeersschakeling is bekend
Zet het DNS-record terug naar het AWS-adres. Laat de TTL tijdens het rollbackvenster verlaagd, zodat een tweede overschakeling snel ingaat.
Voor schrijfacties op STACKIT na de overschakeling is er een plan
Die staan niet op de bron. Kopieer ze met dezelfde methode in de andere richting terug, na een aparte repetitie, of accepteer het verlies schriftelijk.
De AWS-resources blijven staan tot de GO
Het plan faseert niets uit vóór de vastgelegde GO van de beslisstap voor de rollback.
6 · Nazorg: verifiëren, beslissen, opruimen, ontmantelen
Bestanden: de stappen MAN/verify en MAN/decommission van execution-plan.json; execution/manual/actions.md.
Een herstel is getest op STACKIT
Kloon de PostgreSQL Flex-instance naar een tijdstip ná de dataverplaatsing, lees en vergelijk die, leg de duur vast en verwijder de clone. Leg ook de datum vast tot wanneer de automatische AWS-back-ups worden bewaard.
GO of ROLLBACK is vastgelegd met het resultaat van elke controle
De beslisstap hangt af van elke verificatiestap. Zet bij GO de normale DNS-TTL terug.
Resten van de replicatie zijn verwijderd
Subscription, publication en slot, dumpbestanden, de verplaatshost in de toegangslijst. Roteer de inloggegevens die voor de verhuizing zijn gebruikt.
Van elke bronstore is een laatste back-up bewaard
De ontmanteling van de database of de bucket kan het plan niet ongedaan maken; alleen de laatste back-up herstelt de data, in een nieuwe resource. De bron noemt geen final_snapshot_identifier, dus het plan waarschuwt dat het verwijderen van de RDS-instance als beheerd mislukt tot een snapshotnaam is opgegeven.
Bronresources worden in afhankelijkheidsvolgorde uitgefaseerd
Bijvoorbeeld subnets vóór de VPC. Verwijder ze uit de bronconfiguratie en pas dat toe, in plaats van een gerichte destroy die verwijdert wat ervan afhangt.
Waar het venster opent en waar de weg terug eindigt
Letterlijke regelbereiken uit execution-plan.json van de run, op 4 november 2026 geschreven voor een omgeving die voor deze pagina is gemaakt: de bewerking, risico's en rollback van twee stappen. Links: de TTL-verlaging die de cutover opent. Rechts: de uitfasering van de database, de stap zonder weg terug.
"operation": {
"manual": {
"what": "Lower the TTL of the DNS names the clients of aws_eip.portal (aws_eip) resolve, ahead of its traffic switch: the source holds 1 Route 53 record that point to it: \"portal.example.com\" (aws_route53_record.portal): the source states a TTL of 60 s. Lower each TTL that is not an alias record's to a short value the person chooses (the plan suggests 60 s, which is also the lowest TTL STACKIT DNS takes for a record set; it is a suggestion, not a fact of the source)",
"why": "a resolver keeps the answer it holds for one TTL: a switch of aws_eip.portal made while resolvers still hold an answer cached under the old TTL leaves part of the clients on the AWS address until that answer expires, and lowering the TTL first shortens that tail to the lowered TTL",
"owner_role": "Network Architect",
"when": "at least 60 s (the longest TTL the source states) before the maintenance window of the traffic switch of aws_eip.portal, because resolvers keep the old answer for up to one TTL: a change made later does not reach the resolvers that already hold the old answer",
"required_input": "the old TTL of each name (stated above, or read with the command named), the TTL to lower it to (the owner's choice; the plan suggests 60 s), and a person who can change the record sets in Route 53",
"success_condition": "the record set of each name that has a TTL of its own shows the lowered TTL (`aws route53 list-resource-record-sets`), the TTL a resolver is given for each alias name is read and recorded, and one old TTL has passed since the change (the time of the change and the old TTL are recorded)"
}
},
"postconditions": [],
"decisions": [],
"risks": [],
"rollback": [
{
"capability": "MANUAL",
"how": "restore the old TTL of each name after the GO recorded at the rollback decision step; on a ROLLBACK leave it lowered during the rollback window, so that a second switch (back to AWS, then again) takes effect within the lowered TTL, and restore it when the owner decides to stay on AWS"
}
], "operation": {
"manual": {
"what": "Retire aws_db_instance.portal (aws_db_instance) in the AWS account after the GO: delete it the way it is managed (remove it from the source configuration and apply that, or delete it in the AWS console), once the resources that depend on it are retired (the steps it follows); a targeted destroy of the source configuration would also delete what depends on it",
"why": "aws_db_instance.portal keeps costing money and can still take traffic or writes after the cutover, so the two copies drift apart; StackToIT deletes nothing (it is read-only): a person retires it",
"owner_role": "Data Architect",
"when": "after the GO recorded at the rollback decision step",
"required_input": "the final backup of aws_db_instance.portal, kept for a number of days the owner decides (the plan states no default), and the GO recorded at the rollback decision step",
"success_condition": "aws_db_instance.portal no longer exists in the AWS account and its charges stop on the bill"
}
},
"postconditions": [],
"decisions": [],
"risks": [
"StackToIT performs none of this: it deletes nothing in any cloud, and no step of this plan automates the retirement",
"the source states no final_snapshot_identifier and not skip_final_snapshot = true: the provider documents the identifier as required when skip_final_snapshot is false (its default), so deleting the instance as managed fails until a name is stated; state it, and the snapshot it names is the final backup this step needs"
],
"rollback": [
{
"capability": "IMPOSSIBLE",
"how": "the plan cannot bring aws_db_instance.portal back: only the final backup the owner kept restores its data, into a new resource"
}
],Twee rollbackmogelijkheden
De TTL-stap is MANUAL: zet de oude TTL terug na de GO, of laat die verlaagd tijdens een rollback, zodat een tweede overschakeling snel gaat. De uitfasering is IMPOSSIBLE: alleen de laatste back-up brengt de data terug, in een nieuwe resource.
Eigenaren zijn rollen
De run noemt rollen zoals Migration Owner, Data Architect en Network Architect; wijs ze vóór het venster aan personen toe.
Vragen vóór het venster
Voert StackToIT de cutover uit?
Nee. Het schrijft de stappen, eigenaren, controles en rollbacknotities; mensen of OpenTofu voeren ze uit. Het sequencingbestand zegt dat het geen tijdsinschatting geeft.
Welke stappen kunnen niet worden teruggedraaid?
In deze run de uitfasering van de database en van de bucket: het plan meldt dat alleen de laatste back-up die de eigenaar heeft bewaard de data herstelt, in een nieuwe resource. De VPC, het certificaat en het DNS-record kunnen uit de bronconfiguratie opnieuw worden aangemaakt, al wordt wat ze buiten die configuratie bevatten niet hersteld.
Hoe lang moet de bron blijven staan?
Het plan laat dat open en vraagt de migratie-eigenaar om een datum. Bewaar de bron tot de vastgelegde GO, en langer als uw herstelobjectieven dat zeggen.
Waarom de DNS-TTL verlagen?
Zodat de overschakeling, en een terugschakeling, binnen de verlaagde TTL ingaan. Het plan stelt 60 seconden voor en behandelt dat als suggestie, niet als feit over uw bron.
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
Hartelijk dank.
Uw verzoek is bij ons binnengekomen. Onze specialisten nemen contact met u op.