Website Migration Checklist: Move Hosting Providers With Minimal Downtime

Overview

A clean website migration is usually less about one dramatic switch and more about sequencing. Most downtime happens when teams change too many things at once: a new server, new DNS, new SSL setup, new caching rules, and a fresh deployment process all in one move. The safer approach is to reduce variables, stage the environment in advance, validate it privately, and only then perform the public cutover.

Use this website migration checklist as a practical order of operations:

• Audit the current site: know what exists before you touch anything.
• Prepare the new host: provision the server, runtime, storage, and access controls.
• Copy site files and databases: migrate content before traffic moves.
• Recreate critical services: SSL, cron jobs, redirects, email-related DNS, backups, and monitoring.
• Test on a staging URL, hosts file override, or temporary domain: confirm behavior before DNS cutover.
• Lower DNS TTL where practical: shorten the cutover window ahead of time.
• Schedule a final sync: capture changes made since the initial copy.
• Update DNS or load balancer routing: direct users to the new host.
• Validate production: test pages, forms, checkout, APIs, and logs.
• Keep rollback ready: preserve the old environment until stability is confirmed.

If you are still deciding what type of target environment to use, it helps to settle that before migration planning begins. For that, see Cloud Hosting vs Shared Hosting vs VPS: Which Is Right for Your Site? and How Much Cloud Hosting Do You Need? CPU, RAM, Storage, and Bandwidth Guide.

One important principle: a hosting migration is not always the same as a domain transfer. You can move hosting providers while keeping domain registration and DNS management exactly where they are. In many cases that is the safest path, because it limits the number of systems changing on the same day.

Checklist by scenario

This section gives you reusable site migration steps by scenario. Start with the universal checklist, then apply the scenario-specific items that fit your stack.

Universal pre-migration checklist

• Inventory everything: domain names, subdomains, DNS zones, SSL certificates, origin IPs, CDN settings, databases, storage buckets, cron jobs, environment variables, firewall rules, and third-party integrations.
• Document current DNS management: note whether you use registrar DNS or managed DNS. If you need to switch providers, review Managed DNS vs Registrar DNS: Which Should You Use?.
• Export or snapshot the current environment: take file backups, database dumps, application config exports, and server snapshots where available.
• Record software versions: web server, PHP, Node.js, Python, database engine, extensions, and package versions. Version mismatches are a common source of migration problems.
• Lower TTL for relevant DNS records: do this well before cutover if your provider allows it. A shorter TTL can help your dns cutover website plan complete faster.
• Provision the new host: create the server, users, SSH keys, firewall policy, storage mounts, and backups before transferring any traffic.
• Install dependencies and recreate runtime settings: app secrets, workers, process manager, web server config, and scheduled jobs.
• Migrate content to the new host: copy site files, media, and database contents.
• Test privately: use a hosts file override, internal URL, or temporary subdomain to verify pages, admin login, API calls, uploads, and redirects.
• Create a rollback plan: define exactly how you will restore traffic to the old host if needed.

Scenario 1: Static website or marketing site

This is often the simplest case, but it still benefits from discipline.

• Confirm all assets are copied, including images, fonts, downloadable files, and favicons.
• Recreate redirects from the old host, especially any non-www to www or HTTP to HTTPS rules.
• Check compression, cache headers, and custom error pages.
• Validate forms, analytics scripts, consent banners, and tag manager snippets.
• Before cutover, compare page source on old and new environments to make sure tracking and meta tags are intact.

Scenario 2: CMS site with database, such as WordPress or similar platforms

• Export the database after taking the site inventory.
• Copy uploads, themes, plugins, and any custom configuration files.
• Update database connection settings on the new host.
• Search and replace old URLs only if required by your platform and migration method.
• Review file permissions and writable directories.
• Disable page cache during the first validation pass so you are testing the live application, not stale output.
• Confirm admin login, media uploads, forms, comments, and any ecommerce or membership flows.

Scenario 3: Ecommerce or any site with live transactions

This is where hosting migration without downtime requires extra control. The challenge is not just copying data; it is preserving changes made during the migration window.

• Schedule the move during a lower-traffic period if possible.
• Reduce change activity near cutover: pause catalog edits, content updates, or bulk imports if your business can accommodate it.
• Plan a final delta sync for orders, users, and inventory changes.
• Verify payment gateway callbacks, webhooks, and fraud tools on the new host.
• Confirm email sending for receipts and account notifications.
• Test tax, shipping, currency, and session persistence behavior.
• Keep the old host available until you confirm no late writes were missed.

Scenario 4: Custom app on cloud hosting or VPS hosting

• Replicate system packages, language runtime, and process manager settings.
• Copy environment variables securely rather than hard-coding them during deployment.
• Recreate queues, workers, scheduled jobs, and background services.
• Test health checks, logs, and restart policies.
• Confirm storage paths and permissions for uploaded content.
• Review outbound network rules for third-party APIs, SMTP, and webhooks.
• If moving to a new VPS hosting setup, confirm swap, disk space, CPU, RAM, and monitoring are adequate for current load.

If you need a sizing refresher before provisioning, revisit How Much Cloud Hosting Do You Need? CPU, RAM, Storage, and Bandwidth Guide.

Scenario 5: Site migration with DNS provider changes

