Website migration without downtime: a practical guide

You can migrate your website to a new host with effectively zero visible downtime by preparing the new environment fully, replicating all DNS records, lowering TTLs appropriately in advance, and running old and new services in parallel until propagation completes. The single most important action you can take right now is to export a full backup of your files and database, then record every record in your current DNS zone before touching anything else.

Three things make or break a no-downtime website transfer:

A complete, verified backup stored somewhere other than your current host
DNS sequencing done in the right order, with TTLs lowered at least 48 hours before you switch nameservers
A parallel overlap period where both old and new environments stay live, with a clear rollback plan if something goes wrong

Pro Tip: Before you start, open your domain registrar and your current DNS provider in separate browser tabs. You will need both throughout this process, and losing access mid-migration is one of the most common causes of unnecessary downtime.

Key takeaways

A website migration without downtime is achievable for any small business site when you prepare the new environment fully, sequence DNS changes correctly, and keep both old and new services running in parallel until propagation is confirmed.

Point	Details
Back up everything first	Export files, database, and mailboxes before touching anything; store copies off-site.
Lower TTLs 48 hours ahead	Reduce record TTLs to ~300 seconds and wait the full previous-TTL interval before cutting over.
Run a parallel overlap	Keep old and new DNS providers serving identical data so resolvers get consistent answers from either.
Test before DNS changes	Use the hosts file method to verify the new site privately; check SSL, forms, and email before cutover.
Keep old host for 7+ days	Retain the old hosting account and DNS zone for at least 7 days as a rollback safety net.
No Worry Websites & Ai Automations	Offers fully managed migrations with backup, DNS sequencing, SSL, testing, and 7-day rollback support.

What to gather before you touch anything
How to move your files and database to the new host
The phase-by-phase DNS playbook
How to test the new site before you change DNS
Exact steps to follow during cutover and how to monitor
What to verify after propagation, and when to decommission
Common mistakes that cause downtime, and how to fix them fast
A note from No Worry Websites & Ai Automations
Managed migration, done for you
Sources

What to gather before you touch anything

Rushing into a migration without the right credentials and checks in place is how small businesses end up with broken forms, missing emails, and a site that is down for hours. Take 30 minutes to gather everything listed below before you proceed.

Accounts and credentials

Confirm you have working login details for: your domain registrar, your current DNS provider (sometimes the same as the registrar, sometimes separate), your old hosting control panel (cPanel, Plesk, or similar), your new hosting control panel, FTP or SSH access to both servers, your database credentials (host, username, password, database name), and your email provider if email is hosted separately.

If any of these are missing, stop and retrieve them now. A migration stalled at the registrar because you cannot log in is a preventable problem.

Backups

Export a full copy of your webroot files and a database dump (SQL format). If email is hosted on the same server, export your mailboxes too. Store everything off-site: a USB drive, Google Drive, Dropbox, or a cloud storage bucket. Never rely on your current host’s own backup system as your only copy during a migration.

Compatibility checks on the new host

Mismatched PHP or database versions are among the most common causes of fatal errors during migrations, according to WP Engine’s zero-downtime migration guide. Before you transfer a single file, confirm:

PHP version matches (or is compatible with) your current environment
MySQL or MariaDB version is compatible
Required PHP extensions are enabled (e.g. mbstring, curl, gd, xml)
Disk space is sufficient, including room for growth
File permissions can be set correctly (755 for directories, 644 for files)
Any cron jobs or scheduled tasks are noted and ready to recreate

DNS inventory

Export your full DNS zone from your current provider. Most providers offer a BIND-format export; if yours does not, manually list every record: A, AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC), CAA, and SRV. Note the TTL on each record and, critically, check the NS record TTL at your registrar. That NS TTL is controlled at the registry level and may be more than one day regardless of what you set elsewhere.

Pro Tip: Screenshot your full DNS zone or paste it into a text file. You will refer to it repeatedly during the migration, and having it offline means you can check it even if your old provider’s dashboard goes down.

