AWS to STACKIT cutover and rollback runbook

How to use this runbook

The order comes from the run's execution plan, the owners and rollback lines from the manual steps it writes (execution/manual/actions.md). Rows marked practice are general good practice that the run does not write.

• Source of the order

  Dependencies set the waves; the cutover steps carry "after" links, so readiness follows the last data reconcile, the switches follow readiness and the rollback decision follows every check.

• Nothing runs by itself

  StackToIT creates, changes and deletes nothing. Each step is done by a person, by OpenTofu or by a script your team runs.

• No timings

  The plan states no maintenance window and invents none. Take durations from your rehearsal, not from a table.

The build order: three waves

From migration/technical-sequencing.md of the demo run: nine units in three waves. Units of one wave can move in parallel; the file calls it a starting point for your wave plan, not a schedule.

## Wave 1 — 4 unit(s)

| Unit | Class | Target |
|---|---|---|
| `aws_route53_zone.main` | DIRECT / MEDIUM | STACKIT DNS |
| `aws_s3_bucket.uploads` | RECONFIGURE / MEDIUM | STACKIT Object Storage |
| `aws_secretsmanager_secret.api_key` | RECONFIGURE / MEDIUM | STACKIT Secrets Manager |
| `aws_vpc.app` | RECONFIGURE / MEDIUM | STACKIT project networking / Network Area (SNA) |

## Wave 2 — 3 unit(s)

| Unit | Class | Target |
|---|---|---|
| `aws_security_group.db` | RECONFIGURE / MEDIUM | STACKIT security group |
| `aws_subnet.app_a` | RECONFIGURE / MEDIUM | STACKIT network |
| `aws_subnet.app_b` | RECONFIGURE / MEDIUM | STACKIT network |

## Wave 3 — 2 unit(s)

| Unit | Class | Target |
|---|---|---|
| `aws_db_instance.orders` | REPLATFORM / MEDIUM | STACKIT PostgreSQL Flex |
| `aws_instance.app` | RECONFIGURE / MEDIUM | STACKIT Compute Engine |

Phase 1 · Before the window

Phase 2 · Freeze and final copy

Phase 3 · The switch

The two steps that carry the rollback

Verbatim line ranges from execution/manual/actions.md of the demo run: the risk and the rollback of the delegation change, then the head and the rollback of the rollback decision step. The long dependency and state lines between them are left out.

- Risk: while resolvers hold the old delegation (one parent NS TTL) some answer from Route 53 and some from STACKIT: a record changed in one zone and not in the other is seen by part of the clients only, so both zones hold the same records until the TTL has passed
- Rollback (manual): set the NS records at the registrar (or the parent zone) back to the Route 53 name servers; resolvers that hold the STACKIT delegation keep it for one parent NS TTL, so the STACKIT zone stays in service for at least that long after the rollback, and the Route 53 zone is retired only after the GO recorded at the rollback decision step

#### The rollback decision step (`MAN/verify/rollback-decision`)

- Phase: Verification
- What: Decide GO or ROLLBACK for the migration once every check of the verification is done: GO lets the source resources be retired, ROLLBACK reverts the cutover and keeps AWS serving
- Why: reverting the cutover is a change of addresses only while the AWS resources exist; after the first decommission step the way back is a rebuild from backups
- Who: Migration Owner
- When: after every check of the verification

- Risk: the decision point follows every check of the verification (each is also an action-complete precondition); the retirement steps depend on it, and through it on the checks
- Rollback (manual): on ROLLBACK, revert each cutover step as its rollback says (the traffic switch of aws_instance.app, the delegation change of the hosted zone of aws_route53_zone.main, the switch of the applications that use aws_s3_bucket.uploads, the switch of the applications that use aws_db_instance.orders) and start no decommission step; on GO nothing is reverted

Phase 4 and 5 · Verify, decide, retire

The DNS draft behind the delegation step

The STACKIT DNS zone and record set the demo run wrote (terraform/dns.tf, without comments). The record keeps the 300 s TTL of the source.

resource "stackit_dns_zone" "main" {
  project_id = var.project_id
  name       = "orders.example.com"
  dns_name   = "orders.example.com"
}

resource "stackit_dns_record_set" "app" {
  project_id = var.project_id
  zone_id    = stackit_dns_zone.main.zone_id
  name       = "www.orders.example.com"
  type       = "A"
  records    = ["203.0.113.10"]
  ttl        = 300
}

Rules for the rollback

Where the way back ends, and what you give up on the way.

• Keep the source whole until the GO

  The plan never makes the source read-only or changes it after the freeze, so a rollback is only configuration put back. Delete nothing in AWS before the rollback decision is GO.

• Writes after the switch

  Whatever the applications wrote to STACKIT after the switch is not in AWS. Copy it back with a separately rehearsed method or accept it as lost, and decide before the window.

• DNS needs patience

  Resolvers keep the old delegation for one parent NS TTL after a change, so both zones must hold the same records for that long. The TTL of the delegation at the registrar is not in the source.

• DNSSEC (practice)

  AWS documents for the opposite direction that a domain cannot be signed by two providers at once and the DS record must be removed first. If your zone is signed, plan the DS record in both directions.

• The point of no return

  After the first retirement step the way back is a rebuild from backups. That is why the decision step is separate and carries a date and the result of every check.

Questions teams ask

Sources

• Making Route 53 the DNS service for a domain that is in use (AWS documentation, the reverse direction)
• STACKIT PostgreSQL Flex (STACKIT documentation)
• STACKIT Object Storage (STACKIT documentation)
• Backup and clone of PostgreSQL Flex (STACKIT documentation)
• STACKIT DNS: manage DNS zones (zone delegation)