Website Migration Checklist for Moving Hosting Providers

Overview

A hosting move usually fails in predictable ways. Files are copied but configuration is missed. DNS is updated before the new server is ready. SSL is left for later. Email routing breaks because DNS records were not documented. Or the new host works for the homepage but not for forms, logins, scheduled tasks, or checkout.

A practical website migration checklist reduces that risk by turning a one-time project into a controlled sequence. The core idea is simple: inventory what exists, build and test the new environment, switch traffic carefully, and keep a rollback path until you are confident the move is complete.

Before you start, separate three layers that are often confused:

• Domain registration: who manages your domain ownership and renewals.
• DNS hosting: where your DNS records are controlled and how quickly updates are served.
• Web hosting: where your website files, database, and application runtime live.

You may change only one of these or all three at once. The more layers you change together, the more careful your plan should be. If your team is also reviewing how to transfer a domain without downtime, keep that workstream separate from the hosting move unless there is a clear reason to combine them.

Use this checklist in four phases:

1. Prepare: document the current state and reduce surprises.
2. Build: configure the new host to match production requirements.
3. Cut over: switch traffic in a controlled window.
4. Verify: confirm business-critical functions and keep rollback available.

If DNS performance is part of the reason for moving, review your DNS setup as its own decision. These guides can help frame that work: DNS Propagation Explained: How Long Changes Take and How to Check and Fast DNS Providers Compared for Business Websites.

Checklist by scenario

This section gives you a practical migration checklist you can reuse across common business scenarios. Start with the universal checklist, then add the scenario-specific items that fit your site.

Universal hosting migration checklist

• Define the scope. Confirm whether you are moving only web hosting, or also DNS hosting, email, CDN, domain registration, or SSL management.
• Set a migration owner. One person should coordinate the timeline, approvals, vendors, and final go/no-go decision.
• Create a full inventory. Record domains, subdomains, DNS records, databases, application versions, CMS plugins or modules, cron jobs, SSL certificates, forms, third-party integrations, firewall rules, and email-related records.
• Audit dependencies. Check payment gateways, CRM forms, SMTP services, analytics scripts, API connections, webhooks, search tools, and any IP allowlists.
• Take complete backups. Save website files, databases, configuration files, and a DNS zone export or manual record list. Store backups outside both the old and new hosts.
• Confirm restore access. A backup is only useful if you can restore it. Validate that the files are readable and the database export is usable.
• Review account access. Ensure you have working access to the registrar, DNS provider, old host, new host, CDN, SSL controls, and email provider.
• Lower DNS TTL in advance if appropriate. If you control DNS, reducing TTL before the cutover can make changes propagate faster. Do this well ahead of the migration window so the lower setting has time to take effect.
• Build the new hosting environment. Match required runtime versions, memory limits, file permissions, caching rules, firewall settings, and storage needs.
• Install SSL early. Prepare certificates before cutover so the site is ready to load securely as soon as traffic arrives.
• Copy files and data. Migrate the application, media, database, and environment-specific settings.
• Create a staging or preview method. Test on a temporary URL, host file override, or platform preview environment without exposing the unfinished site publicly.
• Test key user paths. Check homepage, navigation, forms, account login, search, checkout, image loading, page speed, structured redirects, and admin access.
• Plan content freeze if needed. For dynamic sites, define a brief period where new content, orders, or records are limited or carefully synchronized.
• Document rollback. Define what conditions trigger a rollback, who approves it, and how traffic returns to the old environment.
• Schedule a low-risk cutover window. Avoid your busiest hours, campaigns, launches, and seasonal peaks.
• Update DNS only when ready. Change the necessary A, AAAA, CNAME, or other records after the new site passes validation.
• Monitor both environments. Keep the old host active during propagation and early verification.
• Run post-cutover checks. Confirm SSL, redirects, forms, analytics, transactions, uptime, and log health.
• Decommission carefully. Cancel the old host only after you are certain traffic, data, and business functions are stable.

Scenario 1: Simple business website or brochure site

If the site is mostly static or lightly dynamic, the migration is usually straightforward, but basic mistakes can still cause downtime.

• Export all files and any CMS database.
• Check contact forms and form delivery addresses.
• Verify image paths, internal links, and 301 redirects.
• Confirm SSL is active on the new host before DNS cutover.
• Check mobile navigation, page templates, and thank-you pages.
• Revalidate analytics, tag manager, and cookie banner behavior after launch.

Scenario 2: Ecommerce or lead-generation site

These sites carry more business risk because forms, carts, or checkout may fail silently.

• Schedule the move outside high-conversion periods.
• Review payment gateway, tax, shipping, and transactional email settings.
• Test cart, checkout, account login, password reset, and confirmation emails.
• Check webhooks and API callbacks from payment or fulfillment systems.
• Plan order synchronization or a brief content and transaction freeze during final sync.
• Confirm inventory, customer records, and order history integrity after migration.

Scenario 3: WordPress or CMS-based site

CMS migrations often break because the platform moves, but plugin, theme, or cache assumptions do not.

• Record the exact application, theme, plugin, and PHP or runtime versions.
• Disable or carefully manage aggressive caching during testing.
• Update configuration values such as database credentials, salts, environment variables, and file paths.
• Check media library paths and writable directories.
• Test admin login, publishing workflow, search, forms, and scheduled tasks.
• Review security plugins or firewall tools that may block expected traffic on the new host.

Scenario 4: Custom application or server-level move

For more complex business web hosting environments, migration planning needs deeper technical review.

