Website Hosting Migration Checklist: Move Without Breaking the Site, Email, or DNS

Moving a website is usually less about copying files and more about preserving all the small dependencies around the site.

A clean migration plan should answer four questions before anything changes:

1. What needs to move?
2. Who controls each account?
3. What can break during cutover?
4. How will you roll back if something goes wrong?

1. Inventory the current website

Write down:

• primary domain and any aliases;
• website files and document root;
• database names and versions;
• PHP/runtime version;
• cron jobs, scheduled tasks and queue workers;
• redirects;
• SSL certificates;
• third-party APIs and webhooks;
• CDN or proxy services;
• contact forms and mail-routing dependencies.

Do not assume the website is only the visible files in public_html. A working site often depends on database credentials, scheduled jobs, DNS records, environment files and external services.

2. Record who controls the domain and DNS

Confirm that the business or site owner can access:

• the domain registrar account;
• DNS management;
• the current hosting account;
• analytics and search tools;
• business email administration.

A hosting move should not accidentally turn into a domain-ownership dispute or account-recovery problem.

3. Back up before touching production

Take a fresh backup of:

• website files;
• databases;
• mailbox data if email is moving;
• DNS records;
• important configuration files.

Keep a copy outside both the old and new hosting accounts until the migration is complete and verified.

Restore the backup in an isolated environment and verify that the files and database work together. Record how long restoration takes so the rollback plan allows enough time.

4. Build and test the new copy first

Where possible, configure the new hosting environment before changing public DNS.

Check:

• the correct PHP/runtime version and required extensions;
• database connectivity;
• file permissions;
• application configuration, secrets and upload/memory limits;
• HTTPS for every hostname and certificate auto-renewal;
• redirects and web-server rewrite rules;
• uploads and media;
• admin login;
• forms, outbound SMTP and transactional email;
• scheduled tasks and queue configuration;
• external service IP allowlists;
• CDN origin settings, caching and firewall rules.

Use a hosts-file override or temporary preview method when available so you can test the new server without sending real visitors there yet.

Protect any publicly accessible preview copy with authentication to prevent indexing and unauthorized access. Keep its scheduled jobs, queue workers and automated customer emails disabled until the planned handover. Use controlled test recipients and payment sandbox settings when testing integrations.

Enable automated backups on the new host and verify the first successful run before launch.

5. Plan the DNS cutover

Before changing DNS:

• record the existing records;
• identify which records are actually changing;
• lower the relevant DNS TTLs in advance, allowing at least the previous TTL to expire before cutover;
• check both A and AAAA records so IPv4 and IPv6 visitors reach the intended server;
• confirm email-related MX, SPF, DKIM and DMARC records;
• avoid unnecessary registrar or nameserver changes if an individual A/AAAA/CNAME change is enough;
• if nameservers must change, verify the complete destination zone and plan the DNSSEC/DS-record transition with the DNS providers and registrar;
• keep the old hosting online during the transition.

The safest migration is usually the smallest DNS change required.

Lowering a TTL does not shorten the lifetime of records already cached under the previous TTL. Restore normal TTLs after the migration has stabilized. If DNSSEC is enabled, a nameserver change must preserve or deliberately transition the chain of trust; stale DS records can make the domain unreachable.

If email is also moving

• create destination mailboxes, aliases and forwarders before changing MX records;
• migrate existing messages and plan a final synchronization for messages arriving during the transition;
• prepare mail-client settings and any required credential changes;
• verify inbound and outbound delivery using an external email account;
• check SPF, DKIM and DMARC authentication for the intended sending services;
• keep the old mail service available until remaining messages are synchronized and delivery to the new service is verified.

Confirm whether cancelling the old hosting also removes mailboxes or DNS hosting, even if those services are not part of the website move.

6. Schedule cutover and protect live data

Agree on:

• a migration window and expected downtime;
• the person responsible for each step and the final go/no-go decision;
• hosting-provider support contacts;
• how affected users and staff will receive maintenance updates;
• the critical checks that must pass before the new site accepts live traffic.

For sites that accept orders, bookings, uploads or content edits, plan how changes made after the initial copy will reach the new server.

At cutover:

• pause deployments and content changes;
• use a maintenance/read-only window or a tested synchronization method to prevent conflicting writes;
• pause old scheduled jobs, queue workers and other data writers, including integrations where necessary;
• take the final backup and synchronize the remaining database changes and uploaded files;
• verify recent records and files on the destination;
• switch traffic and enable production integrations and background jobs on the intended environment only;
• reopen writes after the critical checks pass.

Visitors may still reach the old server through cached DNS. Keep that copy read-only, in maintenance mode or routing requests to the new system so it cannot collect separate orders or edits. Account for queued work and webhook retries so they are neither lost nor processed twice.

7. Write down the rollback procedure

Before cutover, record:

• the failures that trigger rollback, such as broken checkout or persistent server errors;
• who decides whether to fix the new environment or roll back;
• the previous DNS/CDN settings and exact steps to restore service;
• the time required for restoration and traffic changes;
• how jobs, integrations and write access will be switched back;
• how new orders, uploads and other changes received by the new server will be preserved.

Keeping the old host available is only part of a rollback plan. Once the new site accepts writes, its data may be newer than the old copy. Freeze writes and reconcile or restore those changes before reopening the old site; changing DNS back alone can lose data. Rehearse the procedure in an isolated environment where practical.

8. Test immediately after cutover

Test from more than one network/device if possible.

Verify:

• homepage and important internal pages;
• admin login;
• forms;
• checkout or booking flows;
• database writes;
• HTTPS;
• email send/receive;
• redirects;
• scheduled jobs;
• queue processing and webhook delivery;
• mobile layout;
• CDN content and cache invalidation;
• analytics collection;
• response times and application/server error logs.

Confirm requests are reaching the new environment. Check representative workflows against the old site's baseline, including a controlled order or booking where relevant.

For search visibility, verify:

• existing URL paths and expected HTTP status codes;
• canonical URLs and the sitemap use the production domain;
• production pages have no leftover preview authentication, unintended noindex directives or crawler blocks;
• preview URLs remain protected from indexing.

9. Monitor before retiring the old account

Do not cancel the old hosting the moment DNS changes. Agree on an observation period that covers DNS cache expiry and important business workflows, including scheduled tasks that may not run every day.

Retire the old service only when:

• traffic has moved and the old server no longer receives legitimate application requests that need handling;
• critical workflows and relevant scheduled jobs have passed;
• uptime, error rates and performance remain healthy through the observation period;
• automated backups on the new host are running and restoration has been verified;
• any mailbox synchronization is complete;
• the site owner has accepted the migration and the rollback window has closed.

Keep a final backup according to the agreed retention policy. Confirm that cancellation will not remove DNS or email services still in use, then remove obsolete access credentials and temporary migration accounts.

10. Document the new setup

Record:

• registrar;
• DNS provider;
• hosting provider;
• control panel URL;
• renewal responsibility;
• backup location, schedule, retention and restore procedure;
• who has administrative access;
• what monitoring is in place and who receives alerts;
• certificate renewal method;
• scheduled jobs and integration dependencies;
• cutover date, validation results and any remaining follow-up work.

That documentation makes the next migration much easier.