I led our company's move from AWS to Azure. The goal was easy to state and hard to do: move everything with as little disruption to the service as possible. This post covers the approach. Both clouds are capable, and the reasons to move between them are usually business reasons.

Inventory before architecture

Before drawing the target architecture, list what actually exists: every service, database, DNS record, certificate, scheduled job, and secret, with its owner and whatever depends on it. The pieces that cause trouble during a migration are usually the ones nobody remembered.

Map services, not names

Most AWS services have a close Azure equivalent, but close isn't identical. IAM and Azure RBAC model identity differently, and networking defaults, load balancer behavior, and managed service settings all differ in small ways. Each mapping is a design decision that needs checking.

Portability pays off

The move is easiest wherever you've already invested in portability. Workloads packaged as containers and scheduled on Kubernetes travel with much less friction than anything tied to provider-specific services. Server setup written in Ansible can be replayed against new machines.

Move in slices

Move one service, or one group of closely related services, at a time, with both environments running in parallel. Lowering DNS TTLs ahead of time, syncing data before the cutover, and keeping a tested rollback path means any step can be undone if it goes wrong.

Before each cutover, write down how you'll know it worked and how you'll roll it back. If either answer is vague, it isn't ready.

State is the hard part

Stateless services can run in two places at once. Databases like MySQL and Redis can't, at least not easily. The usual plan is replication to the new environment, a short, announced write window, and verification before switching traffic. Most of the risk sits in that window, so it deserves most of the rehearsal.

After the cutover

Migrations tend to over-provision, because nobody wants to be the reason performance dropped. Once traffic settles, review what's actually running and right-size it based on real usage. That's where much of the cost control in a new cloud comes from.