How to Move a Website to Another Host

Moving a website safely is a sequencing problem. You need a complete copy of the site, a tested destination, a DNS cutover plan, and enough overlap between old and new hosting to recover if something goes wrong. Do not cancel the old service until the new site has been verified.

Inventory the current site

For inventory the current site, the useful approach is to separate the headline idea from the operating details that determine whether it works in practice. Record domains, DNS, files, databases, scheduled jobs, email dependencies, SSL, redirects, environment variables, CDN settings, and integrations. A migration can fail because of one forgotten background job even when visible pages look correct. Translate that into explicit requirements, ownership, and evidence before committing resources. Where two options are being compared, use the same assumptions and define what success would look like. That prevents a marketing label, vendor claim, or attractive feature from becoming a substitute for an actual decision framework.

Verify backups

For verify backups, the useful approach is to separate the headline idea from the operating details that determine whether it works in practice. Take a full backup of files and databases before changing anything. For critical sites, test that the backup is readable and restorable. Translate that into explicit requirements, ownership, and evidence before committing resources. Where two options are being compared, use the same assumptions and define what success would look like. That prevents a marketing label, vendor claim, or attractive feature from becoming a substitute for an actual decision framework.

Build destination first

For build destination first, the useful approach is to separate the headline idea from the operating details that determine whether it works in practice. Deploy the site to the new host and test before changing public DNS. Use a preview hostname, hosts-file override, or another safe method to inspect the real destination. Translate that into explicit requirements, ownership, and evidence before committing resources. Where two options are being compared, use the same assumptions and define what success would look like. That prevents a marketing label, vendor claim, or attractive feature from becoming a substitute for an actual decision framework.

Plan DNS cutover

For plan dns cutover, the useful approach is to separate the headline idea from the operating details that determine whether it works in practice. Confirm target IP or hostname, lower TTL in advance where appropriate, and keep the old host online while caches expire. For database-driven sites, plan a final synchronization so writes are not lost. Translate that into explicit requirements, ownership, and evidence before committing resources. Where two options are being compared, use the same assumptions and define what success would look like. That prevents a marketing label, vendor claim, or attractive feature from becoming a substitute for an actual decision framework.

Verify after launch

For verify after launch, the useful approach is to separate the headline idea from the operating details that determine whether it works in practice. Check DNS, HTTPS, redirects, key pages, forms, analytics, robots directives, sitemap, logs, and monitoring. Keep the old account until the migration is stable. Translate that into explicit requirements, ownership, and evidence before committing resources. Where two options are being compared, use the same assumptions and define what success would look like. That prevents a marketing label, vendor claim, or attractive feature from becoming a substitute for an actual decision framework.

Practical checklist

• Inventory files, databases, DNS, email, and jobs.
• Create verified backups.
• Test destination before cutover.
• Plan final data synchronization.
• Keep old hosting active during transition.

Common mistakes

• Cancelling old hosting before verification.
• Changing DNS and data without a plan.
• Forgetting email DNS records.
• Assuming the homepage proves everything works.

Bottom line

A low-risk migration separates copying, testing, DNS cutover, and decommissioning into distinct steps. Overlap gives you room to diagnose problems without unnecessary outage.