Hosting Migration Checklist: How to Move a Website With Minimal Downtime

Overview

If your goal is a website migration without downtime, the real work happens before you switch anything public. Most hosting moves fail for predictable reasons: no verified backup, unclear DNS ownership, missing mail records, overlooked cron jobs, or a rushed cutover with no rollback plan. A good hosting migration checklist reduces risk by separating the project into clear stages.

At a high level, every migration follows the same path:

• Audit the current setup so you know exactly what must move.
• Prepare the new host with the right software versions, storage, SSL approach, and access.
• Copy files, databases, and configuration without changing live traffic yet.
• Test on a temporary URL, hosts file, staging domain, or preview environment.
• Lower DNS TTL in advance if you control the records and want faster cutover.
• Schedule the final sync and switch during a low-traffic window.
• Monitor carefully after launch and keep the old host available until you are confident.

This process applies whether you use shared hosting, VPS hosting, or cloud hosting for small business projects. If you are still deciding where to move, it helps to compare the destination type before you migrate. Related reading: Shared Hosting vs VPS vs Cloud Hosting: Which Upgrade Path Makes Sense?, Best Web Hosting for Small Business Websites Compared, and Best VPS Hosting for Developers and Growing Sites.

One more point matters early: your registrar and your hosting provider may be different companies. That is normal. A hosting move usually does not require a domain transfer. In many cases, you only need to update DNS management so the domain points to the new server. If that distinction is fuzzy, review How to Point a Domain to Web Hosting: Nameservers, A Records, and DNS Steps.

Use the checklist below as a preflight document. Save it, edit it, and mark each item off before you touch production DNS.

Checklist by scenario

This section gives you reusable site migration steps by type of move. Start with the universal checklist, then add the scenario that matches your setup.

Universal pre-migration checklist

• Document the current environment. Record hostnames, IP addresses, nameservers, DNS provider, control panel access, SSH or SFTP access, database versions, PHP or runtime versions, cron jobs, SSL details, CDN settings, and installed caching layers.
• List what must stay working during the move. Site pages, forms, checkout, login, APIs, webhooks, media files, redirects, and email.
• Confirm who controls the domain and DNS. Verify registrar login, DNS host login, and whether records are managed at the registrar, host, or a service such as Cloudflare.
• Export a full backup. Save site files, databases, configuration files, email-related DNS records, and any server-level settings you can access.
• Verify the backup. A backup is only useful if it opens, restores, or at least clearly contains the expected files and database dump.
• Reduce TTL on key DNS records ahead of time. If possible, lower it well before the cutover so record changes may propagate faster later. For background, see DNS Propagation Explained: How Long It Takes and How to Check Changes.
• Build the new hosting environment before the switch. Match software versions where needed to avoid compatibility issues.
• Create a rollback plan. Know exactly how to point traffic back, restore the old database state if needed, and who is responsible during the migration window.
• Schedule the cutover. Choose a low-traffic period and notify stakeholders if the site is important to sales, support, or internal operations.

Scenario 1: Moving a standard CMS site, including WordPress

This is the most common case for people who want to move a website to a new host. The risk usually comes from database sync, plugin behavior, hard-coded URLs, and caching.

• Check PHP and database version compatibility on the new host.
• Review disk usage and file count so you know how large the transfer will be.
• Export the database and copy the full web root, including hidden files such as configuration files.
• Update configuration values on the new host, such as database credentials and environment settings.
• If the CMS stores absolute URLs, prepare for a safe URL update after import.
• Disable or pause aggressive page caching, firewall rules, or maintenance plugins during testing if they interfere with preview access.
• Test admin login, forms, image loading, redirects, and permalink behavior.
• If the site processes frequent content updates, plan a final database sync close to cutover.

If your destination is WordPress-focused hosting, compare staging, backup, and support features before choosing the target. See Best Hosting for WordPress Sites: Speed, Backups, Staging, and Support Compared.

Scenario 2: Moving from shared hosting to VPS or cloud hosting

This move often improves control and performance, but it adds server responsibility. The key question is whether the new environment is managed well enough for your team.

• Confirm whether the new plan is managed or unmanaged.
• Recreate required services: web server, database server, PHP or runtime modules, backups, firewall rules, and monitoring.
• Check file ownership and permissions after transfer.
• Replicate cron jobs and scheduled tasks.
• Confirm log rotation, disk alerts, and backup retention policies.
• Test performance-sensitive pages and background jobs, not just the home page.

If you are deciding between cheap hosting with cPanel and a larger upgrade, these guides can help frame the move: Cheap Hosting With cPanel: What You Actually Get at Each Price Point and Shared Hosting vs VPS vs Cloud Hosting: Which Upgrade Path Makes Sense?.

Scenario 3: Moving a custom application or developer-managed site

Custom stacks bring more freedom and more places to miss something. Treat the move as an environment replication project, not just a file transfer.

• Document environment variables, secrets, API keys, and deployment scripts.
• Check language runtime versions, package dependencies, and build tools.
• Confirm worker processes, queues, and cache services such as Redis are set up correctly.
• Review webhook endpoints and IP allowlists that may need updating.
• Test background jobs, file uploads, and transactional email paths.
• Confirm that logs, monitoring, and alerting are active on the new system before cutover.

Scenario 4: Migrating when email uses the same domain

Email is often the most overlooked part of a hosting migration checklist. If your website and email share the same domain, a DNS mistake can interrupt mail even when the site itself works.