Operational decision to make now: Decide who has authority to approve the registrar nameserver change, what your acceptable maintenance window is (even a 2 AM slot is worth booking), and who is on call to execute a rollback if needed. These decisions made in advance prevent panic decisions made under pressure.

How to move your files and database to the new host

With your credentials gathered and your new hosting environment ready, the goal of this phase is to get a working copy of your site running on the new server before you change a single DNS record. Visitors continue to see the old server throughout.

Setting up the new environment

Create the webroot directory on the new host and set correct file permissions.
Create a new database and database user with a strong password; grant full privileges on the database.
Match the PHP version to your current host. If you are on PHP 8.1 on the old server, set PHP 8.1 on the new one.
Configure any caching layers (e.g. Redis, Memcached, or server-level caching) to match your current setup.
Recreate any cron jobs from your notes.
Install an SSL certificate on the new host before DNS changes (more on this below).

Transferring files

For most small business sites, SFTP works well. For large media libraries, rsync over SSH is faster and restartable:

rsync -avz --progress user@oldhost:/var/www/html/ user@newhost:/var/www/html/

Alternatively, use your old host’s cPanel full-account backup tool and restore it on the new host. Many UK hosts also offer server-to-server migration assistance; if yours does, use it, but verify the transferred files and database yourself rather than assuming the automated tool caught everything.

Importing the database

Export using mysqldump, phpMyAdmin, or WP-CLI:

mysqldump -u username -p database_name > backup.sql

Import on the new server:

mysql -u newuser -p newdatabase < backup.sql

WordPress users: WordPress stores serialised data in the database, so a simple find-and-replace on the SQL file will corrupt it. Use WP-CLI’s search-replace command instead:

wp search-replace 'https://oldsite.com' 'https://newsite.com' --all-tables

The official WordPress moving guide covers this process in full, including updating wp-config.php with the new database credentials and flushing caches after the import.

Pro Tip: After importing the database, run wp cache flush and wp rewrite flush via WP-CLI. Stale cache entries are a common reason a migrated WordPress site looks broken during testing even when the files and database are correct.

Testing on the new host before touching DNS

Edit your local hosts file to point your domain to the new server’s IP address. On Windows, this file is at C:WindowsSystem32driversetchosts; on Mac and Linux, it is /etc/hosts. Add a line like:

203.0.113.10  yourdomain.co.uk www.yourdomain.co.uk

Only your machine will see the new server. Everyone else continues to see the old one. Browse your site, submit a test form, log in as a user, and check that images and plugins load correctly. When you are satisfied, remove the hosts file entry.

The phase-by-phase DNS playbook

DNS is the part of a migration most likely to cause visible downtime, and most of the problems are avoidable with the right sequence. A seven-phase DNS migration sequence reduces the common failure modes: audit, replicate, lower TTLs, verify, update registrar NS, monitor propagation, then restore TTLs and decommission only after confirming zero traffic.

Phase 1 — Audit and export. Export your full zone in BIND format if your provider supports it. Every TXT record matters: a missing SPF record means your outbound email lands in spam; a missing CAA record means your SSL certificate may not auto-renew on the new host.
Phase 2 — Replicate the zone exactly. Create every record at the new DNS provider before you lower any TTLs. Pay particular attention to SPF: if you have multiple TXT records that look like SPF entries, they must be merged into a single TXT record (multiple SPF records cause SPF failures). Copy CAA records verbatim. For zone replication, Infrastructure-as-Code tools like Terraform or DNSControl are the cleanest approach because they are versionable and detect drift; AXFR zone transfer works when both providers support it securely, per DNScale’s DNS migration guide.
Phase 3 — Lower TTLs. At least 48 hours before your planned cutover, reduce all record TTLs to around 300 seconds (5 minutes). Then wait the full length of the previous TTL before proceeding. If your A record TTL was 86,400 seconds (24 hours), you must wait 24 hours after lowering it before cutting over, so that all resolvers have expired their cached answers. Cloudflare’s DNS TTL explainer explains this clearly: lowering the TTL is necessary but only effective once the old TTL has expired across the resolver network. Note that NS and TLD TTLs are set at the registrar and registry level; you cannot always shorten them below 24–48 hours.
Phase 4 — Parallel run. Run both DNS providers simultaneously with identical zone data. This means resolvers returning answers from either provider will get consistent results. The transition becomes tolerant to resolvers that are slow to pick up the nameserver change.
Phase 5 — Registrar NS update. Pick a low-traffic window (early morning on a weekday works well for most UK small businesses). Log into your registrar and update the nameserver delegation to point to your new DNS provider. Note the exact time and the change reference number. This is the cutover point.
Phase 6 — Monitor propagation. Check propagation globally using dig:

