Website Hosting Migration Checklist: Move Your Site Without Downtime

Overview

If you want a reliable website migration without downtime, the core idea is simple: do not replace the old site first and hope DNS catches up fast enough. Instead, run the new host in parallel, validate it carefully, then switch traffic only when you know the destination is ready.

This article gives you a reusable website hosting migration checklist for common scenarios. You can use it when you move website to a new host, change DNS providers, upgrade from shared hosting to managed cloud hosting, or split one site into separate services. The exact tools vary, but the sequence stays useful.

The migration model to follow:

• Prepare: document the current setup, dependencies, and rollback path.
• Replicate: build the destination host, copy files and data, and match key settings.
• Test: verify the site on the new host before the public cutover.
• Cut over: change DNS or routing in a controlled window.
• Observe: monitor logs, uptime, forms, transactions, and email after the switch.
• Decommission: retire the old host only after traffic, data, and background jobs are stable.

Before you touch anything, answer these five questions:

1. What exactly is being moved: static files, CMS, database, media, email, DNS, cron jobs, SSL, app server, or all of them?
2. What can break silently: contact forms, webhooks, logins, checkout, search, uploads, redirects, or scheduled tasks?
3. Who controls the domain and DNS?
4. How will you test the new environment before public traffic reaches it?
5. If the cutover fails, how will you roll back within minutes rather than hours?

If you are still evaluating infrastructure, it helps to clarify whether you actually need managed cloud hosting, a VPS, or a simpler platform. Related reading: Managed Hosting vs Shared Hosting vs VPS: Which Option Fits Your Website in 2026? and Best Cloud Hosting for Small Businesses: Features, Pricing, and Trade-Offs.

Checklist by scenario

Use the scenario closest to your move, then add the general items that apply to every migration.

Universal pre-migration checklist

• Create a full backup of files, databases, configuration, and media assets.
• Export DNS records before making changes.
• List all third-party integrations: CDN, email delivery, analytics, payment providers, webhooks, API keys, search services, and object storage.
• Document current versions: runtime, CMS, plugins, themes, database engine, caching layer, and server software.
• Lower DNS TTL ahead of the cutover if your DNS provider and timing allow it.
• Choose a migration window that avoids peak traffic and key campaigns.
• Notify stakeholders if content freezes or admin limitations will be needed.
• Set success criteria: homepage loads, login works, forms send, checkout completes, redirects resolve, SSL is valid, and no major errors appear in logs.
• Define rollback steps before starting the move.

Scenario 1: Static site or landing page migration

This is the simplest case, but static sites still break if DNS, redirects, or asset paths are mishandled.

1. Copy the built site output or repository to the new host.
2. Recreate environment-specific settings, including base URLs and asset paths.
3. Confirm redirects, custom headers, and caching rules are matched.
4. Test the site on a preview domain, temporary URL, or hosts-file override.
5. Verify images, scripts, fonts, favicons, and canonical URLs.
6. Check HTTPS on the destination before cutover if possible.
7. Switch DNS when the new site is fully validated.
8. Monitor for missing assets, redirect loops, or mixed-content warnings.

Scenario 2: CMS migration with database

This is the most common path for a small business hosting move. The challenge is not only copying content, but preserving settings, paths, media, and admin functionality.

1. Back up files and database separately.
2. Provision the destination with compatible versions of PHP, database engine, memory limits, and required extensions.
3. Copy application files, themes, plugins, uploads, and private assets.
4. Import the database into the new environment.
5. Update configuration values for database credentials and environment settings.
6. Search and replace old URLs carefully if the application requires it.
7. Disable indexing on staging or temporary URLs so test environments do not get crawled.
8. Test critical paths: homepage, navigation, search, forms, logins, media uploads, admin dashboard, checkout if applicable, and transactional email.
9. Pause content changes briefly before final sync if the site is active and writes to the database often.
10. Run a final database sync if needed, then cut over DNS.
11. Watch logs and error pages immediately after the switch.

Scenario 3: Application move to cloud website hosting

When moving an application from older hosting to cloud hosting or scalable hosting, you usually have more moving parts: application server, worker processes, queues, object storage, secrets, and background jobs.

1. Inventory all services, including app server, database, cache, queue, scheduled jobs, storage buckets, and email providers.
2. Recreate secrets and environment variables without copying expired or legacy values blindly.
3. Deploy the app to the new host and validate build and startup steps.
4. Run database migrations in a controlled order.
5. Verify worker processes and scheduled jobs separately from the web app.
6. Test file uploads, API callbacks, authentication flows, and session persistence.
7. Check firewall, allowed IPs, and outbound connectivity for third-party APIs.
8. If the app uses a separate database host, confirm latency and access policies.
9. Decide whether the final cutover needs a read-only window or brief maintenance mode for consistency.
10. Switch traffic only after application health checks pass.

Scenario 4: DNS-only or nameserver change

A DNS cutover looks small, but it can affect the website, email, subdomains, and verification records all at once.

1. Export every existing DNS record.
2. Recreate all records on the new DNS provider before changing nameservers.
3. Confirm A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC, verification, and redirect-related records are present.
4. Double-check root domain and www behavior.
5. Review TTL values and propagation expectations.
6. Change nameservers only after record parity is confirmed.
7. Test website resolution, mail flow, and subdomains after propagation begins.

Scenario 5: Email and website migration together

