Website migration with minimal downtime: moving hosts without breaking your business

At some point almost every growing business outgrows its first hosting provider — or simply wants better speed, support, or pricing. The common fear is that migrating means downtime, broken emails, and lost data. With careful planning, a move can keep interruption to a minimum. This guide explains what a migration actually involves and how to plan one so your site is out of service for as little time as possible.

What a website migration actually moves

A complete site migration is not just copying files. There are four distinct components, and each one needs to be handled in the right order:

• Website files: All your theme files, plugins, uploaded images, and any custom code. For WordPress sites this is primarily the wp-content folder.
• Database: A WordPress site keeps its pages, posts, settings and user accounts in a MySQL database — not in the files. Migrating without the database gives you a shell with no content. Where plugins such as forms or shops store their own data depends on the plugin and its configuration, so check that separately.
• Email accounts: If your email runs on the same hosting account (e.g. [email protected]), the mailboxes, folders, and contacts need to be migrated or pointed to a new mail server. This is the component most often broken during rushed migrations.
• SSL certificate: Your HTTPS padlock must be active on the new host before you cut over DNS. Visitors hitting the site on an insecure connection will see browser warnings and leave immediately.

The DNS cutover: where downtime usually happens

When you move hosts, you update your domain’s DNS records to point to the new server’s IP address. DNS changes do not reach everyone at once: each DNS record has a TTL (Time to Live) that tells resolvers how long they may cache it, and some resolvers cache for longer than others. During that window, some visitors reach the old server and some reach the new one.

A common approach is to lower the TTL (for example to 300 seconds) at least 24 hours before the planned cutover. This shortens the period during which cached records remain in use, although it does not guarantee that all traffic switches within minutes. Once the lowered TTL has taken effect you make the DNS change. The old server stays live and untouched until you are certain everything is working — acting as a safety net. Only then do you decommission it. See Cloudflare’s TTL reference for how TTL works.

Orders, forms and other writes during the cutover

While both servers are reachable, a site that accepts new orders, form submissions or comments can receive them on the old server and the new one, and the two copies then diverge. Agree a method for your site before the move: a short content freeze, a final database sync after the switch, or another approach suited to how the site works. A rollback after new orders have arrived also needs a plan for that data. See AWS’s cutover guidance for the general approach.

Pre-launch checklist

Before you change a single DNS record, confirm every item on this list:

1. Full backup of files and database taken from the old host and stored off-server (not just on the new host).
2. Files and database successfully imported and verified on the new host using a temporary staging URL or hosts file override.
3. All internal links and media URLs resolve correctly on the new host — especially important if you are changing your domain at the same time.
4. SSL certificate issued and active on the new host for your domain.
5. Contact forms, payment gateways, and any third-party integrations tested and working.
6. Email accounts created on the new mail server and IMAP/SMTP settings documented.
7. TTL already lowered on your current DNS for at least 24 hours.
8. A plan for orders and form submissions that arrive during the switch.
9. A monitoring alert set up so you know immediately if the site returns an error after cutover.

What to ask any migration provider

Not all “free migration” offers are equal. Before you hand over access credentials, ask these questions:

• Do you migrate the database, or just the files? Files-only migrations leave your site broken.
• Do you handle email migration, or is that separate? Many providers migrate the site but leave email for you to sort out — often without telling you upfront.
• What is your rollback procedure if something goes wrong? A serious provider has a documented rollback plan, not just a vague “we’ll fix it.”
• How do you keep interruption to a minimum? A provider should be able to explain the cutover plan for your site, including how new orders and forms are handled. A vague promise of “zero downtime” is a red flag.
• Who do I contact during the cutover window? The DNS cutover is the highest-risk moment. You want a named person available, not a ticket queue.

After the cutover

Once DNS has propagated and the new server is live, spend 30 minutes walking through your site as a real user would: test the checkout if you have e-commerce, submit a contact form, check that emails arrive, verify the SSL padlock on every major page. Do not cancel the old hosting account for at least 7 days — you want a clean fallback if an edge case surfaces in the first week.

If you would rather hand this off, the WebHostLB migration service reviews your site, domain and email dependencies and agrees the scope and cutover approach with you before the move.