How to Migrate Your Dev Stack to Europe in 2026: The Complete Checklist

Post #1091 in the sota.io EU Developer Sovereignty Series

Hacker News thread "I moved my digital stack to Europe" generated hundreds of comments in 2026. The consensus: it's doable, but nobody had written a comprehensive developer checklist. After researching 40+ EU-native services across every stack layer, here is that checklist.

This guide covers 10 infrastructure layers, with CLOUD Act risk scores (0–25, lower is better) and GDPR Art.46 transfer mechanism status for each. If your current stack scores above 15 on any layer, you have a data transfer compliance gap.

Why Migrate in 2026?

Three converging forces make EU stack migration urgent for European developers:

1. CLOUD Act enforcement expanded. The US Clarifying Lawful Overseas Use of Data Act (18 U.S.C. § 2713) allows US authorities to compel disclosure of data held by US-controlled companies anywhere in the world — including EU-region servers. After the Schrems II ruling invalidated Privacy Shield, DPA enforcement intensified. The Austrian DSB (2022), French CNIL (2022), Italian Garante (2022), Swedish IMY (2022), and Danish Datatilsynet (2022) all ruled US-hosted analytics tools illegal under GDPR.

2. EU Cloud Sovereignty legislation accelerated. The European Cloud Act entered force in 2025. EUCS (EU Cybersecurity Certification Scheme for Cloud Services) is finalising Level High requirements that explicitly require jurisdictional independence from non-EU law. CADA (Cyber Act) implementation deadlines hit in mid-2026.

3. Enterprise procurement requires it. DORA (Digital Operational Resilience Act, effective January 2025) requires financial entities to ensure their ICT vendors are not subject to concentration risk from non-EU jurisdictions. NIS2 (effective October 2024) applies similar logic to critical infrastructure operators. B2B SaaS sales into regulated EU sectors now require evidence of EU data processing.

CLOUD Act Risk Score Framework

Throughout this checklist, each service is scored on a 25-point scale:

Score 0–4: EU-native, no CLOUD Act exposure. ✅
Score 5–12: Manageable with DPAs and SCCs, document carefully. ⚠️
Score 13–20: High risk, DPA enforcement likely. ❌
Score 21–25: Critical exposure, GDPR Art.46 gap. 🔴

Layer 1: DNS and Domain Registrar

What's exposed: Every DNS query for your domain. Registrar account data. WHOIS records.

US-controlled services to replace

EU-native replacements

Migration effort: 30 minutes per domain (TTL reduction → NS change → propagation).

Checklist:

• Export zone files from current registrar
• Create zone in Hetzner DNS or INWX
• Lower TTL to 300s (5 min) 24h before cutover
• Verify all records (A, AAAA, MX, TXT, CNAME, CAA) are correct
• Update nameservers at registrar
• Monitor DNS propagation (72h full propagation)

Layer 2: CDN and DDoS Protection

What's exposed: All HTTP request headers (including IP, User-Agent, cookies). Cached content. TLS termination (private keys at CDN edge).

US-controlled services to replace

EU-native replacements

Migration effort: 2–4 hours (DNS CNAME swap + cache warming).

Checklist:

• Sign up BunnyCDN or KeyCDN (free trials available)
• Configure pull zone pointing to your origin
• Set CNAME dns.bunnycdn.com (or equivalent)
• Enable HTTPS with Let's Encrypt auto-renewal
• Configure cache rules (match existing Cloudflare Page Rules)
• Test with curl -I https://yourdomain.com — check CDN headers

Layer 3: PaaS and Application Hosting

What's exposed: Your application code. Environment variables (secrets, API keys, database URLs). Build logs. All runtime data.

This is the most critical layer. Your PaaS provider has root access to everything your application does. A CLOUD Act request here means full application data exposure.

US-controlled PaaS to replace

EU-native PaaS replacements

Why sota.io: sota.io is the only EU-native managed PaaS with one-sentence deploy semantics (git push, Docker, or CLI) and explicit CLOUD Act independence documentation. No US parent company, no US-law compelled disclosure risk. Hetzner Germany infrastructure gives EUCS-compatible data residency.

Migration effort: 1–3 hours for a typical Next.js/Rails/Django/Go app.

Checklist:

• sota deploy or push Dockerfile (sota.io supports any language)
• Migrate environment variables to sota.io secrets
• Configure custom domain (sota domains add yourdomain.com)
• Update DNS CNAME to sota.io edge
• Run smoke tests on staging environment
• Cut over production DNS (low TTL first)

Layer 4: Authentication and Identity

What's exposed: User passwords (hashed). Session tokens. OAuth tokens for connected services. MFA seeds. User PII.

US-controlled auth to replace

EU-native auth replacements

Keycloak on sota.io: Deploy Keycloak container on sota.io in under 10 minutes. Keycloak supports OIDC, SAML 2.0, OAuth 2.0, LDAP federation, and social login — replacing Auth0/Firebase Auth feature-for-feature. GDPR Art.25 privacy by design built in (minimal data collection, right to erasure built into user management).

Migration effort: 4–8 hours (Keycloak setup + OAuth redirect URI updates in all apps).

Checklist:

• Deploy Keycloak via sota.io Docker (keycloak/keycloak:latest)
• Configure realm, clients, and user federation
• Update OAuth callback URLs in your applications
• Migrate existing user accounts (export from Auth0 via Management API)
• Test all OAuth flows (login, refresh, logout, token introspection)
• Update email templates (Keycloak has full custom template support)

Layer 5: Database and Data Storage

What's exposed: All application data. User PII. Business logic tables. Query logs.

US-controlled databases to replace

EU-native database services

Migration effort: 4–16 hours (schema export, data migration, application connection string update + testing).