dig @8.8.8.8 yourdomain.co.uk A
dig @1.1.1.1 yourdomain.co.uk MX

Online propagation checkers let you see resolver responses from multiple locations simultaneously. Rollback criteria: if your error rate is high, SSL is failing, or email is down and not fixable within 15 minutes, revert the registrar NS to the old provider immediately.

Phase 7 — Post-cutover. Once propagation looks stable, restore TTLs to production values (typically 3,600 seconds). Verify SSL auto-renewal is configured and that CAA records allow your certificate authority. Keep the old DNS provider active for at least 7 days as insurance, per DNScale’s decommission guidance.

Pro Tip: When you update your registrar’s nameservers, write down the old nameserver values before you change them. If you need to roll back, you will want those exact strings ready to paste back in without hunting for them.

How to test the new site before you change DNS

The hosts file method described above lets you browse the new server privately, but a thorough pre-cutover test covers more ground than just clicking around.

Core smoke tests to run

Browse your homepage, key service pages, and any page with a form
Submit a contact form and confirm the submission arrives correctly
If you have a shop, complete a test checkout (use a test payment gateway mode)
Log in as a registered user and check the account area
Check all redirects (301s from old URLs should still fire correctly)
Test any third-party API integrations (booking widgets, CRM connections, payment processors)

For resilient SaaS-style integrations, testing APIs and webhooks before cutover is especially worth the time; a broken webhook discovered post-cutover is far harder to diagnose under pressure.

Command-line checks

# Check HTTP response headers
curl -I https://yourdomain.co.uk

# Resolve against the new nameserver directly
dig @new.nameserver.example yourdomain.co.uk A

# Inspect the SSL certificate
openssl s_client -connect yourdomain.co.uk:443 -servername yourdomain.co.uk

Email and deliverability checks

Send a test email from the new server to an external address (Gmail, Outlook). Check that:

MX records at the new DNS provider point to the correct mail host
SPF TXT record includes the new server’s sending IP
DKIM TXT record is present and the selector matches your mail platform’s configuration
DMARC TXT record is present and correctly formatted
The email arrives in the inbox, not spam

SSL checklist

Certificate is present and valid on the new host
SANs cover both yourdomain.co.uk and www.yourdomain.co.uk
Auto-renewal is configured (Let’s Encrypt via Certbot or your host’s ACME client)
CAA records at the new DNS provider permit your chosen certificate authority

Pro Tip: Run openssl s_client -connect yourdomain.co.uk:443 before and after DNS cutover. It shows you the certificate’s issuer, expiry date, and SANs in seconds, and is far faster than waiting for a browser to flag a problem.

Exact steps to follow during cutover and how to monitor

The cutover window is where preparation pays off. Keep this section open as a run-book.

Final sync. If your site has active writes (blog comments, orders, form submissions), run a final rsync and a fresh database dump immediately before the NS change. For sites with continuous writes, consider pausing form submissions briefly or queuing changes so you can reconcile them after propagation.
Update the registrar. Log into your domain registrar and change the nameservers to your new DNS provider. Save the change and note the time.
Verify the change has been accepted. Run dig NS yourdomain.co.uk @a.root-servers.net to confirm the TLD is serving the new NS records.
Start monitoring. Check your uptime monitor, watch your server error logs, and run DNS propagation checks every 10–15 minutes for the first hour.
Send an email loop test. Send a message from an external address to your domain and reply; confirm both directions work.
Check SSL. Open your site in a browser and confirm the padlock is present. Run the openssl s_client command above.

Rollback criteria and actions

