The Complete Website Migration Checklist: Domains, DNS, Hosting, SSL, and Backups

Overview

A hosting migration changes several connected systems at once: website files, databases, domain records, certificates, email services, scheduled jobs, access credentials, and sometimes application configuration. Treating the move as a sequence of controlled checkpoints reduces the chance of downtime and makes rollback possible if a problem appears.

The safest approach is to separate the migration into four phases:

1. Discover: document the existing website, domain, DNS, email, integrations, and backup process.
2. Prepare: create the new hosting environment and confirm that the application can run there.
3. Switch: synchronize the latest content, update DNS, and verify SSL and email continuity.
4. Monitor: test the production site, watch logs and key metrics, and keep the old environment available until the move is proven stable.

Before changing anything, record the current DNS records and hosting configuration. Include the domain’s nameservers, A and AAAA records, CNAME records, MX records, TXT records, subdomains, redirects, and any verification records used by third-party services. A domain transfer is separate from a hosting migration: you can move a website to a new host while leaving the domain registered with the current registrar. Keeping those steps separate often makes troubleshooting easier.

If the new environment will support multiple sites, confirm how domains, document roots, databases, users, certificates, and backups are isolated. The guide How to Host Multiple Websites on One Server or Hosting Plan provides useful context for planning that arrangement. For teams that need a controlled validation area, review Staging vs Production Environments before beginning the cutover.

What to track

1. Website inventory

List every component that must move or be re-created. At minimum, track:

• Website files, uploaded media, themes, plugins, and custom code.
• Databases, database users, connection strings, and required database versions.
• Domain names, subdomains, aliases, redirects, and parked domains.
• Forms, payment integrations, analytics, search tools, APIs, webhooks, and other external services.
• Cron jobs, queues, background workers, server-side scripts, and scheduled publishing tasks.
• Application environment variables and secrets, stored securely rather than in a public document.

For WordPress hosting, include the wp-content directory, the database, the site URL settings, uploads, caching configuration, and any server rules in .htaccess or the hosting control panel. Do not assume that a file-only copy is sufficient; posts, users, settings, and orders generally live in the database.

2. DNS and domain records

Maintain a DNS change sheet with the record type, hostname, current value, intended new value, TTL, and owner. Pay particular attention to email records. MX records determine where mail is delivered, while SPF, DKIM, and DMARC records may be stored as TXT records. If email remains with a separate provider, do not replace those records with values supplied by the new web host unless that service is intentionally moving too.

Lowering DNS TTL before a planned cutover may help resolvers refresh records sooner, but TTL changes are not an instant switch for every visitor. Some resolvers and devices can retain cached information longer. Plan for a transition period in which the old and new environments may both receive traffic.

3. Backup and rollback status

Create at least one complete backup before migration and verify that it can be restored. A useful backup set includes website files, databases, DNS documentation, mail-related records, configuration files, and a list of scheduled tasks. Keep a copy outside the source server. Define the rollback decision in advance: for example, restore the previous DNS target if critical transactions fail, data is not synchronizing, or the new application cannot serve essential pages.

Use the Website Security Checklist for Hosting to review access control, malware scanning, firewall settings, and backup coverage before exposing the new host to production traffic.

4. SSL and application security

Confirm how the new host will issue, install, renew, and monitor the certificate. Test both the bare domain and the www hostname when both are in use. Check that HTTP redirects to HTTPS, that mixed-content warnings are absent, and that the certificate covers every required hostname. The article SSL Certificates Explained can help distinguish certificate options without assuming that every site needs the same configuration.

Cadence and checkpoints

Before migration

At least several days before the planned move, audit the current site and capture a baseline. Record representative page URLs, response behavior, form submissions, checkout or login flows, current redirects, and the status of backups. Confirm the new host supports the application’s runtime, extensions, database engine, storage needs, and traffic pattern. For a VPS or developer hosting environment, document firewall rules, SSH access, deployment steps, web server configuration, and process supervisors.

Build the new site without changing the public DNS. Use a staging URL, temporary hostname, hosts-file override, or access-controlled preview. Avoid indexing the preview and protect it with authentication where appropriate. Compare the new environment with the production baseline, including content, images, canonical URLs, robots directives, forms, and user permissions.