Changing both hosting and DNS in one project adds risk, because troubleshooting becomes harder. If possible, move hosting first and DNS later. If you must do both, use a written checklist.

• Export the current DNS zone before making changes.
• Recreate all records at the new DNS provider: A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC, verification records, and any service-specific entries.
• Double-check records for email, because website launches often break mail flow indirectly.
• Compare nameservers and record contents before switching.
• Review Nameserver Change Guide: How to Switch DNS Providers Safely and How to Launch a Website on a New Domain Without Breaking Email.

Cutover checklist

• Freeze nonessential changes on the old host.
• Run final database sync or content sync.
• Put the old site into maintenance mode only if your application requires strict write consistency.
• Update DNS records or switch origin routing.
• Verify SSL on the new host.
• Watch logs, uptime checks, and error rates.
• Test from multiple networks if possible.
• Keep the previous host online during propagation and validation.

For practical DNS validation after cutover, see DNS Propagation Checker Guide: How Long DNS Changes Really Take and How to Point a Domain to a Server or Hosting Provider.

What to double-check

These are the items most likely to cause a migration to look successful on the surface while hiding operational issues underneath.

DNS records

Do not only verify the main A record. Confirm www, root domain, subdomains, API endpoints, mail records, and TXT verification entries. If the site sends or receives business-critical email, review MX, SPF, DKIM, and DMARC records carefully. A clean website migration can still cause email failures if DNS management is incomplete.

SSL and HTTPS behavior

Check that certificates are issued correctly for every hostname in use, including www and relevant subdomains. Test forced HTTPS, mixed content, HSTS behavior if enabled, and redirect loops. If you need a deeper walkthrough, read SSL Certificate Setup Guide for Domains and Subdomains.

Application configuration

Make sure environment variables, API keys, callback URLs, and database credentials point to the new environment. Applications often fail quietly when one leftover endpoint or secret still references the old host.

Database write behavior

For dynamic sites, validate that new writes land on the intended database after cutover. Create a test record, submit a form, place a sample order if appropriate, and verify the data appears where expected.

Scheduled tasks and background jobs

Cron jobs, queue workers, report generation, cleanup scripts, and renewal tasks are easy to overlook. Confirm not just that they exist, but that they run at the right interval with the right permissions.

Performance and caching

Test the site without relying on old cached responses. Clear application, CDN, and browser caches where needed. Then review response times, asset delivery, image optimization, and cache headers. A new host may be more capable than the old one, but only if the stack is configured correctly.

Backups and monitoring

Do not assume the new provider's defaults match your previous setup. Confirm backup frequency, retention, restore workflow, uptime checks, SSL expiration monitoring, and log access. Post-migration is the wrong time to discover backups were never enabled.

Common mistakes

If you want to avoid downtime, these are the mistakes to eliminate first.

• Changing too many variables at once: a redesign, replatform, DNS switch, and host migration in one release creates avoidable complexity.
• Skipping a rollback plan: every migration should include a clear path back, even if you do not expect to use it.
• Forgetting email-related DNS: website traffic may be fine while business email silently fails.
• Testing only the homepage: forms, checkout, admin areas, uploads, redirects, and API callbacks often reveal the real issues.
• Ignoring TTL timing: if you reduce TTL too late, the shorter value may not help the upcoming cutover.
• Migrating stale data: if there is a long gap between initial copy and final switch, you need a final sync strategy.
• Assuming SSL will configure itself perfectly: certificate issuance, redirect logic, and mixed content still need verification.
• Turning off the old host too soon: keep it available until you are confident traffic and writes have fully settled on the new host.
• Overlooking staging practices: a proper staging or preview method reduces production risk substantially. See How to Set Up Staging and Production Domains for a Website.

A useful rule is this: if the migration depends on memory, it is under-documented. Write down every step, even for a small site. That written sequence becomes your future website launch checklist and your rollback reference.

When to revisit

This checklist works best as a living document. Revisit it before any migration and update it whenever your stack or operational process changes.

Review and refresh the checklist in these situations:

• Before seasonal planning cycles: if your busiest period is approaching, confirm that your migration process reflects current DNS, SSL, backup, and monitoring practices.
• When workflows or tools change: a new CI/CD pipeline, DNS provider, CDN, mail service, or cloud hosting setup can alter the cutover sequence.
• When you add subdomains or services: dashboards, APIs, regional sites, and transactional email services introduce new DNS and SSL dependencies.
• After every completed migration: add notes on what broke, what was unclear, and what should be tested earlier next time.
• When domain ownership or registrar details change: if domain registration access has moved to another team member or provider, verify who controls nameservers and DNS management before a future cutover.

For the next move, keep this short action list at the top of your runbook:

1. Inventory current hosting, DNS, SSL, backups, and email dependencies.
2. Provision and test the new host before changing public traffic.
3. Lower TTL ahead of time if your cutover plan depends on it.
4. Run an initial copy, then a final sync close to cutover.
5. Validate the site privately, then switch DNS or routing.
6. Check logs, transactions, forms, SSL, and email after the switch.
7. Keep rollback available until the new environment is stable.

If you treat migration as an operational checklist instead of a one-time scramble, each future move becomes faster, safer, and easier to audit. That is the real goal: not just one successful cutover, but a repeatable process you can trust whenever you need to move hosting providers again.