Big tech cloud exit checklist¶

Phase 1: Reality check¶

☐ Audit current cloud usage

• Inventory services, dependencies, regions, and lurking Lambda functions.

• Identify critical workloads vs vanity projects.

☐ Estimate total cloud cost

• Include hidden gremlins: egress fees, storage tiers, and zombie VMs.

  • AWS: The bill that never ends

  • Azure: Nice dashboard, shame about the costs

  • GCP: Free-tier until it is not

  • On-Prem @ Hetzner cloud costs “DIY, but actually sane”

• Compare with realistic on-prem or hybrid costs (include staff, power, hardware).

☐ Check for vendor lock-in

• Look for managed services with no easy exit (e.g., proprietary databases, serverless traps).

  • AWS lock-in assessment

  • Microsoft Azure lock-in assessment

  • Google Cloud (GCP) lock-in assessment

  • On-prem/Alternative clouds (Hetzner, OVH, etc.) lock-in assessment

• Document migration blockers (formats, APIs, service contracts).

☐ Assess compliance risk

• Is the setup GDPR-compliant or just spiritually so?

• Know where data physically lives and under which jurisdiction.

  • AWS data protection: GDPR roadmap notes

  • Azure data protection: Notes on meeting GDPR Requirements

  • Notes on navigating GDPR requirements on Google Cloud

  • GDPR compliance Hetzner (On-Prem/Alternative Cloud)

Phase 2: Plan your escape¶

☐ Choose the deployment model

• Cloud-on-prem: full local hosting with cloud-like tools.

• Hybrid: local core + hyperscale for bursts or AI training.

• Multicloud: diversify, but be ready to juggle.

☐ Select the toolkit

• Orchestration: Kubernetes, Nomad, or a stiff gin.

• IaaS replacement: OpenStack, Proxmox, Harvester.

• CI/CD + secrets: GitLab, ArgoCD, HashiCorp Vault.

☐ Pick a European provider (if applicable)

• Hetzner for power-efficient, no-nonsense infra.

• UpCloud for low-latency EU edge.

• Greenhost or 1984.is for civil-liberties-friendly compute.

☐ Pilot and test

• Start with dev/test environments.

• Benchmark latency, throughput, and team morale.

Phase 3: Migrate like a professional¶

☐ Move core workloads

• Prioritise data sovereignty: HR, healthcare, legal, anything that screams “breach me”.

• Document every step. The future will be grateful.

☐ Refactor or replace cloud-native services

• Replace proprietary functions (e.g., AWS Lambda) with open equivalents.

• Use containers, not Stockholm Syndrome.

☐ Set up proper monitoring and alerting

• Grafana > guessing.

• Avoid outages caused by a silent disk filling up since last Christmas.

☐ Implement backup & disaster recovery

• Test restores, not just backups.

• Store backups somewhere Uncle Sam doesn’t have keys.

Phase 4: Post-migration hygiene¶

☐ Decommission responsibly

• Delete unused cloud resources (verify rather than assume).

• Watch final invoices like a hawk with trust issues.

☐ Update policies and documentation

• New infrastructure = new responsibilities.

• Train staff. Expect some eye-rolls.

☐ Monitor for regression

• Avoid sliding back into “just this one AWS S3 bucket…”

• Build cloud repatriation into the tech strategy.

☐ Celebrate with the team

• Cake, if budget allows.

• Stickers for the sysadmins.

• Inner peace from no longer funding data surveillance.

Phase 5: Notify the compliance officer¶

• They will sleep better knowing the backups do not reside under the CLOUD Act.

• And it may be worth avoiding explaining the infrastructure to a Data Protection Authority with a grudge.