Website Migration Checklist: Move Hosting Without Downtime

Overview

A good website migration checklist does two jobs at once: it reduces risk, and it creates a clear order of operations. The main idea is simple. Build and test the new environment before you point traffic at it, lower the chance of stale DNS and mismatched content, and keep the old host available until the new one is fully verified.

If you need a broader planning reference, see How to Launch a Website: Domain, Hosting, DNS, SSL, and Go-Live Checklist. If you are still comparing hosting models before the move, Shared Hosting vs VPS vs Cloud Hosting: Pros, Cons, and Upgrade Triggers and How to Choose Web Hosting Based on Traffic, Storage, and Growth Stage can help frame the decision.

Before you start, define the migration type. Most website moves fall into one of these buckets:

• Same site, new host: domain stays the same, infrastructure changes.
• Same application, new platform: for example, moving from shared hosting to cloud web hosting or managed hosting.
• Rebuild plus migration: content moves, but the site may also shift to a new CMS, website builder, or deployment workflow.
• Partial migration: the web app moves, but DNS, email, CDN, or databases remain elsewhere.

From there, work through these core phases:

1. Inventory: document everything attached to the current site.
2. Backup: take complete, restorable copies.
3. Provision: build the destination environment.
4. Test: validate site behavior before traffic shifts.
5. Cut over: update DNS and switch traffic carefully.
6. Verify: check functionality, performance, SSL, and logs.
7. Decommission: only after you are sure nothing still relies on the old setup.

That sequence is what makes hosting migration without downtime possible. Downtime usually comes from changing too many variables at once, skipping validation, or shutting down the old environment too early.

Checklist by scenario

Use the scenario that matches your move, then add the universal checks that follow. The goal is not to create a perfect migration plan on paper. It is to make sure you have covered the failure points that matter.

Universal pre-migration checklist

• List every domain and subdomain involved, including www and non-www versions.
• Export current DNS records: A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC, SRV, and any verification records.
• Document where DNS is hosted and who has access.
• Document the current hosting stack: web server, runtime version, database engine, cache layer, cron jobs, object storage, CDN, firewall, SSL method, and deployment process.
• Take a full file backup and a fresh database backup.
• Verify that backups can be restored, not just downloaded.
• Record current application settings, environment variables, API keys, and webhook destinations.
• Review traffic patterns and avoid cutover during your peak usage window.
• Lower DNS TTL in advance if your DNS provider allows it and if enough time remains before the migration window.
• Define a rollback plan: what triggers it, who approves it, and how long the old host will stay online.

Scenario 1: Move a standard CMS site to a new host

This is the most common case for small business website hosting and managed hosting migrations. The CMS might be WordPress, Drupal, Joomla, or another database-backed application.

• Create the new hosting environment with matching or compatible runtime versions.
• Import site files and database into staging first, not directly into production.
• Update application configuration for the new database credentials and file paths.
• Check media paths, uploads, and writable directories.
• Test login, forms, search, checkout, account flows, and admin access.
• Verify cron jobs, scheduled tasks, and background workers.
• Confirm caching behavior so you do not carry stale data into launch.
• Check redirects and canonical tags to preserve SEO signals.
• Issue or install SSL before DNS cutover if possible.
• During final sync, freeze content changes or set a short content blackout window.

If you are deciding whether to remain on a CMS, switch to a site builder for business, or move to managed hosting, see Website Builder vs WordPress vs Managed Hosting: Which Is Best for Launching a Business Site?.

Scenario 2: Move a static or custom-coded site

Static sites and custom apps are often simpler to move, but they can still break at the edges if environment assumptions are hidden.

• Export the build output or repository needed for deployment.
• Replicate the build pipeline, environment variables, and deployment hooks.
• Check asset paths, cache headers, redirects, and custom error pages.
• Verify any connected services such as forms, APIs, search, analytics, image optimization, and authentication.
• Test route handling for clean URLs and deep links.
• Confirm that the new host supports the required framework behavior.

For a broader look at site architecture tradeoffs, see Website Builder vs Custom-Coded Site: Cost, Control, and Maintenance.

Scenario 3: Move from one managed platform to another

Managed hosting reduces some operational burden, but migrations still need careful review because each platform handles DNS, backups, cache, SSL, and deployment differently.

• Review what the destination host manages automatically and what you still control manually.
• Confirm how backups are created and how restores work.
• Check whether the new host provides temporary URLs, staging, or host-file testing.
• Map any platform-specific features you currently rely on, such as image optimization, WAF rules, object cache, or one-click rollback.
• Recreate redirects, rewrite rules, scheduled jobs, and environment variables.
• Test email sending from the application, even if inbound email is hosted elsewhere.

Scenario 4: Domain stays the same, DNS cutover required

This is where downtime fears usually show up. In practice, the safest approach is to make the new environment fully ready first, then change as little as possible during the cutover window.

• Make sure the new server responds correctly before changing public DNS.
• Use a hosts file override, temporary domain, or staging URL to test the destination site.
• Prepare the exact DNS changes in advance.
• Identify whether you need to update only A or CNAME records, or whether nameservers are changing too.
• Do not mix unrelated DNS cleanup into the migration window.
• Keep the old host live during propagation.
• Monitor both old and new environments until traffic stabilizes.

For a deeper explanation of timing and verification, read How Long DNS Changes Take to Propagate and How to Check Them and How to Connect a Domain to Your Website Builder or Hosting Provider.

Scenario 5: Migration with email on the same domain

Email is often the part people forget. Your website may be fine while mail silently fails because MX or SPF records were changed incorrectly.

