De complete migratiegids van AWS naar STACKIT

De zeven stappen

De volgorde is die van de golven en werkpakketten van de run zelf.

1. 01

   1. De Terraform-code beoordelen

   Richt StackToIT op de map met uw AWS-Terraform. Het leest de configuratie en de modules offline, bouwt een afhankelijkheidsgraaf en kent elke resource een klasse en een doel toe. Er wordt niets aangeroepen in AWS of STACKIT.

2. 02

   2. De klassen lezen en de beslissingen nemen

   DIRECT- en RECONFIGURE-eenheden zijn regulier werk. REPLATFORM-, CONTAINERIZE- en REDESIGN-eenheden veranderen het programmeermodel. Kopieer decisions-template.yaml, leg uw antwoorden vast en voer het assessment opnieuw uit met --decisions; het nieuwe rapport laat zien welke antwoorden zijn toegepast en welke beslissingen nog openstaan.

3. 03

   3. Het fundament bouwen

   Maak de projectindeling, de netwerken en de security groups aan. Dit is golf 2 in de run, na de VPC-eenheid.

4. 04

   4. De data- en messagingservices opzetten

   Pas de concepten voor PostgreSQL Flex, Valkey, RabbitMQ, MongoDB Flex en Object Storage toe. Ze zijn leeg tot u data verplaatst.

5. 05

   5. De data verplaatsen

   De run schrijft per stateful eenheid een document voor de dataverplaatsing. StackToIT verplaatst zelf geen data; uw team voert de commando's uit na een proefrun.

6. 06

   6. Producers, consumers en clients omschakelen

   De cutoverwerkpakketten van de run schakelen eerst de dataconsumers en de clients om, daarna de workloads met de producers en consumers van berichten. Die nummering als volgorde lezen is onze samenvatting; bindend is per stap welke stappen eraan voorafgaan, zoals vermeld in execution/manual/actions.md.

7. 07

   7. Controleren, de weg terug bewaren, uitfaseren

   Voer de controles uit, leg de rollbackgrens vast, bewaar de bron gedurende de bewaartermijn die u bepaalt en faseer die daarna uit.

De commando's achter de stappen

Dit zijn de gedocumenteerde StackToIT-commando's, elk overgenomen van de openbare documentatiepagina die erboven staat. De optionele stap discover voegt een alleen-lezen AWS-inventaris toe om met de Terraform-code te vergelijken; explain herleidt een eenheid tot het bewijs; verify controleert een afgeronde run aan de hand van het manifest.

stacktoit assess ./aws-terraform

stacktoit discover commands
stacktoit discover aws ./aws-terraform-stacktoit --region eu-central-1
stacktoit assess ./aws-terraform ./aws-terraform-stacktoit

stacktoit explain ./terraform-stacktoit 'UNIT_ADDRESS'

stacktoit verify ./terraform-stacktoit

• Standaard offline

  assess zelf maakt geen verbinding met een AWS-account. discover aws gebruikt uw lokale AWS CLI-inloggegevens en alleen-lezen verzamelcommando's.

• Een concept is geen goedkeuring

  De documentatie is ondubbelzinnig: dat er een Terraform-concept bestaat, is geen goedkeuring om het toe te passen.

De run: 12 resources, 11 eenheden

Omgeving die voor deze pagina is opgesteld en op 4 november 2026 is beoordeeld: een VPC met twee subnets, een security group, een EC2-instance, een RDS PostgreSQL-database, een S3-bucket, een ElastiCache-groep, een SQS-wachtrij, een Lambda-functie en een DynamoDB-tabel. De klassen komen uit assessment.json; de database subnet group gaat op in de database.

Per klasse: 6 RECONFIGURE, 2 REPLATFORM, 1 DIRECT, 1 CONTAINERIZE, 1 REDESIGN, allemaal met zekerheidsniveau MEDIUM. Bij geen van de 11 eenheden zijn de kritieke instellingen al afgesloten: 5 komen daar zodra hun openstaande punten zijn beantwoord, en 6 vergen werk dat in deze build handmatig door een persoon wordt gedaan.

Fundament: subnets worden netwerken

Links: de VPC en de twee subnets. Rechts: de twee stackit_network-blokken van het concept, elk met de commentaarregel die de availability zone noemt die het niet overneemt; de overige commentaarregels van het bestand zijn weggelaten. STACKIT kent geen VPC-containerobject, dus het project waarin het concept wordt aangemaakt, vormt de grens van de VPC.

resource "aws_vpc" "main" {
  cidr_block = "10.30.0.0/16"
}

resource "aws_subnet" "private_a" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.30.1.0/24"
  availability_zone = "eu-central-1a"
}

resource "aws_subnet" "private_b" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.30.2.0/24"
  availability_zone = "eu-central-1b"
}

# NOT CARRIED (aws_subnet.private_a): availability_zone = eu-central-1a — stackit_network has no availability zone (pinned provider): the network serves the region; servers and volumes choose their zone.
resource "stackit_network" "private_a" {
  project_id       = var.project_id
  name             = "private-a"
  ipv4_prefix      = "10.30.1.0/24"
  ipv4_nameservers = var.default_ipv4_nameservers
}

# NOT CARRIED (aws_subnet.private_b): availability_zone = eu-central-1b — stackit_network has no availability zone (pinned provider): the network serves the region; servers and volumes choose their zone.
resource "stackit_network" "private_b" {
  project_id       = var.project_id
  name             = "private-b"
  ipv4_prefix      = "10.30.2.0/24"
  ipv4_nameservers = var.default_ipv4_nameservers
}