If possible, separate these changes. Combining them increases risk. But when they must move together, use an explicit checklist.

1. Document all mail-related DNS records before changing anything.
2. Confirm mailbox migration steps if user mail must be preserved.
3. Recreate MX, SPF, DKIM, and DMARC records exactly as required by the destination provider.
4. Test outbound and inbound mail from a noncritical account first.
5. Do not delete the old mail service until you have confirmed delivery, forwarding, and historical access where needed.
6. Monitor for soft failures such as messages landing in spam after the cutover.

Cutover checklist for any migration

• Freeze content updates if the site has active writes and no live sync strategy.
• Take one final backup.
• Complete a final data sync if applicable.
• Confirm SSL is ready or can be issued immediately on the destination.
• Update DNS records or nameservers.
• Purge or refresh caches where needed.
• Run smoke tests from multiple networks and devices.
• Monitor uptime, error logs, and user-reported issues for at least the first several hours.
• Keep the old host live until traffic and background tasks are stable.

What to double-check

This is where many hosting migration steps fail. The site may appear up, but a secondary function breaks quietly and is only discovered later.

DNS and routing

• Root domain and www both point where you expect.
• Subdomains such as blog, shop, app, or api still resolve correctly.
• There are no stale AAAA records sending IPv6 traffic to the wrong destination.
• CDN or proxy settings match the new origin.

SSL certificate setup

• The certificate covers every hostname that serves traffic.
• Auto-renewal is enabled where applicable.
• There are no mixed-content warnings caused by hard-coded HTTP assets.
• Redirects from HTTP to HTTPS are working without loops.

Application behavior

• Forms send successfully and confirmations arrive.
• Logins, password resets, and protected routes work.
• Uploads save correctly and are retrievable.
• Search and filtering still function after the database move.
• Scheduled tasks, webhooks, and queue workers are active.

Performance and caching

• Page caching is enabled where appropriate.
• Object cache or application cache is connected and healthy if used.
• Compression, image delivery, and static asset caching are active.
• There is no accidental cache of admin pages or checkout flows.

SEO and public-facing signals

• Canonical tags still point to the correct production domain.
• Robots directives were not copied from staging.
• Redirects from old URLs still work.
• Sitemap and feed URLs remain valid.

Monitoring and rollback readiness

• Uptime monitoring checks the production URL, not just the server IP.
• Application error logging is enabled.
• You still have access to the old host and old DNS settings.
• The rollback decision point is clear: what threshold of failure means you switch back?

Teams that want predictable costs during a move should also review how billing changes across providers, especially when a migration adds storage, bandwidth, backup, or managed support. See Cloud Hosting Pricing Guide: What You Actually Pay for Compute, Storage, Bandwidth, and Support.

Common mistakes

Most migration problems are not caused by the copy itself. They come from assumptions made under time pressure. These are the mistakes worth avoiding every time.

• Changing too many things at once. A host move, DNS change, design update, and plugin cleanup in one window makes troubleshooting harder. Keep the migration narrow when possible.
• Skipping a real test environment. A successful file transfer is not the same as a validated site. Test against a temporary URL or hosts-file mapping before public traffic moves.
• Forgetting non-web services. Cron jobs, form handlers, SMTP settings, webhooks, image processing, and worker processes often fail quietly.
• Not planning for live data changes. If orders, submissions, comments, or uploads continue during migration, you need a sync strategy or a brief freeze window.
• Cutting DNS before SSL is ready. Visitors may reach the new host before the certificate is active, causing browser warnings.
• Turning off the old host too early. DNS propagation, cached records, or delayed callbacks can continue to hit the old environment for a while.
• Missing email records during a DNS move. The website can look healthy while mail silently stops delivering.
• Ignoring staging leftovers. Noindex tags, placeholder analytics, debug settings, and test API keys often survive the move unless someone checks them intentionally.
• No rollback plan. Hoping to fix issues live is slower than a prepared rollback, especially for client-facing sites.

If you are migrating because your current setup has outgrown shared hosting, take the time to confirm the target platform actually fits your traffic patterns and operational needs. A move is a good moment to simplify, not just relocate complexity.

When to revisit

This checklist is worth revisiting whenever your infrastructure, traffic pattern, or deployment workflow changes. A migration process that worked for a static portfolio may not be enough for a transactional site, a multi-subdomain application, or a business that now depends on email deliverability and uptime monitoring.

Revisit this checklist:

• Before renewing or replacing your current hosting plan.
• Before seasonal traffic spikes or campaign launches.
• When changing DNS providers, CDN settings, or SSL handling.
• When moving from shared hosting to managed cloud hosting or another cloud website hosting platform.
• When your site gains a database, forms, checkout, memberships, or background jobs.
• When your team changes deployment tools or adds a staging workflow.
• After any incident where rollback was slower or harder than expected.

A practical pre-migration routine:

1. Open this checklist one week before the move.
2. Create a migration doc with owners, timeline, DNS records, credentials, and rollback steps.
3. Run a dry test on a nonproduction domain if possible.
4. Schedule the cutover during a low-risk window.
5. Keep the old environment live until logs, forms, transactions, and DNS behavior are stable.
6. After completion, save notes on what was missed so the next move gets easier.

The goal is not to make migrations dramatic. It is to make them routine. A calm, repeatable process is one of the simplest ways to improve uptime, reduce deployment risk, and move to better hosting without surprising your users.