Define these thresholds before you start:

HTTP error rate above 5% for more than 5 minutes
SSL certificate error visible in browser
Email delivery failure not resolved within 15 minutes
Any critical page returning a 500 error

If any threshold is met, revert the registrar NS to the old provider immediately. The old environment is still live and will resume serving traffic as soon as resolvers pick up the reverted NS records.

Monitoring tools for the first 48 hours

Uptime monitors: UptimeRobot (free tier), Better Uptime, or Pingdom
DNS propagation: dnschecker.org or whatsmydns.net
Real-user monitoring: Cloudflare Analytics (free) or Google Search Console for crawl errors
Server logs: tail your access and error logs on the new host in real time

Pro Tip: Set up a free UptimeRobot monitor on your domain before you start the migration, not after. That way you have a baseline and will receive an alert the moment the site becomes unreachable, rather than finding out from a customer.

What to verify after propagation, and when to decommission

Propagation is largely complete within a few hours for most resolvers once TTLs are at 300 seconds, but some resolvers hold answers longer. Give it 24–48 hours before you consider the migration fully settled.

Post-migration verification checklist

Site loads correctly on both yourdomain.co.uk and www.yourdomain.co.uk
SSL certificate is valid and shows the correct expiry date
Google Search Console shows no crawl errors or coverage drops
Google Analytics (or your analytics platform) is recording sessions correctly
All 301 redirects are functioning as expected
Subdomains (e.g. mail., shop., app.) resolve correctly
Key conversion pages load and function correctly

Email verification

Check MX records resolve to the correct mail host using dig MX yourdomain.co.uk. Send test messages from external providers (Gmail, Outlook, Yahoo) and confirm delivery. Use a tool such as MXToolbox to verify SPF, DKIM, and DMARC alignment.

Restoring TTLs and decommissioning safely

After 24–48 hours of stable operation, restore your DNS record TTLs to production values (a sensible TTL default for most records). Keep the old hosting account active for at least 7 days. Check your old server’s access logs: if you still see traffic hitting the old IP, some resolvers are still caching the old A record. Only cancel the old account once those logs show no meaningful traffic.

Take a final backup from the old host before you cancel. Update any internal documentation that references the old server IP or credentials, and notify any team members or third-party developers who had access.

Pro Tip: Before cancelling the old hosting account, download a copy of the old server’s error logs. They can be invaluable if a problem surfaces a week after migration and you need to compare behaviour across the two environments.

Common mistakes that cause downtime, and how to fix them fast

Even well-planned migrations hit problems. Here are the most frequent ones and how to recover quickly.

Problem and fix pairs

Missing MX or SPF records: Email stops arriving or lands in spam. Fix: add the missing records at the new DNS provider and wait for propagation (up to the current TTL). Use MXToolbox to confirm.
Missing CAA record: SSL auto-renewal fails at the next renewal cycle. Fix: add the correct CAA record (e.g. 0 issue "letsencrypt.org") and verify with dig CAA yourdomain.co.uk.
Wrong A record IP: Site loads the old server or returns a connection error. Fix: correct the A record immediately and monitor propagation.
Broken WordPress serialised data: Pages look wrong or plugins throw errors. Fix: use WP-CLI search-replace with the --dry-run flag first, then run it for real.
Missing DKIM selector: Outbound email fails DKIM checks. Fix: add the DKIM TXT record with the correct selector name your mail platform specifies.

DNSSEC pitfalls

DNSSEC is the single most dangerous element in a nameserver migration. If your domain has DNSSEC enabled and you switch nameservers without handling it correctly, resolvers that validate DNSSEC will return SERVFAIL for your domain. Visitors will see a DNS error, not your site. There are two safe approaches:

Disable DNSSEC at the registrar before changing nameservers, wait for the DS record TTL to expire (often 24 hours), then change nameservers, then re-enable DNSSEC with the new provider’s DS records.
Coordinate a multi-signer DNSSEC transition if both providers support it, which keeps DNSSEC active throughout.

For most small business sites, option 1 is simpler and safer.

TTL mistakes

