Website Migration Checklist: Step-by-Step Workflow to Move Any Site to a New Host with Zero Downtime

Overview

A successful host-to-host migration is a controlled change, not a single upload. The safest approach is to build the new environment while the existing site remains live, test the copy privately, reduce DNS time to live (TTL) before the switch, and keep the old host available until the new site has proved stable.

This process works for a WordPress installation, a static HTML site, or a larger application such as Magento. The control-panel labels will differ between cPanel, Plesk, and cloud dashboards, but the underlying tasks are the same:

1. Inventory the current site and its dependencies.
2. Back up files, databases, DNS records, and email-related settings.
3. Prepare the new hosting account without changing public DNS yet.
4. Copy the site and database, then test it privately.
5. Synchronize recent changes and switch DNS during a controlled window.
6. Verify the live site, monitor it, and retain a rollback option.

Before starting, record the current host, domain registrar, DNS provider, CMS version, PHP or runtime version, database type, SSL arrangement, and any integrations. If the site processes orders, registrations, comments, or contact forms, identify where those transactions are stored. A final file copy alone may not capture activity that occurs while the old site is still live.

For a broader recovery plan, pair this workflow with the WordPress Backup and Restore Guide. If you are still comparing hosting options, review the differences in managed WordPress hosting and shared hosting before committing to the move.

What to track

1. Build a migration inventory

Create a simple document with the following items and mark each one as recorded, copied, tested, or confirmed:

• Website files: document root, uploads, media, private storage, configuration files, and deployment scripts.
• Database: database name, user, host, table prefix, character set, credentials, and approximate size.
• DNS: A and AAAA records, CNAME records, MX records, TXT records, subdomains, and any verification records.
• Email: mailboxes, forwarding addresses, aliases, autoresponders, SMTP settings, and spam-filter or authentication records.
• SSL: certificate source, renewal method, covered hostnames, and whether HTTP redirects to HTTPS.
• Scheduled work: cron jobs, queue workers, backups, security scans, cache clearing, and report generation.
• Application connections: payment providers, analytics, search tools, webhooks, APIs, CDN settings, and storage buckets.
• SEO controls: robots.txt, XML sitemaps, canonical URLs, redirects, metadata, and any server-level rules.

Take screenshots or export settings where possible. Do not rely on memory, especially for email and DNS. A website can appear healthy while mail delivery fails because an MX or TXT record was omitted.

2. Create backups you can restore

Make at least one complete backup before changing the account. For a typical Linux host, a database export may look like this:

mysqldump -u DB_USER -p DB_NAME > site-backup.sql
tar -czf site-files-backup.tar.gz /path/to/document-root

Replace the placeholders with your actual values and confirm that the commands complete without errors. If you use a control panel, download the database export and a compressed copy of the site files from its backup or file-management tools. Keep a copy outside the old hosting account. Test the backup by opening the archive and, where practical, restoring it to a temporary environment.

For WordPress, record active plugins, themes, custom code, uploads, and configuration values. Migration plugins can simplify a smaller site, while command-line tools or host-provided transfer utilities may be more suitable for a large installation. Check the tool's compatibility with the site's PHP version, database size, available disk space, and server access before relying on it.

3. Prepare the new host

Create the domain, database, database user, and required email accounts on the new host. In cPanel this may involve Domains, MySQL Databases, File Manager, and SSL/TLS. In Plesk, look for Websites & Domains, Databases, File Manager, and certificate settings. Cloud dashboards use different names, but you still need an application root, runtime version, database, access credentials, and HTTPS configuration.

Match the old environment first rather than upgrading several components during the move. A later upgrade is easier to troubleshoot than a migration that changes the operating system, PHP version, database engine, caching layer, and application code simultaneously.

4. Copy and test the site privately

Upload the files and import the database. For a command-line transfer, a basic pattern is:

rsync -avz --delete /local/site/ user@new-server:/path/to/site/
mysql -u NEW_DB_USER -p NEW_DB_NAME < site-backup.sql

Use the destination path and credentials supplied by the new host. Do not use --delete unless you understand that it removes destination files absent from the source. After importing, update the application configuration with the new database name, user, password, and host. Keep the public domain pointed at the old host while you test through a temporary hostname, preview feature, hosts-file entry, or password-protected staging address.

Check the homepage, representative internal pages, media files, search, logins, forms, checkout flows, admin functions, scheduled tasks, and server error logs. For WordPress, verify site URL values carefully and avoid permanently changing them to a temporary hostname unless you understand the consequences for serialized data and links.

5. Plan DNS and the final synchronization