During the cutover

Schedule the switch during a period when the team can monitor it. If the site accepts orders, registrations, comments, uploads, or other changing data, place it in maintenance mode or pause writes for the final synchronization when practical. Copy the latest files and database, then verify timestamps or checksums for critical assets.

Update only the DNS records that need to change. Preserve email and verification records unless they are part of the migration. Confirm the new host answers correctly before switching traffic, then issue or activate SSL as soon as the domain resolves there. Keep the old account online and unchanged while DNS caches expire and the new environment is checked.

After launch

Run a defined smoke test immediately after the DNS change:

• Open the homepage, key landing pages, contact pages, and representative deep links.
• Submit forms and verify that messages reach the intended destination.
• Test login, password reset, search, uploads, checkout, and other business-critical actions.
• Check redirects, canonical tags, robots.txt, XML sitemaps, and error pages.
• Confirm HTTPS, certificate coverage, security headers, and absence of mixed content.
• Send and receive test email if mail delivery could be affected.
• Review application, web server, PHP, database, and security logs for new errors.

For performance-sensitive sites, compare the new setup with the original baseline rather than relying on a single page-load test. Review the Website Speed Checklist for Hosting for server response, caching, CDN, database, and image considerations. If a CDN is involved, purge or revalidate its cache only after the origin is confirmed to be correct; see CDN vs Web Hosting for the distinction between the two systems.

How to interpret changes

Not every post-migration difference indicates a failure, but unexplained changes deserve investigation. A sudden increase in 404 responses may point to missing files, altered URL rules, or an incomplete redirect map. A rise in 500 errors often requires checking runtime versions, permissions, environment variables, plugins, database connectivity, or server logs. Slow responses can result from cold caches, different resource limits, database configuration, or an application that is making requests to an unavailable service.

Separate DNS propagation effects from application problems. If some users reach the old host while others reach the new one, compare both environments and avoid editing content in only one location. This is especially important for sites with ongoing transactions. If email fails but the website works, inspect MX, SPF, DKIM, DMARC, and mail-provider settings rather than changing web records at random.

Use thresholds that reflect the site’s purpose. A brochure site may prioritize page availability, forms, and search visibility. An ecommerce site must also verify orders, payment callbacks, inventory updates, and confirmation email. A developer application may need API responses, queues, workers, and deployment hooks checked. Hosting uptime is useful context, but it does not replace endpoint and transaction monitoring; the guide What Is Good Hosting Uptime? explains why both views matter.

If the new host remains stable, do not delete the old environment immediately. Retain the rollback copy for a period appropriate to the site’s risk and backup policy, then remove old credentials, revoke temporary access, and confirm that backups now run from the new environment.

When to revisit

Keep this migration record as an operational document, not just a one-time checklist. Review it monthly or quarterly, and whenever a recurring data point changes. Revisit the DNS inventory after adding a subdomain, changing email providers, enabling a CDN, or connecting a new third-party service. Recheck SSL renewal, backup restoration, access permissions, scheduled jobs, and monitoring after hosting plan changes or major application updates.

Run a deeper migration-readiness review before a major launch, domain transfer, platform upgrade, redesign, or move between shared hosting, managed WordPress hosting, VPS hosting, and cloud hosting. If the control panel or server architecture changes, document the new deployment and recovery steps rather than assuming the old procedure still applies. The comparison of hosting control panels can help identify which administrative tasks need to be recreated.

For your next review, take these practical actions:

1. Export or record current DNS records and confirm who controls the domain registration account.
2. Restore a recent backup in a non-production location and document the result.
3. Test one critical user journey from start to finish, including email or webhook delivery.
4. Check certificate status, redirect behavior, logs, scheduled jobs, and storage usage.
5. Update the rollback plan, contact list, credentials inventory, and migration notes.

A migration is complete when the new host serves the right content, essential workflows work, DNS and email are accounted for, backups are recoverable, and the team knows how to respond if conditions change. Repeating those checks on a regular cadence turns a risky one-time move into a manageable part of website operations.