• Dezelfde prefixen, geen zone

  Subnets behouden hun IPv4-prefixen, waardoor adresplannen stabiel blijven. De availability zone vervalt: een STACKIT-netwerk bedient de regio en servers en volumes kiezen hun zone zelf.

• Publiek of privé is geen eigenschap van een subnet

  Op STACKIT krijgen servers expliciet publieke IP's. De run legt vast dat uitgaande internettoegang voor een netwerk niet kan worden uitgeschakeld, terwijl een privésubnet in AWS die toegang niet had, en laat dat als open beslissing staan.

Data: RDS wordt PostgreSQL Flex

Links: de RDS-instance. Rechts: de instance uit het concept met de twee NOT CARRIED-commentaarregels die er in het bestand aan voorafgaan; de overige commentaarregels zijn weggelaten. Flavor en opslag zijn afgeleid van de bron: 2.16 is 2 vCPU en 16 GiB, de kleinste single-node-flavor die db.m6g.large dekt, en de opslag is van 100 GiB naar boven afgerond op 108, omdat STACKIT gigabytes noemt zonder de eenheid te definiëren.

resource "aws_db_instance" "main" {
  identifier              = "app-db"
  engine                  = "postgres"
  engine_version          = "16.4"
  instance_class          = "db.m6g.large"
  allocated_storage       = 100
  db_subnet_group_name    = aws_db_subnet_group.main.name
  username                = "app"
  manage_master_user_password = true
  storage_encrypted       = true
  backup_retention_period = 7
}

# NOT CARRIED (aws_db_instance.main): db_subnet_group_name — stackit_postgresflex_instance has no subnet, availability-zone or IP-family attribute (pinned provider): clients reach the instance at the endpoint STACKIT assigns.
# NOT CARRIED (aws_db_instance.main): manage_master_user_password — the master secret in AWS Secrets Manager (managed master password) is not carried: STACKIT generates the credential (pinned provider) and has no rotation schedule; keep the new one in STACKIT Secrets Manager or the application's own store.
resource "stackit_postgresflex_instance" "main" {
  project_id = var.project_id
  name       = "app-db"
  version    = "16"
  flavor_id  = "2.16"
  storage = {
    class = var.postgresflex_storage_class
    size  = 108
  }
  backup_schedule = "0 2 * * *"
  network = {
    acl          = var.relational_database_allowed_cidrs
    access_scope = var.relational_database_access_scope == "SNA" ? "SNA" : null
  }
  retention_days = 32
}

• Inloggegevens veranderen

  STACKIT genereert de inloggegevens van de mastergebruiker en de applicatie ontvangt die nieuwe gegevens. Er is geen rotatieschema om over te nemen.

• Endpoint, geen subnet

  De instance heeft een eigen endpoint en een toegangslijst; de plaatsing van de bron in een subnet group wordt niet overgenomen. Blootstelling is een beslissing.

• Instance-beveiliging inschakelen

  De PostgreSQL Flex-documentatie van STACKIT waarschuwt dat bij API v3 de data onmiddellijk en definitief verloren gaat als u een instance verwijdert zonder actieve instance-beveiliging. Schakel de beveiliging in voordat de database productiedata bevat.

De volgorde die de run voorstelt

Golven worden berekend uit afhankelijkheden. Eenheden in dezelfde golf kunnen parallel worden verplaatst; de run noemt dit een uitgangspunt voor uw plan, geen planning.

Het uitvoeringspakket voegt 24 geautomatiseerde stappen toe (18 resourceblokken en 6 API-aanroepen) en 102 handmatige stappen in 33 werkpakketten. Van de 24 geautomatiseerde stappen zijn er 19 vrij van beslissingen en handmatige randvoorwaarden, maar ze wachten nog op waarden zoals project_id.

Beslissingen die uw architecten nemen

Het register van deze run bevat 26 records. Dit zijn de beslissingen met het grootste effect.

• DynamoDB

  STACKIT kent geen DynamoDB-compatibele service. Het concept biedt één MongoDB Flex-instance, de managed MongoDB-service van STACKIT, met elke tabel als collectie; relationele JSONB op PostgreSQL Flex is de andere optie. In beide gevallen wordt de toegangslaag herschreven en komen sleutelontwerp, capaciteitsmodi en voorwaardelijke schrijfacties niet mee.

• Lambda

  De run merkt op dat STACKIT geen algemeen beschikbare functieservice heeft. De handler draait in een permanent draaiend proces: een Cloud Foundry-app of een container. Het uitvoeringsmodel verandert van per aanroep naar permanent actief.

• Bootimage

  Een AMI wordt vervangen door een STACKIT-image naar keuze. Zolang dit niet is beantwoord, wachten de connectiviteitscontrole en de cutoverstappen.

• Egress en endpoints

  Het concept houdt uitgaand verkeer gesloten en stelt de databases bloot op een publiek endpoint dat door een toegangslijst wordt beperkt; beide zijn standaardwaarden die u bevestigt of vervangt. Vul de toegangslijsten zelf in: de RabbitMQ-documentatie van STACKIT vermeldt dat een nieuwe dataservice start met een standaardtoegangslijst die STACKIT-IP-bereiken bevat.

• Methode voor dataverplaatsing

  Dump en restore of logische replicatie voor PostgreSQL; synchronisatietools voor buckets. De juiste keuze hangt af van de omvang van de data en het venster voor de schrijfstop, die de Terraform-code niet vermeldt.

Vragen die architecten het eerst stellen

Bronnen

• STACKIT Object Storage-documentatie
• STACKIT RabbitMQ-documentatie
• STACKIT PostgreSQL Flex-documentatie
• STACKIT MongoDB Flex-documentatie
• StackToIT-documentatie: AWS naar STACKIT