Website Migration Checklist: Moving Hosts Without Downtime

Overview

If your goal is hosting migration without downtime, the core idea is simple: build the new environment first, test it thoroughly, and only then update DNS to send visitors to the new server. In practice, the details matter. A missed redirect rule, an overlooked cron job, or a forgotten MX record can turn an otherwise smooth move into a confusing incident.

This site migration guide focuses on five phases:

1. Inventory what exists now. Know exactly what you are moving: files, databases, DNS records, SSL setup, email routing, scheduled jobs, application dependencies, analytics tags, and any third-party integrations.
2. Prepare the destination host. Match runtime versions, storage structure, caching behavior, SSL requirements, and security settings before importing content.
3. Test privately before cutover. Validate the new site using a temporary URL, local hosts file override, or preview domain so you can catch issues before public traffic reaches the new host.
4. Cut over DNS deliberately. Lower TTL ahead of time when possible, update the right records, and monitor propagation and service health during the transition.
5. Keep a rollback option. Do not cancel the old host immediately. Leave it available until you are confident traffic, forms, logins, email, and background tasks work normally on the new platform.

It also helps to separate two related but different changes:

• Hosting migration: moving the website application and data to a new hosting provider.
• Domain transfer: moving domain registration between registrars.

You can do one without the other. If your site is moving but the domain registrar stays the same, the project is usually simpler because you only need DNS changes, not a registrar transfer. If you are doing both, treat them as separate workstreams. For registrar-side planning, see Domain Transfer Checklist: Requirements, Timelines, Fees, and Common Delays.

Before you move website to new host infrastructure, define success in operational terms:

• No meaningful visitor-facing downtime
• No data loss
• No email interruption
• SSL active at cutover
• Rollback available for a defined window

That framing keeps the migration grounded in reliability rather than speed.

Checklist by scenario

Use the base checklist first, then add the scenario-specific items that apply to your stack.

Base migration checklist for any website

1. Document the current environment.
   • Hosting provider and plan
   • Control panel or deployment method
   • Web server type
   • PHP, Node, Python, or other runtime versions
   • Database engine and version
   • File paths, storage locations, and media directories
   • DNS provider and current zone records
   • SSL certificate method
   • Email provider and MX records
2. Export backups before touching DNS.
   • Full site files backup
   • Database dump
   • Configuration files
   • Environment variables or secrets inventory
   • A copy stored outside both the old and new hosts
3. Lower DNS TTL in advance if practical.
   • Do this before cutover, not during it
   • Focus on the records you plan to change, usually A, AAAA, or CNAME
4. Provision the new host.
   • Create the site or application container
   • Match runtime requirements
   • Create the database and user permissions
   • Set up storage, backups, and access controls
5. Copy the website and import the database.
   • Preserve file permissions where needed
   • Update connection strings and application settings
   • Check absolute paths and URL references
6. Prepare SSL.
   • Confirm whether you need to reissue, reinstall, or newly generate a certificate
   • Make sure HTTPS can be enabled immediately after cutover
   • Review tradeoffs in Free SSL vs Paid SSL Certificates: Features, Support, and Renewal Tradeoffs and SSL Certificate Guide: DV vs OV vs EV and When Each Still Makes Sense
7. Test privately.
   • Load the homepage and key templates
   • Test logins, forms, search, checkout, and uploads if relevant
   • Check redirects, canonical tags, robots rules, and sitemaps
   • Review error logs and application logs
8. Plan a cutover window.
   • Avoid peak traffic periods
   • Notify internal stakeholders
   • Pause content changes if the site is database-driven and writes data frequently
9. Update DNS.
   • Change only the records required for the website
   • Leave email records alone unless email is also moving
   • Use a DNS propagation checker workflow if needed; see DNS Propagation Checker Guide: How Long DNS Changes Really Take
10. Monitor after cutover.
    • Confirm the new host is receiving traffic
    • Check uptime, response times, logs, and resource usage
    • Verify forms, transactional messages, and background jobs
11. Keep the old host live temporarily.
    • Do not decommission immediately
    • Maintain backups and access until the rollback window closes

Scenario: WordPress site migration

WordPress hosting moves are common, but they still break in familiar ways. Add these checks if you are migrating WordPress:

• Verify the destination host supports the required PHP version, memory limits, and database compatibility.
• Copy both the WordPress files and the database, not just one of them.
• Check wp-config.php for updated database credentials and any host-specific settings.
• Review hardcoded URLs in the database, theme settings, and page builder content.
• Re-save permalinks if routes or rewrite rules do not behave as expected.
• Test plugins tied to caching, security, backups, image optimization, forms, search, membership, and e-commerce.
• Clear old cache layers and ensure the new host cache does not serve stale content.
• Confirm scheduled tasks are running as expected if you depend on cron behavior.

If you are still deciding between a specialized WordPress environment and a more general cloud setup, compare tradeoffs in WordPress Hosting Comparison: Managed WordPress vs General Cloud Hosting.

Scenario: Static site or simple brochure website

A simpler site can still fail at launch if small details are missed. Add these steps:

• Check all asset paths, especially if the base URL changes.
• Confirm redirects from old pages still work.
• Validate contact forms or third-party form handlers.
• Review analytics tags, cookie banners, and consent tools.
• Test mobile rendering and performance after the move.

Scenario: Site with custom email domain on the same domain

Email is often the most fragile part of a migration because the website and mail may share a domain while living on different providers. If the hosting move does not include email migration, treat mail settings as protected infrastructure.

• Export the current DNS zone before making changes.
• Identify MX, SPF, DKIM, and DMARC records.
• Change only web-related DNS records during cutover.
• Re-check that MX records still point to the intended mail provider after edits.
• Confirm SPF and DKIM still align with your sending services.

