What We Check Before Moving a Website to New Servers
Every cloud migration checklist looks similar on paper — inventory, dependency mapping, a cutover plan. The version that matters is the one written after something has already gone wrong.
Before we move a production workload, we confirm rollback is actually tested, not just documented. We trace every hardcoded IP, every assumption about latency between services, and every cron job nobody remembers writing.
The migrations that go quietly are the ones where the boring 80% — DNS TTLs, connection pool limits, IAM permissions — got checked before the exciting 20% started.
A rollback plan that's never been executed isn't a rollback plan, it's a hope. We've seen teams write detailed rollback documentation and then discover, mid-incident, that the old environment was already decommissioned or that a database migration ran one-way. Before any cutover, we run the rollback in a staging environment as a rehearsal, not just a review of the steps on paper.
DNS is the failure mode that catches the most experienced teams off guard, because it's invisible until it isn't. A TTL set to 24 hours 'temporarily' two years ago means a cutover that should take minutes instead bleeds traffic to the old environment for a full day. We check every TTL in the path weeks before a migration, not the night before, because lowering a TTL safely itself needs lead time to propagate.
Connection pool limits are the second-most common surprise. A workload that ran fine against an on-prem database with generous connection limits can quietly exhaust a managed database's default pool the moment it's under real load in its new home. We load-test the new environment at expected peak, not average, before calling a migration ready — average load hides the exact problem a migration is likely to trigger.
IAM and networking rules are where migrations quietly break things that worked by accident rather than by design. A service that could reach another service because they happened to share a VPC in the old environment doesn't automatically have that access in the new one. We map every service-to-service call before migrating, not just the ones documented in an architecture diagram, because the undocumented ones are exactly the ones nobody remembers to re-permission.
The cron jobs are the quietest risk of all. Every long-lived production environment accumulates scheduled tasks nobody owns anymore — a backup script, a cleanup job, a reconciliation report someone needed once. We grep the crontab and the scheduler configs specifically, because a migration that moves the application but silently drops a job nobody remembers writing doesn't fail loudly. It fails three weeks later, as a data discrepancy nobody can explain.
None of these checks are exciting. They're also the difference between a migration nobody notices and one that pages someone at 3am.
