How to Migrate a Website to New Hosting Without Downtime

Overview

If you only remember one idea from this article, make it this: zero-downtime migration is mostly about preparation and cutover order, not luck. The safest process is to build the new environment first, test it privately, lower DNS TTL ahead of time, freeze changes during the final sync, and switch traffic only when the new host is fully ready.

For most sites, the migration has five phases:

1. Audit the current site: understand files, database, DNS, email, SSL, redirects, cron jobs, forms, and third-party integrations.
2. Prepare the new hosting: create the site, install the runtime you need, add SSL support, set up backups, and stage the destination.
3. Copy and test: migrate files and databases, fix configuration differences, and verify the site using a temporary URL, hosts file, or staging domain.
4. Cut over carefully: reduce DNS TTL in advance, pause content edits if needed, run a final data sync, and update DNS.
5. Monitor after launch: check logs, forms, transactions, redirects, search indexing signals, and mail flow before you cancel the old host.

This sequence works whether you use managed website hosting, a traditional control panel, or cloud hosting for websites. The exact buttons change from one provider to another, but the migration logic stays consistent.

Before you begin, gather this information:

• Current registrar and DNS provider
• Current hosting access: control panel, SFTP/SSH, database credentials
• Application details: CMS, PHP or runtime version, plugins, themes, server modules
• Email setup: where mail is hosted, current MX, SPF, DKIM, and DMARC records
• SSL method: provider SSL, custom certificate, or CDN-managed certificate
• Backup method and restore procedure
• Any hard-coded IP addresses, firewall allowlists, or API callbacks

If you need a refresher on the DNS side of the move, see How to Connect a Domain to Web Hosting: Step-by-Step DNS Guide and How Long DNS Changes Take to Propagate and How to Check Status.

Checklist by scenario

Use the scenario closest to your stack. The steps overlap, but the risk points differ.

Scenario 1: Static site or simple brochure site

This is usually the easiest migration because there is little or no changing data.

• Export or copy all site files.
• Upload files to the new host or redeploy from your repository.
• Confirm the document root is correct.
• Set up HTTPS on the new host before DNS cutover.
• Test navigation, contact forms, asset paths, and redirects.
• Update DNS records when the new copy is verified.
• Keep the old host active for a few days while caches expire.

Watch for: broken relative paths, missing redirects, blocked form delivery, and mixed content after SSL is enabled.

Scenario 2: WordPress or another database-driven CMS

This is the most common small business website hosting migration. The challenge is keeping files and database content in sync at cutover.

• Record the current PHP version, memory limits, cron behavior, caching setup, and permalink structure.
• Create a full backup of files and database.
• Provision the new environment with compatible runtime settings.
• Copy files and import the database.
• Update configuration files with the new database credentials.
• Search for environment-specific values such as site URL, upload paths, or cache settings.
• Test the migrated site privately before changing DNS.
• Lower DNS TTL ahead of migration day if your DNS provider allows it.
• At cutover, pause content changes, orders, or user submissions if necessary.
• Run a final database sync or delta migration.
• Switch DNS and verify the live site on the new host.

Watch for: serialized data issues, caching conflicts, plugin license restrictions, file permission problems, and cron jobs still running on the old server.

Scenario 3: Website builder to new hosting or new platform

If your site lives in a proprietary builder, migration may be less about copying files and more about rebuilding or exporting what the platform allows. This is where planning matters more than tooling.

• Check whether the builder supports export, domain transfer, or only domain pointing.
• Inventory every page, form, image, SEO field, redirect, and custom code block.
• Recreate templates and navigation on the destination platform.
• Manually copy metadata, structured content, and image alt text where export is limited.
• Rebuild forms and confirm notification delivery.
• Prepare redirects for any URL changes.
• Test mobile layout and performance before launch.

If you are deciding whether to stay in a builder or move to something more flexible, compare the tradeoffs in Best Website Platforms for Service Businesses Compared.

Scenario 4: Ecommerce or sites with frequent content changes

Stores, membership sites, booking systems, and active communities need extra care because data changes constantly.

• Map all changing data sources: orders, bookings, customer accounts, form leads, comments, inventory, and payment webhooks.
• Schedule migration during a lower-traffic window.
• Set a brief content freeze for administrative changes if possible.
• Place the old site into maintenance mode only for the shortest necessary final sync window.
• Validate payment gateway callbacks, transactional email, tax or shipping rules, and checkout flows on the new host.
• Confirm background jobs and queues run only in one environment after cutover.

Watch for: duplicate order processing, stock mismatches, webhook delivery to the old IP, and sessions invalidated by changed server configuration.

Scenario 5: Moving to managed or cloud hosting

If your goal is better performance, easier maintenance, or more predictable operations, the migration is also a chance to simplify your stack.

• Review what the new host manages for you: backups, SSL, patching, caching, CDN, firewall, staging, and monitoring.
• Remove duplicate plugins or services that the platform already replaces.
• Benchmark the current site so you can compare after migration.
• Confirm restore points exist before and after cutover.
• Document any changes to deployment workflow, Git integration, or team access.

For broader hosting evaluation, see Best Hosting for SEO: What Matters for Rankings, Speed, and Uptime and Web Hosting Pricing Comparison 2026: Entry, Renewal, SSL, Backups, and Migration Fees.

A practical migration runbook

Whatever your scenario, this sequence is reliable:

1. 7 to 3 days before cutover: lower TTL, take backups, inventory DNS, prepare the new host, and test the migrated copy privately.
2. 24 hours before cutover: confirm SSL, forms, redirects, cron jobs, mail records, robots settings, and analytics tags.
3. Migration window: pause content changes, run final sync, update DNS, purge caches, and verify the new origin.
4. First 2 hours after cutover: check homepage, key landing pages, login, forms, transactions, media, and server logs.
5. First 48 to 72 hours: monitor uptime, crawl errors, email, and traffic while keeping the old host online as a fallback.

What to double-check

This is the section many people skip, and it is where most post-launch surprises come from. Before and after the DNS switch, review these items deliberately.

DNS records, not just the main A record

• Root domain and www record
• MX records for business email with domain
• SPF, DKIM, and DMARC TXT records
• Subdomains such as blog, shop, app, help, or staging
• Verification records for search tools, email platforms, or SaaS products

If mail is hosted elsewhere, do not assume changing web hosting should change mail records. Many downtime stories are really email outages caused by incomplete DNS copying.

SSL and mixed content

• Confirm the certificate covers every hostname you use.
• Force HTTPS only after the certificate is active on the new host.
• Check for hard-coded http asset links in themes, templates, and old content.

Redirects and canonical signals

• Recreate important 301 redirects from the old host.
• Check canonical tags on templates and major pages.
• Verify the preferred hostname is consistent: www or non-www.
• Make sure robots.txt and noindex settings are correct in production.

After launch, a quick pass through your broader optimization list can help. See Website Builder SEO Checklist for New Sites.

Application behavior

• Login and password reset
• Forms and notification email
• Search, filtering, and dynamic pages
• Image uploads and file permissions
• Scheduled tasks, backups, and cache warming
• APIs, webhooks, maps, payment gateways, and CAPTCHA

Performance and caching

• Check cache headers and CDN behavior.
• Confirm compression and image delivery work as expected.
• Test from multiple networks or regions if performance matters to your audience.
• Measure a few key pages before and after so you can spot regressions.

Rollback readiness

A good migration plan includes a path back. Keep the old environment untouched long enough to recover if needed. That does not mean actively serving it forever; it means preserving a clean fallback until the new host is stable.

• Do not cancel the old hosting immediately.
• Keep a dated backup taken just before cutover.
• Document the old DNS values so you can revert quickly if necessary.

Common mistakes

Most migration failures are not dramatic technical impossibilities. They are small omissions that compound under time pressure.

1. Changing DNS before the site is truly ready

The new host should already serve a tested copy of the site over HTTPS before you point the domain at it. DNS should be the final switch, not the beginning of setup.

2. Forgetting email records

This is one of the most common mistakes during a move to new hosting. Web and mail are often separate services. Copy DNS carefully and verify mail flow after the cutover.

3. Migrating the first copy but skipping the final sync

For dynamic sites, the copy you made yesterday is already stale today. Comments, orders, leads, and content changes need a final sync plan.

4. Testing only the homepage

Always test the paths that matter: contact forms, checkout, login, blog posts, image uploads, thank-you pages, and any page tied to revenue or lead flow.

5. Leaving staging blocked settings in production

Temporary noindex directives, password protection, or development URLs can quietly reach production if the launch checklist is rushed.

6. Ignoring version differences

A site may fail on the new host because PHP, database engine, server modules, or file permissions differ. Compatibility notes taken during the audit save time later.

7. Running duplicate scheduled jobs

After cutover, disable cron jobs or workers on the old host if the new environment now handles them. Duplicate task execution can cause repeated emails, imports, or billing events.

8. Cancelling the old host too soon

Keep the old environment available until DNS settles, edge caches expire, and you have confirmed that backups and restore points on the new host actually work.

When to revisit

This checklist is most useful when treated as a living runbook. Revisit it whenever your stack, traffic, or operational risk changes.

Revisit before these moments

• Before seasonal peaks or campaign launches: avoid major migrations right before important traffic periods unless there is a clear operational reason.
• When changing platforms or workflows: a move from a website builder to WordPress, from shared to managed hosting, or from manual deployment to Git-based deployment changes the checklist.
• When adding new services: ecommerce, bookings, CRM forms, or business email with domain all add migration dependencies.
• When security posture changes: new SSL handling, WAF rules, CDN layers, or stricter access controls can alter launch steps.
• When performance becomes a priority: if your reason for moving is to improve website speed, revisit your baseline measurements and post-migration validation plan.

Your reusable pre-migration checklist

Bookmark or copy this into your project notes:

1. List all site components: files, database, DNS, email, SSL, redirects, cron jobs, integrations.
2. Lower DNS TTL ahead of migration day.
3. Create verified backups and know how to restore them.
4. Provision the new host with compatible settings.
5. Migrate files and database.
6. Test privately on the new host, including forms and critical paths.
7. Prepare a final sync plan for changing data.
8. Confirm DNS records beyond the website itself, especially mail.
9. Enable SSL and verify HTTPS behavior.
10. Cut over during a controlled window and monitor immediately.
11. Keep the old host live until the new environment is stable.

If your migration is part of a broader site refresh or relaunch, you may also want to review How to Launch a Small Business Website: Complete Checklist From Domain to Go Live. And if the move is part of a redesign for your service business or portfolio, these companion guides may help: How to Build a Freelance Portfolio Website That Wins Clients and One-Page Website vs Multi-Page Website: Which Should You Build?.

The practical takeaway is simple: a smooth website migration without downtime is less about finding a magic tool and more about following a repeatable sequence. Audit first, test before switching, move DNS last, and verify everything that lives around the site, not just the pages themselves.