Moving off cheap shared hosting to AWS - a practical migration playbook

Migrating a live website to new hosting makes people nervous, and rightly so - get it wrong and you’ve got downtime, broken email, or lost data while customers watch. We’ve run migrations for systems where downtime simply wasn’t an option: payment platforms moving millions a day, airline systems, national health and government services. The same disciplined approach works just as well for a small-business website moving off a cramped shared host onto AWS.

Here’s the playbook we actually use.

Why move in the first place

If your site is slow, falls over under traffic spikes, or you’re nervous about security, shared hosting is usually the culprit. AWS gives you a real CDN, proper isolation, automated backups and the ability to scale - at a cost that, sized correctly, is often comparable to a decent shared plan. We’ve covered the why in detail here. This post is about the how.

The golden rule: never migrate without a rollback plan

Every migration we run starts by answering one question: if this goes wrong, how do we get back to a working state, fast? If you can’t answer that clearly, you’re not ready to start. Everything below is built around always having a safe way back.

Step 1 - Inventory what you actually have

Before touching anything, document the full picture:

• The site files and the platform (WordPress, Craft, static, custom).
• The database, and its size.
• Email - is it tied to the current host, or separate? (This catches people out constantly.)
• DNS records - every one, not just the website.
• The current TTL (time-to-live) on your DNS records.

Step 2 - Lower your DNS TTL first

This is the step amateurs skip. A few days before the migration, drop the TTL on your DNS records to something short (say 300 seconds). TTL tells the world how long to cache your DNS. With a low TTL, when you finally flip to the new server, the change propagates in minutes instead of hours - which dramatically shrinks the risky window.

Step 3 - Build the new environment in parallel

Set up the full site on AWS alongside the existing one, without touching the live site at all. Get it working completely on a temporary address, so you can test it as if it were live while the real site keeps serving customers untouched.

Step 4 - Sync data, then test like it’s real

Copy the files and database across, then test thoroughly on the new environment: every key page, forms, checkout, logins, search. For a content site, take a final fresh copy of the database just before cutover so nothing recent is lost.

Step 5 - Cut over by switching DNS

With the new environment tested and a fresh data copy in place, point your DNS at AWS. Thanks to the low TTL, most visitors move across within minutes. Because the old server is still running untouched, your rollback is simply: point DNS back. That’s the safety net.

Step 6 - Verify, then decommission

Once traffic is flowing to AWS and you’ve confirmed everything works - including email and forms - monitor for a day or two, then raise the TTL back up and decommission the old hosting. Not before.

The bits people get wrong

• Forgetting email. If email runs on the old host, migrating the website can break it. Identify and plan for email separately, always.
• Hard-coded URLs. Databases (especially WordPress) often store absolute URLs that need updating for the new environment.
• HTTPS/SSL gaps. Make sure the certificate is in place on the new environment before cutover, so there’s no insecure-site warning.
• No staging test. Cutting over without fully testing the new environment first is how you discover problems in front of customers.

You don’t have to do this yourself

This is routine work for us, and we do it with the same rigour we brought to far higher-stakes systems - usually with zero downtime and always with a clear rollback plan. If you’re stuck on slow hosting and want to move to AWS without the stress, get in touch and we’ll handle the whole migration for you.