• Document runtime versions, package dependencies, containers, services, and background workers.
• Inventory environment variables, secrets handling, and deployment scripts.
• Replicate cron jobs, queue workers, and scheduled maintenance tasks.
• Check IP restrictions, firewall rules, and outbound mail or API permissions.
• Verify logging, uptime monitoring, and error alerting on the new host.
• Confirm database compatibility, replication settings, and backup retention.

Scenario 5: Moving hosting while keeping the same registrar and DNS provider

This is often the cleanest route because fewer systems change at once.

• Keep registrar settings untouched unless they are part of a separate cleanup project.
• Confirm DNS records at the existing provider before making changes.
• Prepare new server IPs or target records in advance.
• Update only the required website records during cutover.
• Leave MX, SPF, DKIM, and DMARC records alone unless email is also moving.

Scenario 6: Moving hosting and DNS together

This can be efficient, but it increases the chance of missing a record.

• Export or manually copy the full DNS zone before any changes.
• Recreate all records at the new DNS provider, not just website records.
• Check subdomains, verification records, TXT records, and mail-related records carefully.
• Confirm nameserver changes are entered correctly if DNS hosting is moving.
• Monitor propagation and service behavior during the overlap period.

What to double-check

Even well-run migrations usually have a short list of items that deserve a second pass. These checks catch issues that affect revenue, trust, and search visibility.

• DNS records: Validate A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC, and any verification records for third-party tools.
• SSL coverage: Check the main domain, www version, and any important subdomains. Look for mixed-content warnings after launch.
• Redirects: Make sure legacy URLs still resolve properly and redirect chains are not introduced.
• Email delivery: Test inbound and outbound messages if email is tied to the domain. This is especially important if DNS records were recreated by hand.
• Forms and notifications: Submit every important form and confirm the message arrives at the right inbox or CRM.
• Robots and indexing settings: Ensure staging restrictions, noindex tags, or password gates do not remain on the live environment.
• Canonical URLs: Confirm the live domain is set correctly so the site does not reference a staging address or temporary hostname.
• Analytics and conversion tracking: Check page views, events, thank-you pages, and conversion tracking after launch.
• Scheduled tasks: Reconfirm backups, cron jobs, feed imports, reports, invoice runs, or cache warmers.
• Performance basics: Test real pages, not just the homepage. Check image compression, caching behavior, and server response on priority pages.
• Security settings: Verify firewall rules, admin access restrictions, malware scanning, and backup schedules on the new platform.

If you are still comparing hosting options before making the switch, these related guides are useful reference points: Managed Hosting vs VPS vs Dedicated Server: Which Business Option Fits Best?, Best Web Hosting for Small Business Websites, and Business Hosting Cost Guide: What You’ll Really Pay Each Year.

Common mistakes

Most migration problems come from rushing the sequence rather than from any single technical issue. Watch for these common mistakes:

• Changing too many systems at once. Moving hosting, DNS, registrar, CDN, and email together can work, but it multiplies failure points.
• Skipping a real inventory. Teams remember the website and forget subdomains, TXT records, old redirects, cron jobs, or webhooks.
• Testing only the homepage. Problems often appear in search, checkout, logged-in areas, forms, and dynamic pages.
• Leaving no rollback path. Do not shut down the old host immediately after DNS changes.
• Forgetting mail records. Recreated DNS zones often omit MX, SPF, DKIM, or DMARC records, causing email disruption.
• Ignoring TTL and propagation timing. DNS changes may not appear instantly everywhere, which is why overlap planning matters.
• Using an incomplete backup strategy. Files alone are not enough if the site relies on a database or custom configuration.
• Letting staging settings leak into production. Temporary passwords, blocked crawlers, noindex tags, or hard-coded staging URLs can remain after launch.
• Canceling the old provider too soon. Wait until traffic, functionality, and records are stable over a reasonable observation window.

If domain ownership or registrar cleanup is part of the project, it helps to review domain governance separately with Business Domain Name Checklist: What to Buy, Protect, and Renew, Best Domain Registrars for Businesses in 2026, and Domain Renewal Pricing Comparison for Business Owners. If privacy settings are also under review, see Domain Privacy Protection for Business: When It Helps and When It Doesn’t.

When to revisit

This checklist is most useful when treated as a living operating document rather than a one-time article. Revisit it before any major infrastructure change and especially in the following situations:

• Before seasonal planning cycles. If your business has busy periods, review migration readiness well before them so you can avoid risky windows.
• When workflows or tools change. New CRM integrations, payment tools, email providers, or security layers create new dependencies that should be added to your checklist.
• When your hosting model changes. A move from shared hosting to managed hosting, VPS, or a dedicated environment often introduces new setup and monitoring tasks.
• When DNS or domain management is reorganized. Consolidating providers or changing nameservers is a good time to refresh records, ownership access, and documentation.
• When your site becomes more complex. Ecommerce, multilingual content, customer portals, and API-heavy systems all need a more detailed migration plan than a simple marketing site.

To make this article practical, keep a copy of the checklist in your internal documentation and add three fields every time you use it: owner, cutover time, and rollback trigger. That small discipline turns migration planning from a stressful one-off project into a repeatable business process.

Before your next move hosting providers project, do these five actions in order:

1. Create a complete inventory of hosting, DNS, email, SSL, and integrations.
2. Take and verify independent backups.
3. Build and test the new environment before changing DNS.
4. Cut over in a low-risk window with rollback still available.
5. Keep the old environment active until business-critical checks pass.

That sequence is simple, but it prevents most avoidable migration failures. If you use it consistently, your website transfer to a new host should feel controlled, documented, and far less risky.