← Back to portfolio

Lessons from Migrating Microservices Across Cloud Providers

AWSOCIKubernetesArgoCDMigration

When teams commit to moving microservices from one cloud provider to another, the hardest part is rarely the infrastructure. It is the people.

A cross-cloud migration involves rewiring deployment pipelines, updating monitoring dashboards, and rebuilding trust in a new platform. The Terraform and ArgoCD work is often straightforward. Convincing multiple teams to change their deployment runbooks and operational habits takes far longer than anyone budgets for.

What Typically Goes Wrong

Early migrations tend to go smoothly, which creates overconfidence. Then a later service turns out to have a hardcoded cloud-specific endpoint buried deep in a config file that nobody has touched in years. It passes every test in staging because staging still points to the old provider. Production breaks in the middle of the night.

The lesson: build a pre-migration scanner. A simple script that greps every repository for cloud-specific endpoints, SDK imports, and environment variables. This kind of scan routinely uncovers dozens of hidden dependencies that would otherwise cause production failures.

The Universal Runbook Pattern

A common mistake is writing per-service migration runbooks. Instead, a single universal checklist works better. It should cover DNS cutover, monitoring validation, rollback triggers, and the escalation chain. Consistency means any on-call engineer can handle a migration issue, not just the team that owns the service.

Key Takeaways

  1. Scan for hidden cloud-specific dependencies before you start
  2. Migrate the noisiest, least critical service first to find tooling gaps
  3. A universal runbook beats per-service documentation
  4. Budget the majority of migration timeline for team adoption, not infrastructure