How to Migrate a Website to a New Host Without Downtime

Overview

A no-downtime migration depends on one principle: do all risky work before visitors are sent to the new host. In practice, that means building the new environment in parallel, syncing data, testing with preview methods, reducing DNS time-to-live in advance, and only then updating DNS or load balancer routing when the target is ready.

If you are planning a move from shared hosting to cloud hosting, from one VPS hosting provider to another, or from a legacy stack to managed WordPress hosting, the sequence matters more than the specific vendor. Most outages during a host change come from one of these issues:

• DNS changed too early
• Database content diverged between old and new hosts
• SSL certificates were not ready on the destination
• Email, cron jobs, caches, or background workers were overlooked
• The old host was cancelled before logs and traffic confirmed a clean cutover

Before you start, define the migration type. That helps you pick the right checklist:

• Static site migration: files, redirects, SSL, and DNS are the main concerns.
• CMS migration: files, database, config values, plugins or themes, media, admin access, and scheduled tasks.
• Ecommerce or application migration: sessions, payments, background jobs, transactional email, cache stores, and writable storage need special handling.
• Infrastructure migration: web server, database engine, PHP or runtime versions, container setup, firewall, monitoring, and deployment workflows.

A good migration plan also includes a clear fallback. If the new environment fails after cutover, you should be able to point traffic back, restore database consistency, and investigate without improvising.

If you are still deciding what kind of platform to move to, it helps to compare hosting models before touching production. See How to Choose Between Shared Hosting, VPS, Cloud Hosting, and Dedicated Servers and Best Web Hosting for Small Business Websites: Updated Comparison Guide.

Checklist by scenario

This section gives you a practical migration checklist by phase and by common hosting scenario. For most teams, the safest approach is to work through the general checklist first, then apply the scenario-specific notes.

Core migration checklist for any website

1. Inventory the current environment.
   Document the web server, runtime version, database engine, DNS provider, SSL method, scheduled tasks, email routing, CDN settings, backups, and third-party integrations. Note anything that writes data: forms, carts, user accounts, comments, APIs, and admin uploads.
2. Set migration success criteria.
   Decide what “done” means before you begin. Typical criteria include: site loads correctly, SSL works, admin login works, forms deliver properly, redirects behave as expected, background jobs run, uptime remains stable, and error logs show no new critical issues.
3. Lower DNS TTL ahead of time.
   If you plan to update A, AAAA, or CNAME records, lower TTL well before cutover so changes propagate faster later. If you need a refresher, review DNS Records Explained: A, AAAA, CNAME, MX, TXT, NS, and SRV and How to Point a Domain to Your Hosting Provider: DNS Records Step by Step.
4. Provision the new host in parallel.
   Do not replace the current host first. Build the destination separately with the correct runtime versions, security rules, file permissions, database access, and deployment tooling.
5. Take and verify backups.
   Create a full backup of files, databases, and configuration. If possible, test restoration on a non-production environment. A backup you have not restored is only a partial safety net.
6. Copy files and migrate the database.
   Move the codebase, uploads, assets, and database dump. Update configuration values such as database credentials, environment variables, path settings, and base URLs where needed.
7. Prepare SSL on the destination.
   Install or issue certificates before cutover if the hosting model allows it. Check whether your certificate flow depends on DNS validation, HTTP validation, or a provider-managed process.
8. Test privately before switching traffic.
   Use a temporary URL, hosts file override, preview domain, or staging access method to confirm the site works on the new host without public traffic. Test page rendering, admin access, forms, search, media, redirects, APIs, and error logging.
9. Freeze changes if needed.
   For dynamic sites, schedule a migration window and temporarily pause high-risk writes. For example, disable new content publishing, limit ecommerce catalog edits, or put selected admin actions on hold during the final sync.
10. Run a final sync.
    Re-copy changed files and export/import the latest database state so the destination is current right before cutover.
11. Update DNS or routing.
    Point the domain to the new host only after validation is complete. Keep the old host online during propagation.
12. Monitor both environments.
    Watch access logs, application logs, uptime checks, form submissions, and user reports. Confirm traffic is landing where expected.