Before the switch, lower the relevant DNS TTL at the authoritative DNS provider. A shorter TTL can help resolvers request the new answer sooner, but it cannot force every cached result to expire immediately. Make this change in advance, then confirm it is visible using more than one DNS lookup location.

For sites that receive frequent writes, schedule a brief maintenance mode or temporarily pause comments, orders, registrations, and other changing functions. Export or copy the database again immediately before the DNS change, import the final delta to the new host, and then update the record. Static sites usually need only a final file sync, but confirm that deployment jobs are not writing to the old location.

6. Keep a rollback template

Write this plan before switching DNS:

Rollback trigger: critical checkout, login, database, email, or data-integrity failure that cannot be corrected promptly.

Rollback action: restore the previous DNS record values, re-enable the old site's write functions, and communicate the temporary change to the team.

Evidence to preserve: timestamps, error logs, failed URLs, DNS responses, application changes, and database backups from both hosts.

Reattempt condition: root cause identified, backups verified, and a new test completed on the destination.

Cadence and checkpoints

Use the following staged schedule for a predictable migration:

1. Several days before: inventory the site, export DNS and email settings, confirm account access, create backups, and lower TTL if appropriate.
2. One to two days before: create the destination environment, copy files and databases, install SSL, and test the site privately.
3. Migration window: pause write-heavy functions if needed, make a final backup, synchronize changes, switch DNS, and record the exact time.
4. First hour: test the homepage, key templates, HTTPS, forms, login, database connections, redirects, and email sending and receiving.
5. First day: inspect logs, analytics, uptime checks, search crawl errors, payment or webhook activity, and application performance.
6. First week: compare traffic, conversions, response times, Core Web Vitals, error rates, storage, backups, and scheduled jobs with the old baseline.

Do not cancel the old hosting account immediately. Retain it until DNS behavior is stable, all critical functions pass, and you have a current backup of the new environment. Once the migration is complete, restore a sensible TTL and remove temporary access, preview records, old credentials, and unused scheduled tasks.

How to interpret changes

A temporary difference during DNS propagation is not automatically a migration failure. First determine which host handled the request by checking DNS resolution, response headers, server logs, or a host-specific test URL. If only some visitors report an issue, cached DNS or CDN behavior may be involved. If every test fails, inspect the destination configuration, database credentials, web-server rules, and certificate installation.

Use a before-and-after comparison rather than relying on a single speed test. Track:

• HTTP status codes and server error rates.
• Time to first byte, page loading behavior, and Core Web Vitals.
• Form submissions, logins, orders, email delivery, and webhooks.
• Redirect chains, canonical URLs, robots.txt, and sitemap accessibility.
• Backup completion, cron execution, disk usage, and resource limits.
• Uptime and user reports across desktop and mobile connections.

Common causes of post-migration problems include an incorrect document root, missing PHP extensions, incompatible runtime versions, incorrect file permissions, a database server that is not reachable, hard-coded old URLs, missing rewrite rules, and DNS records copied incompletely. Email failures often point to missing MX, SPF, DKIM, or other provider-specific records rather than a website-file problem. For systematic diagnosis, use the DNS Troubleshooting Guide.

If the site is slower after the move, compare caching, image delivery, database queries, CDN settings, server location, and resource limits before concluding that the new host is unsuitable. The hosting performance checklist provides a useful post-migration baseline.

When to revisit

Keep this checklist with the site's operational records and reuse it whenever you change hosts, clone a production site, add a domain or subdomain, move email, reissue certificates, or change DNS providers. Review the migration inventory quarterly so that old credentials, integrations, cron jobs, and DNS records do not remain undocumented.

Refresh the technical steps after a major CMS or hosting-control-panel release, when a provider changes its migration utility, or when the site's architecture changes. Recheck DNS TTL assumptions annually and whenever the authoritative DNS provider changes. Hosting plans, runtime support, backup behavior, and migration tools can differ, so confirm provider-specific instructions immediately before a production move rather than relying on an old screenshot.

For your next migration, start by copying this final action list into a project ticket:

• Inventory files, database, DNS, email, SSL, cron jobs, integrations, and SEO settings.
• Export and independently store tested backups.
• Prepare the new host and match the current runtime before optimizing.
• Copy the site, import the database, and test privately.
• Lower TTL in advance, schedule the switch, and document rollback values.
• Synchronize final changes, update DNS, and test every critical path.
• Monitor for at least the first day, compare performance for the first week, and retain the old host until the result is confirmed.

This repeatable process turns a risky hosting change into a measured, reversible operation. It also gives you a current record of how the website, domain, DNS, email, and security layers fit together.