How to Migrate a Website to a New Host: Zero-Downtime Planning Checklist

Overview

If you want to switch web hosts without downtime, the key is to treat migration as an operations project rather than a single transfer task. Most failed website hosting migration projects do not fail because files cannot be copied. They fail because DNS was changed too early, email routing was overlooked, background jobs behaved differently on the new server, or the team had no rollback plan.

A reliable migration usually follows five phases:

1. Inventory the current site: know what exists before you touch anything.
2. Prepare the new host: build the target environment to match or improve on the old one.
3. Copy and test: migrate files, databases, configurations, and integrations without switching live traffic yet.
4. Cut over carefully: update DNS and routing only after the new host has passed checks.
5. Monitor and decommission: keep the old host available until stability is confirmed.

This approach works for small business websites, business web hosting migrations, and more complex developer hosting environments. It also applies whether domain registration stays with the current registrar or you later complete a separate domain transfer. If both hosting and the domain are changing, keep those projects separate whenever possible. Moving web hosting and changing domain registration controls at the same time adds avoidable risk.

Before you begin, define what “done” means. For most teams, success includes:

• No meaningful visitor downtime
• No lost orders, forms, or support messages
• No broken SSL warnings
• No missing media or database records
• No silent failure in cron jobs, email delivery, or API integrations
• Clear rollback options if something unexpected appears after cutover

If you are also evaluating providers, it helps to compare the target environment against your actual needs: traffic pattern, storage growth, database load, control panel preferences, support coverage, and expected uptime. Related planning articles on Best VPS Hosting for Developers and Growing Websites, Best WordPress Hosting for Speed, Security, and Easy Management, and What Is Good Hosting Uptime? can help you decide whether the new platform is actually an upgrade.

Checklist by scenario

Use this section as your working migration checklist. Start with the universal steps, then add the scenario-specific items that fit your stack.

Universal pre-migration checklist

1. Document the current environment.
   List your hosting plan, operating system if relevant, web server, PHP or runtime version, database version, control panel, SSL method, DNS provider, CDN, email hosting, scheduled tasks, firewall rules, and third-party integrations.
2. Identify what must be migrated.
   This usually includes website files, databases, media uploads, environment variables, application secrets, SSL certificates if manually managed, redirects, cron jobs, and server-level config.
3. Audit DNS records.
   Export or write down A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC, verification, and subdomain records. DNS management errors are a common source of downtime.
4. Confirm who controls domain and DNS.
   Do not assume your host also controls your domain registration. If they are separate, know exactly where DNS changes will be made.
5. Create full backups.
   Take fresh file and database backups before migration begins. Make sure backups can actually be restored. Keep one copy outside both the old and new host.
6. Lower DNS TTL if practical.
   Reducing TTL ahead of cutover can make DNS changes propagate faster later. This is not mandatory in every setup, but it is often useful when timing matters.
7. Prepare a rollback plan.
   Decide what triggers rollback, who makes the call, and how traffic will be returned to the old host if needed.
8. Schedule the cutover window.
   Choose a lower-traffic period, but make sure the right technical contacts are available. Quiet hours without support coverage can be worse than a busier time with the full team present.

Scenario 1: Shared hosting to shared hosting or business web hosting

This is common for small business sites, brochure sites, and lower-complexity CMS deployments.

1. Match PHP version, database compatibility, and file permissions.
2. Recreate email accounts if email hosting is bundled with the old host.
3. Copy website files via file manager, SSH, rsync, or migration tool.
4. Export and import the database, then update config files with the new database credentials.
5. Use a temporary URL, hosts file override, or staging domain to test the site before DNS changes.
6. Verify forms, transactional emails, redirects, and contact pages.
7. Reissue or install SSL if the new host uses a different certificate workflow.

Scenario 2: WordPress hosting migration

WordPress hosting moves are usually straightforward, but plugin behavior, caching, and serialized data can create subtle problems.

1. Put major content edits on hold during final sync, especially for stores or membership sites.
2. Inventory active plugins, themes, custom code, and server-side caching settings.
3. Check the destination host’s PHP limits, object caching options, and security rules.
4. Migrate uploads, themes, plugins, and the database.
5. Update wp-config.php and any hard-coded paths or environment values.
6. Search and replace old domain or path references carefully if the site structure changes.
7. Purge caches after migration and test logged-in and logged-out experiences separately.
8. Verify scheduled tasks, webhooks, WooCommerce checkout, and form submissions.

If speed is part of the reason for the move, pair your migration with a post-launch review using Website Speed Checklist for Hosting and How to Improve Website Hosting Performance.

Scenario 3: VPS hosting or cloud hosting migration

When you move site to a new server in a VPS hosting or cloud hosting setup, the task becomes more operational. You are not just copying a site; you are reproducing infrastructure behavior.

1. Define the target stack: Nginx or Apache, runtime versions, database engine, firewall, backup job, monitoring, and deployment workflow.
2. Automate where possible using scripts, configuration management, or deployment pipelines.
3. Create non-production validation first if the site is business-critical.
4. Rebuild users, SSH keys, sudo access, and least-privilege permissions.
5. Install observability tools before cutover so logs and metrics are available immediately.
6. Test worker processes, queues, cron jobs, and background services.
7. Review storage paths, mount points, and permissions for media or persistent data.
8. Benchmark the new server under expected load before you switch traffic.

Scenario 4: Host change with external services still attached

Many sites use a mix of vendors for DNS management, email hosting, CDN, SSL, and app services. These setups can support zero-downtime migration very well, but only if dependencies are tracked.

