Direct answer: To move your website to a new host without downtime, never switch off the old host first. Instead, copy the whole site to the new host and test it there while the old site still serves visitors, lower your DNS time-to-live a day or two ahead so the switch spreads quickly, then point your domain to the new host, watch the change propagate, and keep the old host live for a safety window afterwards in case you need to switch back. Done in that order, visitors keep reaching a working site throughout, because at every moment at least one complete, working copy is live.
This guide covers a host move specifically: the same website, the same content, on a new server. It is different from a content migration or a redesign, where the site itself changes, and the plan below assumes the site stays the same. It walks through the pre-move checklist, the low-TTL trick, copying files and database, testing on a temporary address, switching DNS, monitoring propagation, the post-move checks that people forget, and the rollback plan if something goes wrong. You can read more practical guides on the Asad Webs blog.
What a Host Move Is, and Why Order Matters
A host move means your website's files and database move from one hosting provider's server to another's, while the domain name, the content and the design stay the same. Visitors reach the site through the same address as before; only the server answering that address changes. Because the content does not change, the move is mostly a copying and pointing exercise, and that is why it can be done without downtime: the old copy keeps working until the new copy is proven, and only then does traffic move.
The order is the whole plan. The dangerous way is to cancel the old host, upload files to the new host in a hurry, and hope the domain points correctly before anyone notices. The safe way reverses that: prepare, copy, test, switch, monitor, and only then retire the old host. Every step below exists to make sure that at no point is there a moment when no working copy is available. If any step fails, you simply stay on the old host while you fix it, and visitors never notice.
Two warnings belong at the start. First, email is often tied to the same domain settings as the website, and a careless DNS change can break email even when the website works perfectly, so mail records need separate attention, as covered below. Second, a host move is a good moment to discover that your backups were incomplete, so the backup step is not paperwork: it is the step you will be grateful for if anything else goes wrong.
Step 1: The Pre-Move Checklist
Start with a full backup of everything: all website files, the database, and any uploads, media and configuration files, stored somewhere outside both hosts, such as a download to your own computer or a separate storage account. A backup that lives only on the old host disappears with the old host, and a backup that lives only on the new host is not yet proven. Test that the backup is complete by checking its size and contents against the live site, and note the versions the site runs on: the PHP version, the database version, and any server software the site depends on.
Record the current DNS settings before touching anything: the addresses your domain points to, the mail records, and the time-to-live values currently in force. Take screenshots or export the DNS zone from your domain provider, so you can restore the exact previous settings if needed. Note also any services tied to the domain, such as email accounts, subdomains, and third-party tools that verify the domain, because each of them can be affected by a DNS change.
Check that the new host can actually run your site. Confirm that it offers the PHP and database versions your site needs, enough storage and resources, and the security certificate arrangements you rely on. Ask the new host whether it provides a temporary address or a staging area for testing, and whether it can help import the site. Choosing the quietest period for the final switch, such as a night or a weekend for a business site, reduces the number of visitors affected if anything does run slowly during propagation, even though a well-planned move should not cause downtime at all.
- Full backup of files and database, stored outside both hosts.
- Record of PHP version, database version and server requirements.
- Export or screenshot of current DNS settings, including mail records.
- Confirmation that the new host supports the site's requirements and offers a staging area.
Illustrative example: migration timeline in hours for planning (not a guarantee) — hover or tap each bar for details.
Step 2: Lower the TTL a Day or Two Ahead
DNS time-to-live, usually shortened to TTL, tells other servers how long to remember your domain's address before checking again. A long TTL means that after you change the address, some visitors and providers keep using the old address for hours, because their cached copy has not expired yet. Lowering the TTL ahead of the move shortens that memory, so that when you finally switch, the new address spreads much faster.
The method is simple: a day or two before the planned switch, change the TTL on the relevant DNS records to a low value. A commonly used low value is 300 seconds, which means five minutes, and that is a sensible example to use unless your provider advises otherwise. Then wait at least as long as the previous TTL before switching, so that the old, long-lived cached copies have expired everywhere and the new low value is the one in force. Skipping this wait defeats the purpose: if you lower the TTL and switch immediately, many resolvers still hold the old long TTL and will keep sending visitors to the old host for hours.
Plan the switch for after this waiting period, and remember to raise the TTL back to a normal value after the move is complete and stable. A permanently low TTL means every visitor's provider checks your DNS far more often than necessary, which adds load and can slow lookups slightly. Restoring a normal TTL after a few days of stability is part of finishing the job, not an optional tidy-up.
Step 3: Copy the Site and Test It on the New Host
Copy all files and the database to the new host, then adjust the site's configuration to point at the new database and the new environment. The exact steps depend on your platform, but the principle is the same everywhere: copy everything, change only the connection details, and do not edit content during the move. If you are also updating the site, do that before or after the move, never during it, because combining a move with content changes makes it impossible to tell whether a problem came from the move or from the edit.
Test the copy before anyone else sees it. Many hosts provide a temporary address for the new account, and you can also test by editing your own computer's hosts file so that your computer alone resolves the domain to the new server while everyone else still reaches the old one. In general terms, the hosts-file method is a local override on your own machine, useful for a thorough check, and it affects nobody else. Whichever method you use, test the same things visitors will do: load the homepage and key pages, submit the contact form, complete a test enquiry or order, check images and downloads, and confirm the site works over a secure connection.
Fix every problem found in testing on the new copy before switching DNS. Common findings include missing files that did not copy, database connection errors from an unchanged configuration value, file permission problems that break uploads or forms, and features that depend on a server version the new host does not provide. A problem found now costs minutes; the same problem found after the switch costs visitors. Only when the staging copy passes a full visitor test is the site ready to receive real traffic.
Step 4: Switch DNS, Monitor Propagation, and Keep the Old Host Live
Switching DNS means changing the domain's records to point to the new host's server addresses, using the values the new host provides. Make the change, then monitor propagation: the spread of the new address across the internet's DNS resolvers. During propagation, some visitors reach the new host and some still reach the old host, and that is normal and harmless as long as both copies work and both are the same site. Use a DNS propagation checking tool to watch the new address appear across regions, and check the site yourself from a fresh browser session and, if possible, a mobile connection.
Do not cancel the old host yet. Keep it live and unchanged for a safety window after the switch, at least a week for a typical small site, so that any visitor still reaching the old copy sees a working site, and so that you can switch DNS back instantly if a serious problem appears on the new host. During this window, avoid editing content on either copy alone, because the two copies will drift apart and a rollback would then restore an older version. If you must publish something urgent during the window, publish it on whichever copy is serving most traffic and copy it to the other, or wait until the window closes.
Watch for stragglers and errors during the window: check the new host's error logs, confirm that forms and enquiries arrive, and confirm that any scheduled tasks, such as backups or email sending from the site, run on the new host. If the new host shows a persistent problem you cannot fix quickly, switch DNS back to the old host, which is still live and unchanged, and treat the rollback as a successful use of the safety net, not as a failure. The table below summarises each step with its check and its fallback.
| Step | What to check | If it fails |
|---|---|---|
| Full backup | Backup complete and stored outside both hosts | Do not proceed until a complete backup exists |
| Lower TTL | Low TTL in force after waiting out the old TTL | Wait longer; do not switch while old caches remain |
| Copy and test | Staging copy passes a full visitor test | Fix on the staging copy; old site still serves visitors |
| Switch DNS | New address spreading; site loads on both hosts | Both copies work, so propagation delay is harmless |
| Keep old host live | Old copy unchanged for the safety window | Switch DNS back to the old host and investigate calmly |
| Post-move checks | Forms, email records, security certificate, search console | Fix on the new host; roll back only for serious faults |
Step 5: Post-Move Checks People Forget
Email comes first, because it breaks silently. Moving a website should not change email, but DNS edits can accidentally alter mail records, so check separately that mail still arrives and sends for every mailbox on the domain. Mail routing is controlled by MX records in DNS, which point to your mail provider, and those records must remain exactly as they were unless you are deliberately moving email too. Test by sending messages to and from each mailbox, and ask colleagues to confirm they receive mail normally.
Next, check the security certificate. A new host usually issues or installs a fresh certificate for the domain, and you should confirm that the site loads over a secure connection without warnings, on both the main address and any subdomains visitors use. A certificate problem shows visitors a frightening warning, so verify it in a fresh browser session rather than trusting a cached visit. Then check search tools: confirm the site is reachable in Search Console under the new host, submit the sitemap if the tool asks for it, and watch for crawl errors over the following days.
Finally, confirm the everyday functions: forms deliver to the right inbox, scheduled tasks and backups run on the new host, file uploads work, and any integrations, such as payment or booking tools, still connect. Once all checks pass and the safety window has run its course, raise the TTL back to its normal value, cancel the old host, and keep the pre-move backup for a while longer. The move is finished only when the old host is gone, the new host is proven, and the backup still exists somewhere safe.
The Rollback Plan, and a Planning Example
A rollback plan is simply the decision, made in advance, about when to switch back. Decide it before the move, not during a problem: switch back if the new host shows a fault you cannot fix within an agreed short time, if forms or orders stop working, or if the security certificate cannot be made valid. Because the old host is still live and unchanged during the safety window, rolling back means changing DNS back to the old addresses and waiting for the low TTL to spread that change, which is quick for the same reason the forward switch was quick.
The chart below shows an illustrative example of a migration timeline in hours, for planning purposes only, not a guarantee: preparation and backup take the longest, copying and testing follow, the DNS switch itself is brief, propagation is watched for a longer period, and the old host is retained well beyond that as a safety net. Your own timeline will differ with site size and host, but the shape should be the same: most time spent before the switch, a short switch, and a generous safety window afterwards. A plan shaped that way has room for problems without ever leaving visitors without a working site.
That shape is the real lesson of a host move. Downtime is rarely caused by the technology of moving a site; it is caused by rushing the order, skipping the backup, switching before testing, or cancelling the old host too soon. Follow the order in this guide, keep the old copy live, check email and certificates separately, and a host move becomes an uneventful administrative task rather than an emergency. If any step feels uncertain, pause on the old host, which is still working, and resolve it there: there is no deadline in a migration that justifies breaking a working site.
Never cancel the old host on the day of the switch. The old copy is your rollback plan, and it costs little to keep it live for a week while the new host proves itself.
If you are planning a move to a new host and would like it handled with a full backup, a tested staging copy and a safe rollback window, contact Asad Webs for a consultation and we can plan the move around your quietest period.
Frequently Asked Questions
Will moving hosts cause downtime?
Not if you follow the safe order: copy and test on the new host while the old site still serves visitors, then switch DNS, then keep the old host live as a safety net. Downtime happens when the old host is cancelled before the new copy is proven.
What is TTL and why lower it before a move?
TTL, or time-to-live, tells other servers how long to remember your domain's address. Lowering it a day or two ahead, for example to 300 seconds, means the new address spreads much faster when you switch, because fewer servers hold an old cached copy.
Can a host move break my email?
Yes, if DNS mail records are changed by mistake. Website and email use separate DNS records, so check MX records separately after the move and test sending and receiving on every mailbox, even when the website works perfectly.
How long should I keep the old host after switching?
Keep it live and unchanged for at least a week for a typical small site. That window covers slow propagation and gives you an instant rollback if a serious problem appears on the new host.
Should I update my website during a host move?
No. Move the site exactly as it is, and make content or design changes before or after the move. Combining a move with edits makes it impossible to tell whether a problem came from the move or from the edit.
What do I do if the new host does not work after the switch?
Switch DNS back to the old host, which is still live and unchanged during the safety window, and investigate the new host calmly. A rollback is a successful use of the safety net, not a failure.
Be the first to share a useful question or thought.