CHECKLIST · EUROPEAN CLOUD AND SOVEREIGNTY
European cloud migration and digital sovereignty checklist
Tick these checks in order, from discovery to decommission, and attach each answer to a file. A StackToIT run writes a sovereignty file that records 13 dimensions of an estate: in the 13-resource AWS estate behind this page, one dimension needs evidence, two are observed and ten are not assessed by the engine at all. The not-assessed ones are not a verdict, they are your checks. Sovereignty is a position you document, and this list shows where each part of it is written down.
The 13 dimensions of the sovereignty file, and what closes each
From assurance/sovereignty.md of a run on 4 November 2026 with two applications that state a sovereignty tier. The states are the run's own words.
| Dimension | State in the run | What closes it |
|---|---|---|
| Data location | Evidence required | Set the STACKIT region on purpose; the run assumed eu01 for pricing because no input chose one. Record where backups and replicas go. |
| Jurisdiction chain | Not assessed | A question about the legal seat and reach over provider, owners and operators. The file leaves it external; record who answered it. |
| Operator access | Not assessed | Record which staff of the provider or of subcontractors can reach resources and data, on which conditions. |
| Key control | Not assessed | Record who holds the keys of the data. The run observed no customer-managed key in the source; that reflects what the engine reads, not proof that none is used. |
| Identity chain | Not assessed here; decision required when the source names workload identities | Decide how each workload gets its STACKIT identity (see the identity guide). |
| Telemetry chain | Not assessed | Record where logs, metrics and traces go and who runs the destination. |
| Backup chain | Not assessed | Confirm the schedule and retention the draft writes, and where the backups sit. |
| Supply chain | Observed | The source providers and the draft's STACKIT provider version are listed; registries, build chain and module provenance are for you. |
| Third-party processing | Not assessed | List every SaaS and managed service that touches the data and is not in the Terraform. |
| Open interfaces | Not assessed | Record which interfaces you rely on are open standards and whether the STACKIT target keeps them. |
| Data portability | Not assessed | Record the export format and path for each stateful unit. |
| Application coupling | Not assessed | Scan the application code for SDKs and protocols of the source; the engine reads infrastructure, not code. |
| Exitability | Observed | The only fact stated is that the draft is provider-specific Terraform. Write the exit path per dependency yourself. |
The file says it records technical evidence and gaps, does not certify legal compliance and states no score. Sovereignty is not residency: the region of a service is a fact about the service, not about the workload.
Where the requirement comes from
Left: the billing application as the applications file states it. Right: the requirement section of the sovereignty file.
business_criticality: critical
availability:
rto: 30m
rpo: 5m
downtime_tolerance: 15m
data:
classification: confidential
sovereignty:
tier: mandatory## Requirement
Sovereignty requirement: CUSTOMER INPUT.
The applications file states a sovereignty tier or constraints for the applications listed. They are quoted as written; no dimension below is judged against them in this build.
| Application | Sovereignty tier | Constraints |
|---|---|---|
| billing | mandatory | NOT_PROVIDED |
| shop | preferred | NOT_PROVIDED |Quoted as written
The file shows each application's tier as you wrote it and states that no dimension is judged against it in this build. The tier is a record, not a test result.
Each dimension still reads not provided
The per-dimension entries below the requirement section show the requirement as not provided, although the table lists the tiers. Read the table, not the per-dimension line.
The class travels with the data
The data movement file repeats the classification, RPO and downtime tolerance beside each stateful unit: billing's database as confidential with 5m and 15m.
Discovery
General practice, tied to the files a run writes. Establish the requirement and where the tool runs.
Write the applications file with a tier and a classification per application
Use the tier values the file accepts and the owners and RTO and RPO of each application. The sovereignty file and the data movement file repeat them. Check: applications.yaml, assurance/sovereignty.md.
Run the assessment on a machine you control, offline if required
The docs state that assess reads the source locally, uploads nothing and with offline mode makes no outbound requests. Check: the console output and operations notes, a record of the machine and the flags used.
Name the regions you may use
STACKIT documents two regions, eu01 in Germany and eu02 in Austria, each with at least three availability zones, and states its infrastructure is operated in its own data centres in Germany and Austria. Check: STACKIT regions page, your policy.
List the services with no STACKIT counterpart
Units classed REDESIGN, CONTAINERIZE or MANUAL_REVIEW are where a dependency may stay outside the target or be rebuilt. Check: engineering/architect-report.md.
Design
Turn the dimensions into decisions.
Set the region in the variables
The draft has a region variable and the run assumed eu01 for pricing when none was chosen. Check: terraform/variables.tf, the sovereignty file.
Decide name resolution
The draft defaults the networks to the addresses of the STACKIT DNS Resolver rather than the public resolvers 1.1.1.1, 8.8.8.8 and 9.9.9.9. Check its status in the STACKIT documentation, then keep or change it. Check: the sovereignty file, data location.
Decide the identity of every workload
Map machine identities to service accounts and choose roles yourself; STACKIT documents that service accounts have no access by default. Check: assurance/identity-transition.md.
Collect provider evidence per service
The run lists 10 frameworks for the 7 STACKIT services of its draft, 70 rows: 2 show provider evidence present, 3 need your own controls and 65 need an external review of the provider's document. Check: assurance/compliance-evidence.md; each row is valid for 90 days after it was verified.
Build
Make the draft yours before anything is applied.
Pin and lock the providers
The run flags source providers with no lock file entry and writes the draft for one STACKIT provider version. Commit lock files. Check: terraform/terraform.tf, the provider note in the report.
Protect the state
The draft declares no backend, and the provider writes secrets such as database passwords into the state in plain text. Use an encrypted backend with limited read access. Check: terraform/README.md, security checklist.
Confirm backup defaults
The draft writes a 02:00 daily backup schedule and a 32-day retention for PostgreSQL Flex because the source values were not visible; 32 days is the STACKIT minimum. Check: terraform/data.tf.
Authenticate the provider without a long-lived key
The README recommends workload identity federation over a service account key. Check: terraform/README.md.
Data
Move data with a method you chose, and keep the way out open.
Choose a method per stateful unit
The plan defines the methods and chooses none; the mechanism reads unknown until you answer. Check: migration/data-movement.md.
Record classification and RPO beside each unit
They come from the applications file and travel into the movement plan. Check: migration/data-movement.md.
Plan the clean-up of copies
Dump files, key lists and the move host's access are listed as clean-up steps for after acceptance. Check: the plan's clean-up steps in execution-plan.json.
Prefer open protocols for the way out
Object storage that speaks the S3 API can be copied out with the tools that copied it in. Check: the class of each bucket in assessment.json.
Cutover
Switch, decide and keep the source until the decision.
Choose a resilience intent per unit
The run records RTO and RPO as given and leaves the intent unknown for each unit, because it does not call an architecture resilient against an unknown requirement. Check: assurance/resilience.md.
Rehearse the switch and the rollback
One GO or ROLLBACK decision gates the retirement of the source. Check: the rollback decision in the plan.
Confirm the cutover per entry point
Each switch lists the clients and addresses it changes. Check: the cutover steps in the migration plan file under migration/.
After
Keep the evidence current.
Keep the run as evidence and verify it
Keep the run folder with the migration records and check it with the verify command, which tests it against its manifest and checks that the artefacts agree. Re-run the assessment whenever the source changed before the cutover. Check: manifest.json.
Retire source identities, keys and copies
Retirement waits behind the decision to proceed. Check: the retirement steps of the plan.
Re-read the provider's evidence
The compliance file treats a row as valid for 90 days after it was verified. Check its date and the provider's facts page again before an audit.
Questions compliance teams ask
Does StackToIT certify that a migration is sovereign?
No. The sovereignty file says it records technical evidence and gaps, states no score and leaves legal conclusions external. The tier you give is quoted as written.
Why are so many dimensions not assessed?
Because the input is infrastructure code. Jurisdiction, operator access, key ownership, telemetry, backups and application coupling are not facts of a Terraform file, so the run says not assessed rather than guessing.
Where does STACKIT state its locations?
STACKIT's facts page lists 7 data centres in Germany and Austria and says the infrastructure is operated exclusively in its own European data centres there. The regions documentation names eu01 as Germany and eu02 as Austria.
Does the provider evidence cover my workload?
The compliance file says provider evidence describes the provider's own controls and does not make a workload compliant with any framework. Your controls and an external review decide that.
Sources
Your next move: STACKIT.
Tell us about your estate. We show you what StackToIT delivers for it: target architecture, Terraform artifacts and a structured migration plan.