13. Keep rollback available.
    Do not cancel the old web hosting account immediately. Wait until the site is stable and you have confidence that no essential service was missed.

Scenario: static site or brochure website

This is usually the lowest-risk path. The site may only need files, redirects, DNS, and SSL.

• Verify all assets load from the new environment, including fonts, images, and JavaScript bundles.
• Check absolute URLs and canonical tags.
• Rebuild compression and cache rules if the old host used custom server directives.
• Test redirects, especially if you are changing directory structure or moving from HTTP to HTTPS.
• Confirm your CDN or edge cache is attached to the new origin if you use one.

Scenario: WordPress migration

WordPress adds a few predictable failure points: serialized data, plugin behavior, scheduled tasks, media paths, and cache layers. If you are evaluating platforms before the move, read WordPress Hosting Checklist: What to Evaluate Before You Migrate and Managed WordPress Hosting vs Shared Hosting: Which Is Worth It?.

• Match PHP and database versions closely enough to avoid plugin or theme conflicts.
• Update site URL values carefully, especially if the database stores serialized content.
• Disable or clear page cache, object cache, and CDN cache during final validation to avoid misleading results.
• Test wp-cron or your server cron replacement.
• Check uploads, permalinks, media thumbnails, contact forms, transactional email, and admin login.
• Review file ownership and permissions after transfer.

Scenario: ecommerce or membership site

This is where “without downtime” usually means “without user-facing interruption,” not necessarily “without any operational freeze.” The challenge is preserving transactions and user state.

• Schedule the cutover during lower activity if possible.
• Minimize write activity during the final sync window.
• Test login, checkout, webhooks, payment gateway callbacks, tax or shipping integrations, and order notifications.
• Verify session storage and cache backends are configured correctly on the new host.
• Confirm background workers, queues, and scheduled jobs are not running twice on both old and new hosts after cutover.
• Pay attention to email deliverability for receipts and password resets.

Scenario: migration to cloud hosting or scalable hosting

When moving to cloud hosting, you may also be changing architecture: multiple instances, managed databases, object storage, or externalized caching.

• Separate persistent data from ephemeral compute where appropriate.
• Check firewall rules, private networking, and allowed database sources.
• Confirm autoscaling or load balancing does not break sticky sessions or file upload flows.
• Review logging, monitoring, and alerting before launch, not after.
• Estimate ongoing costs for storage, bandwidth, snapshots, and managed services. For planning, see Cloud Hosting Pricing Explained: Monthly Costs, Hidden Fees, and What to Watch.

Scenario: domain transfer versus hosting switch

Many teams conflate domain registration and hosting. They are separate tasks. You can switch web hosting without transferring domain registration at the same time, and in many cases that is simpler.

• If possible, keep the domain at the current registrar until hosting is stable.
• Update DNS records first, then consider registrar transfer later.
• Make sure you know where authoritative DNS is hosted before changing nameservers.
• If you are reconsidering registrar setup, review Domain Registrar Comparison: Pricing, WHOIS Privacy, Transfers, and Renewal Costs.

What to double-check

These are the items that most often decide whether a migration feels clean or chaotic. Even experienced teams skip one of them under time pressure.

DNS and propagation

• Are you changing individual records or nameservers?
• Was TTL lowered early enough to help during cutover?
• Did you preserve MX, TXT, and verification records for email and third-party services?
• Are IPv4 and IPv6 records both correct if you use them?

SSL and security

• Does the certificate cover the exact hostname set, including www or subdomains?
• Are HTTP-to-HTTPS redirects working without loops?
• Did firewall rules accidentally block legitimate traffic, webhooks, or admin IPs?
• Were security headers, WAF settings, and malware scanning tools re-applied on the new host?

Application behavior

• Do forms submit successfully and send mail to the right destination?
• Do search, filters, image uploads, and account actions work?
• Have hard-coded paths, base URLs, or environment variables been updated?
• Do scheduled jobs run once, on the correct server, at the intended times?

Performance and caching

• Is the new stack actually faster under realistic load, or just different?
• Did you rebuild page cache, opcode cache, object cache, and CDN settings appropriately?
• Are old assets still being served from stale cache after cutover?
• Does the origin behave well if the CDN is bypassed?