Checklist:

• Export current database (pg_dump, mysqldump, or DB-specific tool)
• Provision EU-native PostgreSQL instance
• Import schema and data
• Update DATABASE_URL in application environment
• Run integration tests against new DB
• Enable automated backups (daily full + WAL streaming)
• Set up monitoring/alerting for connection pool exhaustion

Layer 6: Object Storage and File Storage

What's exposed: User-uploaded files. Application assets. Backups. Log archives.

US-controlled storage to replace

EU-native storage

S3-compatible API: All EU alternatives listed above support the S3 API. Your existing AWS SDK code works with zero changes — just swap the endpoint URL and credentials.

Migration effort: 1–3 hours (bucket creation + aws s3 sync or rclone copy to move data).

Checklist:

• Create bucket in Hetzner Object Storage or Scaleway
• Run rclone copy s3:your-bucket hetzner:your-bucket for data migration
• Update AWS_ENDPOINT_URL, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY
• Test presigned URL generation and file upload/download
• Update application code if bucket policy logic differs
• Verify CORS settings for frontend direct uploads

Layer 7: Email and Transactional Email

What's exposed: Customer email addresses. Transactional content (order confirmations, password resets). Open/click tracking pixels.

US-controlled email to replace

EU-native transactional email

Brevo for developers: Brevo has a developer-friendly REST API compatible with the Mailgun/SendGrid patterns. Starter tier is free up to 300 emails/day. GDPR-compliant opt-in/opt-out management is built in.

Migration effort: 2–4 hours (API credential swap + email template migration).

Layer 8: Monitoring and Observability

What's exposed: Application error messages (may contain PII). Performance traces. Log streams. Infrastructure metrics. User session data (in APM tools).

US-controlled monitoring to replace

EU-native monitoring

AppSignal for developers: AppSignal is a Dutch company offering APM, error tracking, and uptime monitoring with zero US data exposure. It integrates with Rails, Node.js, Python, Elixir, Go, and PHP. GDPR DPA auto-generated on signup. No sub-processors outside EU.

Layer 9: Analytics

What's exposed: User behavior data. Page views. Session recordings. Conversion funnels. IP addresses. Device fingerprints.

Analytics tools receive the most GDPR enforcement because they sit closest to end-user PII.

US-controlled analytics ruled illegal by EU DPAs

EU-native analytics

Plausible for product teams: Plausible requires no cookie banner (no cookies!), is cookieless by design, and provides product analytics (events, goals, funnels) sufficient for most SaaS teams. The self-hosted option has zero third-party data exposure.

Layer 10: CI/CD and Version Control

What's exposed: Source code. Build secrets. Deployment keys. All environment variables used in CI.

US-controlled CI/CD to replace

EU-native CI/CD

GitHub Actions with EU runners: If migrating your entire VCS is too large an investment right now, you can reduce CLOUD Act exposure by using self-hosted GitHub Actions runners on EU infrastructure. Your code stays on GitHub (US risk), but compute and secrets handling move to EU. This is a partial mitigation only.

Full Stack Migration Timeline

A realistic EU migration for a 3-developer SaaS team:

Common Migration Pitfalls

1. Assuming EU-region = EU-jurisdiction. AWS eu-central-1 (Frankfurt) is hosted in Germany, but the operator is Amazon.com Inc. (Seattle WA). US CLOUD Act applies to the company, not the datacenter.

2. Forgetting sub-processors. Your EU PaaS may be clean, but if it sends error reports to Sentry (US) or metrics to Datadog (US), the sub-processor is a GDPR Art.28 breach.

3. DNS as an afterthought. Cloudflare DNS sees all your traffic metadata even if you've moved to EU hosting. Fix DNS first.

4. Breaking change during migration window. For databases, run the new EU instance in read-replica mode for 48h before cutting over. Validate all query patterns before switching the primary.

5. Missing the GDPR Art.28 DPA documentation. Every service you use must have a signed Data Processing Agreement. EU-native providers generate these automatically (Hetzner, Scaleway, Brevo). US providers offer SCCs — which are legally weaker and potentially invalidatable by future Schrems III.

Your Post-Migration GDPR Compliance Checklist

After completing the stack migration:

• All sub-processors in your privacy policy are EU-incorporated or have valid SCCs
• Record of Processing Activities (ROPA) updated with new processor list
• Data Processing Agreements signed with every new EU provider
• No personal data flowing through US-incorporated sub-processors without Art.46 mechanism
• Cookie banner updated to reflect Plausible/Matomo (may no longer be required!)
• Data Subject Rights requests can be fulfilled from EU-controlled data only
• 72-hour breach notification contacts updated to EU DPA in your country

Start with the PaaS Layer

The application hosting layer has the highest CLOUD Act exposure and the highest migration payoff. Every other layer's data flows through your PaaS (auth tokens, DB connection strings, API keys, logs).

sota.io is the EU-native managed PaaS that removes US jurisdiction from your application runtime. Deploy your existing Dockerfile, git repository, or use sota deploy for zero-configuration deploys. Hetzner Germany infrastructure, no US parent company, automatic GDPR Art.28 DPA, and full CLOUD Act independence documentation.

→ Deploy your first service on sota.io — free tier available, no credit card required.

Sources: GDPR Art.46 transfer mechanisms, CJEU Data & Dossier Schrems II (C-311/18), CLOUD Act 18 U.S.C. § 2713, Austrian DSB complaint (2021-0.586.257), French CNIL decision SAN-2022-001, Italian Garante Provv. 224/2022, Swedish IMY DI-2020-11397, Danish Datatilsynet (2022-431-0159), EUCS Level High criteria consultation paper (2025), CADA Regulation (EU) 2023/2854.