Moving a website to a new host does not have to mean downtime, missing email, or lost search visibility. This reusable hosting migration checklist explains how to copy files and databases, compare DNS and mail records, test the new environment, switch traffic safely, and verify the result before cancelling the old service.
Overview
A hosting migration is more than downloading a website and uploading it somewhere else. A typical site may depend on application files, a database, scheduled tasks, environment variables, SSL certificates, DNS records, email services, analytics, redirects, backups, and third-party integrations. Missing one dependency can produce an outage even when the main pages appear to work.
The safest approach is a staged migration. Keep the existing host active while you build and test the new copy. Change DNS only after the new environment is ready, then retain the old service until you have confirmed that website traffic, forms, logins, transactions, and email are operating normally.
Before starting, document the current setup. Record the domain registrar, DNS provider, hosting account, database type, PHP or runtime version where relevant, SSL arrangement, email provider, CDN, analytics tools, cron jobs, redirects, and any external services connected to the site. If the domain and hosting are managed separately, do not assume that moving one automatically moves the other.
For domain ownership and DNS inventory work, the domain portfolio audit checklist and WHOIS and RDAP lookup guide provide useful preparation steps.
Checklist by scenario
Scenario 1: Moving a standard CMS or database-backed site
- Choose the target environment. Compare storage, bandwidth, database support, runtime versions, backup tools, staging features, SSL options, support access, and renewal pricing. A low introductory price is not enough if the new host lacks a feature your application requires.
- Create a complete backup. Export the database separately, download website files, and save configuration files. Keep at least one copy outside both hosting accounts. Include uploads, media, plugins, themes, custom scripts, and server configuration that affects redirects or caching.
- Record the current baseline. Test representative URLs, contact forms, login flows, checkout or booking paths, image loading, robots.txt, XML sitemaps, canonical tags, redirects, and analytics. Save a list of important URLs and note the current response behavior.
- Build the site on the new host. Create the database and user, import the database, upload files, and update connection settings. Match the required runtime and extensions as closely as possible. Protect the temporary copy from indexing with an appropriate staging method, such as access controls or a non-public environment.
- Test before DNS changes. Use the host's preview address, a temporary hostname, or a local hosts-file override. Check both public pages and administrative functions. Test on more than one device and browser where practical.
- Install and verify SSL. Confirm that HTTPS works on the real domain in the new environment and that HTTP requests redirect correctly. Check mixed-content warnings and confirm that the certificate process is understood before switching traffic.
- Lower DNS TTL before the move if appropriate. A shorter TTL may help resolvers request the updated record sooner, but it cannot guarantee instant worldwide change. Make the adjustment ahead of the migration through the authoritative DNS provider, then restore a sensible value after the move has stabilized.
- Switch DNS during a monitored window. Update only the records required for the website. Keep notes of the old values and the exact time of each change.
- Monitor both hosts. During propagation, some visitors may reach the old server while others reach the new one. Keep the old site available and avoid making content changes on only one copy.
Scenario 2: Moving a site while keeping email at the current provider
Website hosting and email hosting are separate services, even when one company supplies both. If email should remain where it is, preserve the existing mail records while changing only the web records. Before editing DNS, copy the complete zone and identify each record's purpose.
| Record | What to confirm | Migration implication |
|---|---|---|
| A or AAAA | Which server receives web traffic | Usually updated to the new host's address when applicable |
| CNAME | Whether a hostname points to another hostname | Check root, www, staging, and application subdomains |
| MX | Where incoming email is delivered | Do not change if mail remains with the current provider |
| TXT | Verification, SPF, and other service settings | Preserve required entries and check for duplicates |
| DKIM-related records | How outgoing mail is authenticated | Confirm selectors remain present if the mail provider is unchanged |
| DMARC | Policy and reporting destination | Preserve the policy unless you intentionally manage it during the move |
| CAA | Which certificate authorities may issue certificates | Check compatibility with the new host's SSL process |
Send test messages to and from more than one mailbox after the web change. Confirm delivery, replies, attachments, signatures, forwarding, and webmail access. If email is also moving, plan that as a separate workstream and allow time to recreate mailboxes, aliases, forwarding rules, and authentication settings.
Scenario 3: Moving a static site or application without a database
Static migrations are often simpler, but they still require a file inventory and DNS review. Confirm the build output, asset paths, redirects, custom headers, form endpoint, deployment process, and any server-side functions. A static site can look correct while forms, search, downloads, or analytics silently fail. Test the real domain over HTTPS before decommissioning the previous host.
Scenario 4: Moving a high-change store or publishing site
If content, orders, comments, accounts, or inventory change frequently, a simple one-time copy can lose data. Establish a content freeze, maintenance window, replication process, or final database export. Decide in advance which system is authoritative during the cutover. For an online store, verify payment callbacks, order notifications, shipping integrations, and tax or inventory connections before reopening normal activity.
What to double-check
Files, database, and configuration
- Compare file counts or directory inventories between the old and new hosts.
- Confirm that uploaded media and non-public storage were included.
- Check database character settings, table prefixes, users, permissions, and connection credentials.
- Move environment variables and secrets securely rather than placing them in public files.
- Recreate scheduled jobs, queues, webhooks, background workers, and server-side tasks.
- Confirm that caching, compression, image processing, and firewall rules are not blocking legitimate requests.
DNS and access
- Identify the authoritative nameservers before making changes. Editing records at the wrong provider will have no effect.
- Compare the complete DNS zone, not just the website's main A record.
- Check the root domain, www hostname, subdomains, API endpoints, and verification hostnames.
- Keep registrar access, DNS access, hosting access, and email-provider access available during the change.
- Use a DNS propagation checker as a diagnostic aid, but test from real networks as well. Resolver caches do not all update at the same time.
SEO and analytics
A host change should not require a new URL structure. Preserve page addresses, status codes, canonical tags, robots.txt, XML sitemaps, internal links, and redirect rules. If URLs must change as part of a redesign, map each old URL to its most relevant new destination and test the redirects separately from the hosting move.
Verify analytics tags, consent tools, Search Console or similar verification methods, structured data, image URLs, and server logs. Watch for accidental noindex directives or staging restrictions left behind on the production site. The goal is not to make search engines rediscover an entirely different website; it is to provide the same content and signals from a reliable new server.
Rollback readiness
Write down the rollback decision and procedure before cutover. Keep the old hosting account active, preserve the previous DNS values, and retain a current backup. If the new host has a serious defect, reverting the relevant web record may restore access while you investigate. A rollback is not a substitute for fixing the migration, but it limits the duration of an avoidable outage.
Common mistakes
- Cancelling the old host too early. Propagation, forgotten subdomains, and delayed discovery of mail or application problems can take time. Cancel only after the new environment has passed a defined observation period.
- Changing nameservers without copying the DNS zone. A new DNS provider may contain only the records created during setup. Missing MX, TXT, or verification records can interrupt services unrelated to the website.
- Testing only the homepage. Check representative templates, forms, logins, searches, downloads, checkout flows, and error pages.
- Forgetting SSL and redirects. Confirm HTTPS, the preferred hostname, HTTP-to-HTTPS behavior, and legacy URL redirects.
- Editing content during a long migration. New posts, comments, orders, or uploads can exist on the old copy but not the new one. Use a freeze or final synchronization plan.
- Assuming a migration tool handles everything. Automated tools can save time, but they may not copy DNS, email, cron jobs, external integrations, custom server rules, or hidden files.
- Judging performance immediately. Caching and DNS conditions may change after launch. Measure real tasks and error logs over an appropriate period rather than relying on one quick page load.
When to revisit
Revisit this checklist before every hosting migration, infrastructure upgrade, major redesign, domain move, or emergency recovery. It is also worth reviewing before seasonal planning cycles when traffic, orders, publishing volume, or support demands may increase. Hosting control panels, migration tools, SSL workflows, runtime versions, backup systems, and provider limitations can change, so confirm the current provider-specific steps instead of relying on an old screenshot or remembered menu.
When you are ready to act, use this short sequence: inventory the current setup; back up files and databases; copy the site; compare DNS and email records; test the new host privately; prepare rollback values; lower TTL only if useful; change the required web records; monitor both environments; verify forms, mail, SSL, redirects, analytics, and search controls; then cancel the old service only after the site has remained stable.
For related planning, compare the real cost of the old and new arrangements with the domain and hosting cost comparison, and review the domain and hosting setup checklist if the migration also includes a new domain or first-time website launch.