Monitoring and rollback

• Do uptime checks point to the correct host and expected URL paths?
• Are logs accessible on the new platform?
• Can you revert DNS or routing quickly if a critical issue appears?
• Did you keep the old host intact long enough to compare behavior?

For developer teams, this is also the moment to review deployment workflows. A migration often exposes hidden dependencies such as local-only build steps, manual secrets handling, or scripts tied to the old server. Use the move as a chance to standardize repeatable deployment, not just relocate the existing mess.

Common mistakes

You do not need a large outage to have a failed migration. A site can stay online and still break in ways that are expensive: silent form failures, missing orders, inconsistent sessions, or disappearing email. These are the mistakes most worth avoiding.

1. Treating DNS as the migration plan

DNS is the cutover mechanism, not the migration itself. If the new host is not fully tested, changing DNS only moves the problem into production.

2. Cancelling the old host too soon

Keep the old environment available until DNS has fully propagated, traffic has stabilized, and logs show the new host is healthy. This is especially important for cheap cloud hosting or budget web hosting plans where support may not help reconstruct a rushed rollback.

3. Forgetting background services

Cron jobs, workers, webhooks, search indexes, image processing, and external APIs are often omitted from server inventories. A site can look fine while key business processes fail in the background.

4. Overlooking email dependencies

When teams switch hosting, they sometimes break transactional email, mailbox routing, or domain verification records. Review MX and TXT records carefully and test outbound mail after cutover.

5. Migrating and redesigning at the same time

It is tempting to combine a host switch with a new theme, new plugins, or a URL restructure. That increases uncertainty. If possible, separate infrastructure migration from major site changes so troubleshooting stays simpler.

6. Ignoring performance baselines

“Fast web hosting” is hard to verify if you did not record before-and-after measurements. Capture a small baseline: response times for key pages, page weight, cache hit behavior, and basic server resource usage. That gives you a factual post-migration review.

7. No rollback procedure

A rollback is not just “change DNS back.” On dynamic sites, content may have changed after cutover. If you need to revert, know how you will handle database writes, orders, messages, and user actions that happened during the affected period.

8. Transferring the domain registration during the same critical window

Changing domain registration, authoritative DNS, and web hosting simultaneously adds avoidable complexity. In many cases, the safer path is to keep domain registration unchanged until the hosting move is proven stable.

If your long-term goal is to avoid repeating painful migrations, think about portability before your next purchase. An all-in-one stack can simplify operations, but it can also create lock-in. See The All‑in‑One Hosting Stack: Benefits, Risks, and How to Avoid Vendor Lock‑in.

When to revisit

This checklist becomes useful again whenever the underlying environment changes. Review it before you act, not after something breaks.

Revisit your migration plan when:

• You are moving from shared hosting to VPS hosting or cloud hosting
• You are changing DNS providers, nameservers, or domain registrar settings
• You are upgrading PHP, database versions, web server software, or framework versions
• You are adding a CDN, SSL provider change, WAF, or new caching layer
• You are preparing for seasonal traffic, product launches, or expected demand spikes
• You are redesigning the site and considering a host change at the same time
• Your deployment workflow changes from manual uploads to Git-based or CI/CD-based releases
• You need better uptime, security, or global server hosting coverage

A practical way to use this article is to turn it into a short pre-flight routine:

1. List every service tied to the site: web, database, DNS, SSL, email, CDN, jobs, storage, monitoring.
2. Decide what can be migrated in parallel and what must wait for cutover.
3. Lower TTL in advance if DNS changes are required.
4. Build and test the destination privately.
5. Schedule a final sync window and communicate any temporary admin freeze.
6. Switch traffic only after validation is complete.
7. Monitor, compare logs, and keep rollback available.
8. Only then retire the old host.

If you want one takeaway, it is this: website migration without downtime is mostly a planning discipline. The safest teams separate environment setup, data synchronization, and traffic cutover into distinct steps. That approach works whether you are switching to managed WordPress hosting, moving a business site to scalable hosting, or simply trying to get better support and more predictable uptime from your next web hosting provider.