Website Migrations: Moving a Site Between Hosts

Moving a website from one host to another is a routine operation that goes wrong surprisingly often. Done carefully, visitors never notice; done carelessly, it means broken pages, lost email, or hours of downtime. The difference is planning and verification.

What a migration involves

At its core, a migration copies a site’s two halves — its files (code, themes, media) and its database (content, settings) — from the old environment to a new one, then reconfigures anything that was tied to the old host.

The typical sequence:

1. Audit the current site — note the stack it depends on (server software, database, language version), its size, cron jobs, and any custom server configuration.
2. Provision the new host to match those requirements, so the site lands in a compatible environment.
3. Copy files and database to the new server and import them.
4. Update configuration — database credentials, file paths, and any host-specific settings.
5. Test on the new host before any public switch, usually via a temporary URL or hosts-file override.
6. Cut over DNS to point the domain at the new server.

DNS and propagation

The public switch happens in DNS. Changing the domain’s records — usually the A record or nameservers — tells the internet where the site now lives. That change is not instant: resolvers around the world cache DNS records for a period defined by the TTL (time to live), so the new address spreads gradually in what is called propagation.

The practical technique is to lower the TTL in advance (say, a day before) so caches expire quickly, then make the change. During propagation some visitors reach the old server and some the new one, which is exactly why the old site should stay live and functional until propagation completes.

Avoiding downtime

The goal is a switch nobody sees. Two habits achieve it:

• Keep both environments running during cutover. Because visitors hit one server or the other while DNS propagates, both must serve the site correctly.
• Test before you point DNS. Fully verifying the site on the new host first means the cutover reveals no surprises.

Scheduling the change during a low-traffic window and freezing content edits during the move prevents data written to the old site from being lost after the switch.

Common pitfalls

• Email and MX records left pointing at the old host, silently breaking mail even though the website works.
• Hardcoded URLs and mixed content — absolute links or assets still referencing the old domain or plain HTTP.
• Missing SSL certificate on the new host, so the site loads insecurely after cutover.
• Environment mismatches — a different language or database version, or wrong file permissions, causing errors.
• Search-engine indexing risk — an inherited noindex or a robots.txt from a staging setup that blocks crawlers on the live site.

Post-migration checks

Once DNS has propagated, confirm the move is clean:

• Core pages, navigation, and media load correctly.
• Forms, logins, checkout, and any integrations work end to end.
• SSL is valid and every page serves over HTTPS, with no mixed-content warnings.
• Redirects and internal links resolve; no broken URLs.
• Analytics and tracking still fire.
• Search visibility is intact — the site is indexable and the search console shows no new crawl errors.

Keeping a backup of the original site until the new one is fully verified provides a safe fallback. For that safety net, see Backups and Disaster Recovery; to rehearse changes before they go live, see Staging Environments; and for the certificate step, see SSL and Website Security.