1. Confirm whether DNS will stay at the current provider or move later.
2. Leave MX records and email routing untouched unless email hosting is also changing.
3. Review CDN origin settings and firewall allowlists after the new server is ready.
4. Update any IP-based API restrictions, payment gateway allowlists, or webhook destinations.
5. Verify monitoring checks point to the right endpoint after cutover.

If your stack uses edge services, see CDN vs Web Hosting: What Each Does and When You Need Both for a clear separation of responsibilities.

Cutover checklist for near-zero downtime

1. Freeze non-essential content changes during final sync.
2. Take one last fresh backup on the old host.
3. Run a final file and database sync to the new host.
4. Validate the new host using a hosts file override, preview URL, staging domain, or load balancer target test.
5. Confirm SSL works on the live hostname before or immediately at cutover, depending on your certificate method.
6. Update DNS records to point traffic to the new host.
7. Watch server logs, uptime checks, application errors, and form submissions in real time.
8. Keep the old host active until traffic is stable and rollback is no longer likely.

What to double-check

This is where many migrations are won or lost. The site may appear to load, yet important functions can still be broken. Use the list below after staging tests and again after DNS cutover.

DNS and domain controls

• Authoritative nameservers are what you expect.
• The root domain and www both resolve correctly.
• Subdomains such as api, app, blog, or staging still work.
• MX, SPF, DKIM, and DMARC records were preserved if email hosting was not supposed to change.
• TTL values are reasonable after the move; increase them again later if you lowered them for migration.

If you also need to move domain registration later, handle that separately with a domain transfer plan such as How to Transfer a Domain Name Without Downtime.

Application behavior

• Forms submit and deliver messages.
• User login, password reset, and account creation flows work.
• Checkout, cart, and payment callbacks work for ecommerce.
• Search, uploads, media rendering, and dynamic pages behave normally.
• Scheduled tasks, queues, or background jobs continue processing.
• Redirects and canonical URLs are intact.

Security and compliance basics

• SSL certificates are valid and auto-renewal is set up where applicable.
• Backups are enabled on the new host and restoration steps are documented.
• Administrative accounts, SSH keys, and control panel access were reviewed.
• Unused services are disabled and old credentials rotated if necessary.
• Firewall and WAF rules are not blocking legitimate traffic.

For broader post-move validation, it is useful to compare the environment against a launch checklist such as Website Launch Checklist: Domain, Hosting, SSL, Email, DNS, and Backups.

Performance and reliability

• Page load times are at least comparable to the old host.
• Database response is stable under typical traffic.
• Caching is working as intended and not serving stale or mixed-content pages.
• Resource usage is within normal range on the new host.
• Monitoring, alerts, and uptime checks are live.

If the move was motivated by fast web hosting or reliable web hosting requirements, confirm that the new environment solves the original problem rather than simply relocating it.

Common mistakes

The easiest way to improve migration outcomes is to avoid a handful of repeatable mistakes.

Changing too many things at once

Do not change host, domain registration, DNS provider, email platform, CMS version, and site design in one project if you can avoid it. Separate infrastructure changes from application changes. Smaller moves are easier to test and reverse.

Skipping a real inventory

Teams often remember the website and database but forget cron jobs, SMTP settings, DNS TXT records, image processing libraries, webhooks, or API allowlists. A migration inventory should cover everything that keeps the site functioning, not just what renders in the browser.

Testing only the homepage

A site can appear healthy while checkout, search, dashboards, or admin tasks are broken. Test the top revenue paths, top support paths, and admin workflows, not just static pages.

Breaking email accidentally

If email hosting is tied to the old host, a DNS change can disrupt mail even when the website migration succeeds. Preserve MX and related TXT records unless you intentionally plan to move email at the same time.

Removing the old host too early

Keep the old account active through the validation period. DNS caches, delayed jobs, or overlooked dependencies can still reference the previous environment. Early cancellation removes your easiest fallback.

Ignoring SSL timing

If the certificate on the new host depends on DNS validation or live hostname resolution, plan for that before cutover. Browser warnings at launch undermine trust quickly, even if the rest of the migration is correct.

Not planning for content drift

Any live site can change between the first migration copy and the final cutover. Orders, comments, uploads, user registrations, and edits may continue to arrive. For dynamic sites, schedule a final sync or short content freeze to avoid missing recent changes.

When to revisit

This checklist is most useful when treated as a living operational document. Revisit it before any hosting change and also when the surrounding systems evolve.

Review and update your migration plan when:

• You are approaching a renewal decision with your current web hosting provider.
• Your site outgrows shared hosting and needs WordPress hosting, VPS hosting, or cloud hosting.
• You add a CDN, external DNS management, or separate email hosting.
• Your application stack changes version, framework, or deployment method.
• You launch ecommerce, membership features, or other data-sensitive workflows.
• Your compliance, backup, or uptime requirements become stricter.
• Seasonal traffic cycles are coming and you need infrastructure changes completed before they begin.

For a practical next step, create a one-page migration runbook from this article with four headings: Inventory, Dependencies, Cutover Steps, and Rollback. Fill it out before you open a new hosting account or touch DNS. Then assign owners for each step, schedule a validation window, and keep the old host online until the new platform has passed at least one full business cycle.

If the migration also includes domain decisions, use How to Choose a Domain Name for Your Business and Domain Registration Cost Guide for planning, but avoid bundling those decisions into the same cutover unless there is a clear reason.

The main lesson is simple: zero-downtime migration is rarely about speed. It is about sequence, testing, and restraint. Inventory first, validate before cutover, preserve rollback options, and separate domain and hosting changes when possible. Follow that discipline and your next website migration checklist becomes a repeatable process rather than a stressful one-off event.