Planning a Cloud Migration Between Providers

Migrations rarely fail on the obvious parts. Moving an application and a
database is well-understood work. What causes trouble is the cron job nobody
documented, the hardcoded IP address in a partner’s firewall, and the discovery
that the DNS record has a twenty four hour time to live.

Start with an inventory

Before planning anything, write down everything that exists. Be
exhaustive:

• Every server, its role, and what is installed on it
• Databases, with sizes and versions
• Object storage buckets and total volume
• Scheduled jobs, including anything in a user’s crontab
• DNS records, including ones pointing at things you forgot
• TLS certificates and how they renew
• Outbound integrations and any address allowlists they rely on
• Inbound webhooks from third parties
• Credentials, API keys and where each is stored
• Monitoring, alerting and backup jobs

This list is the migration plan. Everything on it needs a decision, and the
items that get forgotten are the ones that were never written down.

Find the things that are not portable

Go through the inventory and mark anything tied to the current provider:
proprietary managed services, provider-specific identity mechanisms, instance
metadata APIs, and anything depending on a fixed IP address.

Each needs a plan: an equivalent service on the destination, a self-hosted
replacement, or a change to the application. This is the step that determines
whether the migration is a week or a quarter, and doing it early prevents an
unpleasant discovery halfway through.

Plan the data move specifically

Data is the part with physical constraints. Work out the volume, then work
out how long transferring it takes at a realistic rate. The answer is frequently
longer than expected.

Remember that moving data out is billed as egress by the source provider,
which can be a meaningful one-off cost for large datasets. See
data egress fees explained.

For databases, the usual approach is to take a bulk copy, then replicate
ongoing changes until the two are in step, then cut over during a short window.
For object storage, sync in advance and re-sync the delta immediately before
cutover.

Prepare DNS before anything else

This is the step with the longest lead time and it is almost always left too
late. Lower the time to live on the records you will change to a few minutes,
and do it days in advance, because the old value stays cached until the original
time to live expires.

Getting this wrong means a cutover where some users reach the new system and
others reach the old one for a day, which is the worst possible state if both
accept writes.

A sequence that keeps rollback available

1. Build the destination environment and get the application running against a
   copy of the data. Nothing is live.
2. Test properly, including the integrations and the scheduled jobs, not just
   the main user journey.
3. Set up monitoring and backups on the new environment before it carries
   traffic, not after.
4. Reduce DNS time to live, several days ahead.
5. Begin data replication and let it catch up.
6. Cut over during a low-traffic window: stop writes, let replication finish,
   switch DNS, verify.
7. Keep the old environment running, untouched, for at least a week.
8. Decommission only after you are confident, having confirmed backups exist
   on the new side.

Step seven is the one people skip to save money, and it is the one that makes
the whole plan reversible.

Things that commonly go wrong

Outbound IP addresses changed. Partners allowlisting your
old addresses will reject you silently. Identify these during the inventory and
give them the new addresses in advance.

Email delivery degraded. New IP addresses have no sending
reputation. If you send mail from your own infrastructure, this is a real
problem, and using a transactional email provider avoids it entirely.

Cron jobs running in both places. Duplicate scheduled jobs
during cutover can double-process or double-charge. Disable them on the old side
deliberately.

Certificates not renewing. The renewal mechanism needs the
domain pointing at the right place. Verify after cutover rather than discovering
it in ninety days.

Backups not configured. The new environment is frequently
live for weeks before anyone notices there is no backup job.

Consider moving less

A full migration is sometimes unnecessary. Moving object storage alone, or
moving one workload while the rest stays, captures much of the benefit for a
fraction of the risk. The reasoning is in
signs you have outgrown your
cloud provider.