• Inventory all mail-related DNS records: MX, SPF, DKIM, and DMARC.
• Determine whether email is hosted with the old web host, a separate email provider, or a workspace suite.
• Before changing nameservers or DNS zones, copy every active DNS record, not just web records.
• After cutover, test inbound and outbound mail with the domain.
• Check web forms and transactional email tools separately from mailbox delivery.
• Keep screenshots or exports of the previous DNS zone in case you need to restore it quickly.

If you use Cloudflare or another DNS layer, verify that all mail records are carried over exactly. For setup patterns and common record issues, see Cloudflare DNS Setup Guide for Domains: Records, Proxying, SSL, and Common Errors.

Scenario 5: Using a hosting migration service

A hosting migration service can save time, but it does not remove the need for internal checks. Even if the new provider offers a free move, treat it as assisted execution, not blind automation.

• Ask what is included: files, databases, email, DNS help, SSL, testing, and rollback support.
• Clarify what you must provide: old host credentials, registrar access, CMS admin access, or SSH keys.
• Ask whether they migrate one-time data only or also perform a final sync close to launch.
• Confirm whether they update hard-coded URLs, configuration files, or cron jobs.
• Request a clear handoff note after completion, including anything they changed.
• Run your own post-migration checks anyway.

What to double-check

These are the items most likely to break after the switch. If you only have time for a short final review before changing DNS, start here.

DNS and domain settings

• Are you changing nameservers or only editing A, AAAA, or CNAME records?
• Did you preserve non-web records such as MX, TXT, verification, and SIP-related entries if applicable?
• Did you confirm the correct destination IP or hostname from the new host?
• Did you note the current values so you can roll back quickly?

If you need a refresher on DNS management basics during a move, review How to Point a Domain to Web Hosting.

SSL and HTTPS behavior

• Does the new host have a valid certificate ready for the domain and the www or non-www variant you use?
• Are redirects from HTTP to HTTPS working as intended?
• Are mixed-content warnings appearing because assets still load from old URLs?
• If a proxy or CDN sits in front of the host, are SSL modes and origin settings aligned?

Application functionality

• Test contact forms, checkout, search, login, password reset, and user registration.
• Check image paths, downloadable files, and embedded media.
• Verify redirects, canonical behavior, and custom error pages.
• Review robots.txt and noindex settings so a staging configuration does not leak into production.

Performance and caching

• Clear application cache, CDN cache, and server cache if you use them.
• Check whether object caching, compression, and image optimization still function normally.
• Load a few uncached pages from different locations if possible.

Email and transactional messages

• Send a test from a contact form.
• Send and receive messages through your domain mailbox if relevant.
• Check SPF, DKIM, and DMARC alignment after DNS changes.

Backups and monitoring

• Confirm backups are enabled on the new host and understand where they are stored.
• Set uptime or error monitoring before or immediately after launch.
• Keep the old host active until you have traffic, logs, and form submissions behaving normally.

Common mistakes

Most migration problems are not exotic. They come from rushing routine steps. Avoid these common mistakes if you want to move a website to a new host with minimal disruption.

• Changing DNS before testing the site. Always test privately first through a preview method, temporary domain, or local hosts file mapping.
• Forgetting email records. This is especially common when switching nameservers instead of editing a single web record.
• Relying on a backup without validating it. Corrupt or incomplete backups are discovered at the worst possible moment.
• Ignoring software version differences. A site that worked on one PHP version or database setup may fail on another.
• Skipping the final content sync. If the live site changes often, a backup from yesterday may already be outdated.
• Canceling the old host too early. Keep it available until DNS propagation settles and key business functions are confirmed.
• Not documenting the old DNS zone. Screenshots or exports save time during rollback.
• Leaving staging restrictions in place. Noindex headers, password prompts, or blocked resources can survive the move.
• Assuming a hosting migration service covers everything. Some services move site data but leave DNS, email, or application-specific tasks to you.
• Forgetting third-party integrations. Payment gateways, analytics, webhooks, maps, and external APIs may depend on specific URLs, IPs, or SSL behavior.

If domain ownership, privacy, or registrar access are part of the project, verify them before migration day. Delays often happen because the person moving the site does not control the domain account. If needed, review registrar-side basics such as Domain Privacy Protection Guide.

When to revisit

This checklist is most useful when you treat it as a living document. Revisit it whenever the underlying workflow changes, not just when a move is already underway.

Update or review the checklist in these situations:

• Before seasonal planning cycles. If traffic spikes at certain times of year, migration timing and rollback standards matter more.
• When you change hosts, DNS providers, or registrars. Even if the site stays put, the control path changes.
• When your application stack changes. New plugins, new framework versions, containers, or queue workers all add migration steps.
• When email handling changes. A move to a new mail provider should be reflected in your DNS copy checklist.
• When your backup or deployment workflow changes. Old instructions become risky very quickly.
• After every migration. Add what actually caused delay, confusion, or post-launch cleanup.

For the next move, use this short action plan:

1. Create a copy of this checklist for the specific site.
2. Fill in current DNS, hosting, email, and access details.
3. Choose the scenario that matches your move and add any application-specific tasks.
4. Lower TTL in advance if appropriate.
5. Take and verify backups.
6. Test the new host privately before any public DNS change.
7. Cut over during a low-risk window.
8. Monitor, verify, and keep the old environment available until stable.

A successful migration is usually not dramatic. It feels calm because the planning did the hard work upfront. If you want a cleaner process, keep this page as your default hosting migration checklist and revise it each time your stack, DNS management, or launch workflow changes.