How to Avoid Downtime During a Website Migration

Reduce the risk of website downtime by testing the new host, planning DNS changes and controlling writes during the move. These checks help you prepare a recovery path without promising a zero-downtime migration.

Start here: reduce downtime, do not promise zero

A static brochure site and a busy ordering system have different migration risks. DNS caching, certificate readiness and changing data all affect the plan. A short, announced maintenance window can be safer than two servers accepting conflicting writes.

This guide focuses on continuity during the switch. Use the migration checklist for the complete inventory and the WordPress guide for application-specific steps.

Prepare the destination before switching visitors

Build and test the new environment while the current site remains available. Confirm capacity, runtime versions, database access and a trusted certificate for the intended hostname. Configure forms and integrations so a test copy cannot contact real customers or process payments.

Test with a supported preview or controlled local hostname override. Compare key pages and assets, not just the home page. Define a small set of health checks and the person authorized to call rollback.

Make DNS changes deliberate

If changing address records, consider lowering their TTL well before the move. Wait out the previous TTL before relying on the shorter one. Leave mail records alone for a website-only move.

For a nameserver move, recreate the full DNS zone first, including mail, verification, subdomains and DNSSEC coordination. The delegation change has its own caching behavior; it is not equivalent to editing an A record.

Read-only checks from Windows can reveal inconsistent address families:

Resolve-DnsName -Name your-domain.example -Type A
Resolve-DnsName -Name your-domain.example -Type AAAA
Resolve-DnsName -Name www.your-domain.example -Type CNAME

Expected findings depend on the recorded design. An old AAAA record can send IPv6 visitors to the former host even when the A record is correct. A missing CNAME can be intentional if www uses address records; compare against your inventory rather than deleting records reflexively.

Control writes during the overlap

For a static site, parallel copies are often straightforward. For a database-driven site, plan final synchronization and an approved write pause covering jobs, integrations and administrators as well as web traffic. Keep a record of the final synchronization time.

Do not turn the old site back into a writable fallback after the new site starts accepting changes unless you have a reconciliation plan. The problem is split data, not merely which page appears.

Watch the right signals

Monitor response codes, application errors, asset loading and authorized test writes. Check forms and external mail delivery separately. Compare authoritative DNS with recursive answers when visitors reach different servers.

Eddie’s Field Notes

“The homepage works,” said Eddie. “From both servers?” asked the migration lead. It did—and both were accepting bookings. A successful page load is only one health check; a single authoritative writer matters just as much.

Close the overlap safely

Keep the former environment available for the agreed cache and recovery window. Confirm logs no longer show meaningful traffic and all business checks pass before retirement. Retain backups and routing records. For a host-only move, preserve public URLs; a domain-change notification to search engines is a different procedure.

Official references

• Google: Change Hosting Without URL Changes
• Cloudflare: DNS Troubleshooting
• Microsoft: Resolve-DnsName

Documentation checked 2026-10-18. Examples use reserved names and addresses; replace placeholders only for systems you are authorized to manage. Interfaces and included features depend on your provider and account.