Cloud migration to STACKIT: the complete enterprise guide

The seven phases

The STACKIT Migration Framework describes four phases: assess, design and mobilize, migrate and run. The seven below split the same road into units a team can staff, and tie each to what a StackToIT run writes.

1. 01

   1 · Read the estate

   A standard assessment reads Terraform or OpenTofu, or a VMware RVTools export, on your own machine. Output: assessment.json with every unit, plus counts of resources, modules and conditional units. See the discovery guide for how to read it.

2. 02

   2 · Classify every resource

   Each unit gets a class, a confidence, a STACKIT target and a stated reason. The class tells you how much work it is; the reason tells you why. See the classes below.

3. 03

   3 · Decide what code cannot

   Sizes, endpoints, identity, data class and recovery point are not in the source. They become records in decisions.json and templates in review/ that you fill and feed to the next run.

4. 04

   4 · Build the landing zone

   Organization, project, roles and network come before any workload. The run writes migration/landing-zone-requirements.md from the draft, so the platform team knows what to provide before the first apply.

5. 05

   5 · Build the target and move data

   Apply the drafted STACKIT Terraform in a test project, then move data by a method you choose. The engine never moves data; it lists every stateful unit and holds the choice open.

6. 06

   6 · Cut over in waves

   Units are ordered by dependency into waves. The cutover steps, verification and rollback conditions sit in execution-plan.json and execution/.

7. 07

   7 · Retire and operate

   Retire the source only after the checks, then run the target. The plan carries retirement as steps of its own, so it is not forgotten.

What the source platforms have in common

Curated mappings per source cloud; the class is the typical one, and your run decides per unit from configuration. Identity and firewalls are decided case by case.

What the classes mean for effort

The classifications come from the public documentation. The figures are from the published AWS Retail Store run: 44 units.

• RECONFIGURE · 34 units

  A corresponding capability exists and needs configuration changes: networks, security groups, secrets, logs, load balancers. Mostly Terraform plus review.

• REPLATFORM · 9 units

  The workload moves to a different platform model: the ECS services to SKE, the RDS clusters to PostgreSQL Flex and STACKIT MariaDB, OpenSearch to STACKIT OpenSearch.

• REDESIGN · 1 unit

  Architectural change: in the Retail run, the DynamoDB table, for which the draft is an alternative on MongoDB Flex, not an equivalent.

• CONTAINERIZE and MANUAL_REVIEW

  Containerize moves a function or app into containers. Manual review marks a question an architect must resolve before the plan can proceed.

• DIRECT and BLOCKED

  Direct means a direct mapping. Blocked means the evaluated path cannot be completed as proposed; the Retail run had none.

Waves and the landing zone

From the published AWS Retail Store run. Left: wave 1 of migration/technical-sequencing.md, the units that depend on nothing else. Right: the organization and project requirements the run lists before the first apply.

## Wave 1 — 9 unit(s)

| Unit | Module | Class | Target |
|---|---|---|---|
| `module.dependencies.module.dynamodb_carts.aws_dynamodb_table.this` | `module.dependencies.module.dynamodb_carts` | REDESIGN / MEDIUM | STACKIT MongoDB Flex (alternative — data-model redesign; PostgreSQL Flex JSONB is the other option) |
| `module.retail_app_ecs.aws_cloudwatch_log_group.ecs_tasks` | `module.retail_app_ecs` | RECONFIGURE / MEDIUM | STACKIT Logs |
| `module.retail_app_ecs.aws_ecs_cluster.cluster` | `module.retail_app_ecs` | REPLATFORM / MEDIUM | STACKIT Kubernetes Engine (SKE) |
| `module.retail_app_ecs.aws_kms_key.cmk` | `module.retail_app_ecs` | RECONFIGURE / MEDIUM | STACKIT KMS |
| `module.retail_app_ecs.module.carts_service.aws_iam_role.task_execution_role` | `module.retail_app_ecs.module.carts_service` | RECONFIGURE / MEDIUM | STACKIT service account for the workload |
| `module.retail_app_ecs.module.checkout_service.aws_iam_role.task_execution_role` | `module.retail_app_ecs.module.checkout_service` | RECONFIGURE / MEDIUM | STACKIT service account for the workload |
| `module.retail_app_ecs.module.ui_service.aws_iam_role.task_execution_role` | `module.retail_app_ecs.module.ui_service` | RECONFIGURE / MEDIUM | STACKIT service account for the workload |
| `module.vpc.module.vpc.aws_eip.nat` | `module.vpc.module.vpc` | RECONFIGURE / MEDIUM | implicit (belongs to the NAT gateway) |
| `module.vpc.module.vpc.aws_vpc.this` | `module.vpc.module.vpc` | RECONFIGURE / MEDIUM | STACKIT project networking / Network Area (SNA) |

## 1. Organization

- A STACKIT organization that the people who carry out the migration belong to, with a project in it that holds everything the draft creates. The plans state no organization name or id; none is assumed.
- The draft takes the project from the variable `project_id`: STACKIT project ID the migrated resources are created in. It has no default: a person supplies it.

## 2. Project

- The project exists

• Waves come from dependencies

  A unit moves after every unit it depends on, and units in one wave can move in parallel. The Retail run has nine waves; the file calls them a starting point for the architect, not a schedule.

• The landing zone is read from the draft

  Requirements are derived from the drafted blocks and the plans. A line marked unknown is a value the run does not know, not a gap in the document.

• Variables without values are the hand-off

  The draft has 60 variables, and 48 automated steps wait for a value such as project_id. Supplying them is the first real task of the platform team.

What a run writes

index.html

The assessment workspace, opened in a browser

assessment.json

Every unit: class, confidence, target, reason, review

decisions.json

Open decisions with options, owner role and phase

terraform/

The STACKIT Terraform draft with review comments

migration/

Waves, landing zone requirements, data movement, the migration plan

execution-plan.json, execution/

Ordered steps for Terraform, APIs and manual work, with checks

review/

Templates for inputs and decisions you fill in

manifest.json

The files of the run and their checksums for stacktoit verify

What stays with your team

• Data movement

  StackToIT never moves data. Choose the method from size, change rate and tolerated downtime.

• Approval

  The package is a proposal. Architect approval is recorded by you, and the engine never asserts that a draft is safe to apply.

• Application behaviour

  Dependencies between applications, cutover timing and test criteria come from the owners of the workloads.

• Parts that need a redesign

  NoSQL, warehouses and some platform services have no equivalent. The run says which and drafts the closest alternative where one exists.

Questions enterprise teams ask

Sources

• STACKIT Cloud Framework: Migration Framework
• STACKIT Kubernetes Engine (SKE)
• StackToIT docs: Migration workflow
• StackToIT docs: Assessment classifications
• The published AWS Retail Store example