The most common TTL mistake is lowering the TTL too late, leaving insufficient time for caches to expire before cutover. The second is forgetting that NS and TLD TTLs are not under your control. If you have already cut over and propagation is slow, the only remedy is patience and keeping both environments live.

This point is reinforced by Kinsta’s analysis of DNS during site migrations: fully preparing the new environment and treating DNS as the final controlled switch is the correct mental model.

Data sync during propagation

For sites with active writes during the propagation window, the safest approach is to pause write operations briefly (put a maintenance notice on forms), run a final database sync, then re-enable writes once propagation is confirmed. For e-commerce sites, queue orders rather than blocking them, and reconcile the queue after propagation.

Pro Tip: If you discover a missing DNS record after cutover, add it immediately at the new provider. With TTLs at 300 seconds, the fix will propagate within 5 minutes for most resolvers. Speed of correction matters far more than diagnosing why the record was missed.

How long does each phase realistically take?

Planning a migration without time estimates leads to surprises. Here is a realistic schedule for a typical small business site.

Active work phases:

Environment setup on new host: 1–2 hours
File transfer and database import can vary significantly depending on site size
WordPress configuration and testing: 1–2 hours
Pre-cutover smoke tests: 1 hour
Final sync and registrar NS change: 30–60 minutes
Post-cutover monitoring (first 48 hours): ongoing checks, roughly 30 minutes of active attention

Calendar time (the phases you cannot rush):

TTL reduction wait: equal to your current TTL, minimum 24 hours, typically 48 hours recommended
Propagation after NS change: 1–24 hours for most resolvers when TTLs are at 300 seconds
Old host overlap period: minimum 7 days
DNSSEC DS record TTL expiry (if applicable): up to 24–48 hours

Overall realistic plan:

Minimum 2–3 days for a small site with short existing TTLs and no DNSSEC
7–10 days if the current zone has long TTLs (86,400 seconds) or DNSSEC is enabled, because you must wait the full existing TTL after lowering it before cutting over

Phase	Active time	Calendar block
Preparation and backup	1–2 hours	Day 1
New environment setup	1–2 hours	Day 1
File and DB transfer	30 min–3 hours	Day 1
TTL reduction and wait	15 minutes	Day 1, then wait 24–48 hours
Pre-cutover testing	1–2 hours	Day 2–3
Registrar NS change and monitoring	1–3 hours	Day 3 (low-traffic window)
Post-migration verification	30–60 minutes	Day 4
Old host decommission	15 minutes	Day 10+

A note from No Worry Websites & Ai Automations

The sequence in this guide is the one we recommend to every client considering a host move. The pattern we see most often is a business that has outgrown a cheap shared host and needs to move to something faster and more reliable, but is understandably nervous about disrupting the site that generates their enquiries. Following the steps above, particularly the TTL preparation and the parallel overlap period, means the actual cutover is usually the calmest part of the whole process.

Our pay-monthly website packages include free domain registration, SSL certificates, and ongoing support, which means SSL issuance and DNS configuration are things we handle as part of the service rather than extras you need to arrange separately. If you are moving to a new host as part of a redesign or a switch to personalised, ongoing support, we can manage the migration end-to-end, including the 7-day rollback window.

Managed migration, done for you

Moving a site yourself is absolutely possible with this guide. But if you would rather hand it over and get on with running your business, No Worry Websites & Ai Automations offers a fully managed migration that covers every step: full backup, new environment setup, DNS sequencing, SSL configuration, pre-cutover testing, and a 7-day overlap period with rollback support included.

Our tailored website packages include green hosting, a free domain, and an SSL certificate as standard, so you are not paying extra for the basics. Every migration comes with hands-on testing before DNS cutover and post-migration monitoring to confirm email, analytics, and SSL auto-renewal are all working correctly. There are no long-term contracts: you pay monthly and stay because the service works, not because you are locked in.

To get started, visit Noworry and get in touch. We will confirm what your migration involves and give you a clear plan before any work begins.

Sources

Ready to stop worrying about your website?

Book a free, no obligation 15 minute call and we will talk you through the best option for your business.