• Identify whether email is hosted with your current web host, a third-party provider, or a separate mail server.
• Export all current MX, SPF, DKIM, and DMARC records before touching DNS.
• Do not remove email-related DNS records unless you are intentionally changing mail providers.
• Test contact forms, transactional email, password reset messages, and mailbox delivery after cutover.
• Confirm that SMTP credentials or sending service settings match the new environment.

Final cutover checklist

• Pause content edits or set a maintenance window for admin users only.
• Run a final file and database sync if the site is dynamic.
• Clear application, server, and CDN caches.
• Update DNS records exactly as planned.
• Verify SSL issuance and forced HTTPS behavior.
• Test the live domain on multiple networks or DNS resolvers.
• Watch logs, error rates, uptime checks, and key user flows for at least the first several hours.
• Leave the old host intact until you are sure the migration is complete.

What to double-check

Even a strong site migration guide can miss small dependencies. This section is the safety net. If a migration goes sideways, the root cause is often in one of these details.

DNS and domain records

• Are the root domain and www both pointing where they should?
• Did you preserve MX, TXT, SPF, DKIM, and verification records?
• Are CDN, proxy, or firewall settings changing how requests reach the origin?
• If nameservers changed, did all required zone records move with them?

SSL and HTTPS

• Does the certificate cover every hostname you use?
• Are HTTP-to-HTTPS redirects working without loops?
• Are there mixed-content warnings from old asset URLs?
• Will renewal work automatically on the new platform?

If SSL is part of your migration risk list, the practical reference is SSL Certificate Setup Guide for Websites: Installation, Renewal, and Common Errors.

Application behavior

• Can users log in, submit forms, check out, and reset passwords?
• Do search, filters, uploads, and media rendering work?
• Are cron jobs and background tasks firing on schedule?
• Are external APIs, webhooks, and integrations still authenticating correctly?

SEO and content integrity

• Are title tags, canonical tags, robots directives, and sitemaps intact?
• Did redirects survive the move?
• Are internal links pointing to the correct hostnames?
• Did image URLs, structured data, and metadata remain consistent?

Hosting alone does not determine rankings, but migration errors can create avoidable SEO losses. For more on what matters operationally, see Best Hosting for SEO: What Actually Matters for Rankings.

Performance and security

• Are cache layers configured correctly for the new environment?
• Did file permissions, firewall rules, or access controls become too open or too restrictive?
• Are backups running on the new host?
• Are monitoring, alerts, and uptime checks pointed at the new environment?

When teams move to scalable web hosting or cloud web hosting, they sometimes focus on infrastructure and forget operational basics. The migration is not finished until backups, logging, and monitoring are confirmed in production.

Common mistakes

Most migration problems are not exotic. They come from skipped steps, unclear ownership, or assumptions that the new host works exactly like the old one.

Changing the DNS too early

Pointing the domain before the new environment is tested creates pressure and reduces your room to fix issues calmly. Treat DNS as the final switch, not the beginning of setup.

Not taking a final fresh backup

An old backup may not include recent orders, form submissions, content changes, or user data. Always take a fresh snapshot close to cutover.

Ignoring hidden dependencies

Sites often rely on external services that are easy to overlook: SMTP relays, payment webhooks, object storage, analytics, maps, single sign-on, or scheduled imports. Migrate the whole system, not just the visible pages.

Forgetting email DNS records

A common way to create an outage without noticing is to overwrite MX or TXT records during a website move. Keep website and email records separate in your planning.

Testing only the homepage

The homepage can look perfect while core workflows are broken. Always test forms, logged-in pages, admin actions, checkout paths, API calls, and search.

Turning off the old host immediately

Keep the old environment available until propagation settles and you are confident the new host is serving traffic correctly. This is one of the simplest ways to prevent downtime during a move website to new host project.

Skipping rollback planning

If the migration fails, you need more than a backup. You need a practical rollback path: restore point, DNS reversal plan, access credentials, and a time threshold for deciding to revert.

Not aligning the migration with the hosting model

Moving from shared hosting to cloud web hosting, or from self-managed to managed hosting, changes workflows. Deployment, caching, logging, and SSL may behave differently. Plan around the destination model, not the source model.

If you are evaluating platforms as part of the move, Best App Deployment Platforms for Small Teams offers a useful operational comparison mindset.

When to revisit

This checklist is most useful when you update it before a real move. Revisit it any time the underlying stack, workflows, or business risk changes.

• Before seasonal planning cycles: if traffic spikes are predictable, schedule migrations well away from high-risk periods and recheck DNS, backup, and rollback assumptions.
• When workflows or tools change: a new CDN, deployment pipeline, email provider, website builder with hosting, or security layer changes the migration path.
• When your site architecture changes: moving from a CMS to a site builder for business, or from a monolith to a service-based setup, requires a fresh inventory.
• When you add new domains or subdomains: each hostname adds SSL, DNS, and redirect considerations.
• When compliance or security expectations change: access controls, logging retention, and data handling may need new validation steps.

For practical use, turn this article into a living migration document. Before each hosting change:

1. Copy the checklist into your project tracker.
2. Assign an owner for DNS, hosting, application testing, and rollback approval.
3. Add the exact domains, records, services, and test cases for the current site.
4. Decide the migration window and freeze period.
5. Record the rollback threshold before cutover starts.
6. Do not close the project until post-move verification is complete.

A repeatable website migration checklist is less about perfection than discipline. When you know what you are moving, test the destination before the cutover, protect DNS and email records, and keep rollback available, you can migrate hosting with minimal risk and little to no downtime.