For a deeper walkthrough, see How to Set Up Business Email on Your Domain: MX, SPF, DKIM, and DMARC and DMARC, SPF, and DKIM Checklist for Small Business Domains.

Scenario: Small business website with light operational risk

If the website supports lead generation, bookings, support requests, or local visibility, include a short business continuity checklist:

• Take screenshots of important pages before migration for quick comparison.
• Test phone links, maps, contact forms, and booking tools.
• Confirm local landing pages, schema markup, and indexability settings are unchanged.
• Make sure SSL warnings do not appear in browsers.
• Check that branded email addresses continue sending and receiving normally.

Scenario: Higher-change site or application with frequent writes

If users create content, submit orders, or update records frequently, plan for data consistency:

• Set a content freeze window if feasible.
• Schedule a final sync close to cutover.
• Know which data can be re-synced and which cannot.
• Communicate maintenance expectations internally, even if public downtime is not expected.
• Define the exact point at which the new host becomes the write source.

What to double-check

This is where most migrations are won or lost. Before and after DNS cutover, review these items deliberately.

DNS management details

• A, AAAA, and CNAME records: confirm the website points where you expect.
• WWW and apex domain behavior: make sure both resolve correctly and redirect consistently.
• TTL settings: lower before the move if needed, then raise later to a normal operational value.
• Unrelated records: do not accidentally overwrite MX, TXT, or verification records while editing the zone.

SSL and secure web hosting checks

• HTTPS loads without certificate warnings.
• HTTP redirects to HTTPS where appropriate.
• Mixed-content issues are not breaking assets on key pages.
• Certificate renewal is configured on the new host if automation is available.

Application behavior

• Admin login works.
• Password resets work.
• Forms send successfully.
• File uploads and media rendering work.
• Search, filtering, and checkout flows behave normally if present.
• Cron jobs, queues, and scheduled tasks run in the new environment.

Performance and observability

• Response times are reasonable under typical load.
• Error logs do not show repeated warnings after launch.
• Caching is enabled intentionally, not accidentally masking a problem.
• Monitoring, uptime alerts, and backup jobs are active on the new host.

SEO and launch hygiene

• The site is not blocked by a leftover noindex directive.
• Canonical tags reflect the production domain.
• Redirects preserve important URLs.
• XML sitemaps and robots rules are still valid.

Rollback readiness

• You still have access to the old host.
• You know which DNS records to revert if needed.
• You have a fresh backup from both environments.
• The team knows who approves a rollback decision.

Common mistakes

Most failed migrations are not caused by one dramatic error. They usually come from small assumptions that stack up.

• Changing too many things at once. A host move, registrar transfer, redesign, plugin replacement, and email migration in one weekend creates unnecessary ambiguity. Separate projects whenever possible.
• Skipping a full DNS export. If you do not capture the original zone, it becomes much harder to restore missing records quickly.
• Forgetting email records. Teams often update a domain and hosting setup for the site, then discover branded email stopped working because MX or TXT records were altered.
• Testing only the homepage. Real problems often appear on forms, account pages, media uploads, or less-visited templates.
• Assuming SSL will just follow the move. Certificates may need reissuance, reinstalling, or host-level reconfiguration.
• Ignoring background jobs. Scheduled tasks, webhooks, and API callbacks can silently fail even when the main site loads fine.
• Canceling the old host too early. Keep the previous environment available long enough to compare behavior and recover if necessary.
• Not accounting for propagation. DNS changes can appear inconsistent during transition. Plan for overlap instead of expecting every resolver to update immediately.
• Missing environment differences. A change in PHP modules, database version, file permissions, or rewrite behavior can break a previously stable site.
• No clear owner during cutover. Someone should be responsible for DNS, someone for application checks, and someone for business validation.

If you are still choosing where to move, it helps to compare hosting models before migration day. See Cloud Hosting Pricing Comparison: Shared vs VPS vs Managed Cloud Plans for a practical framework. And if your project includes registrar decisions as well as hosting, Best Domain Registrars Compared: Pricing, Renewal Rates, Privacy, and DNS Features offers useful context for DNS management and domain operations.

When to revisit

A good DNS cutover checklist is not a one-time document. Revisit and update it whenever the inputs change.

At minimum, review this migration playbook:

• Before seasonal planning cycles when traffic, campaigns, or operational risk are higher
• When workflows or tools change such as a new CI/CD process, control panel, CDN, security layer, or email provider
• After a hosting incident so lessons learned become part of the next migration runbook
• When your architecture changes for example, adding a staging environment, object storage, reverse proxy, or managed database
• Before a registrar or DNS provider change because DNS management processes often shift along with ownership and access controls

To make this article practical, turn it into a living preflight list for your team:

1. Create a migration template with fields for current host, new host, DNS provider, SSL method, and rollback owner.
2. Keep a standard export of DNS records, application settings, and backup locations.
3. Maintain a short test script covering homepage, login, forms, email, uploads, redirects, and HTTPS.
4. Schedule cutovers during lower-traffic windows and define a post-cutover monitoring period.
5. Do a short retrospective after each migration and add any missed checks to your next version.

That discipline matters whether you manage one brochure site or a fleet of business websites. The safest way to move website to new host infrastructure is not to rely on memory, but to reuse a checklist that reflects how your stack actually works.

If your hosting decisions are tied to broader operational risk, including provider concentration or regional dependencies, it is also worth reviewing Geopolitical & Supply Chain Risk Playbook for Domain Registrars and Hosting Providers. Migration planning is not only about launch day. It is part of long-term resilience for your domain and hosting setup.