Website Migration Checklist: Move Hosting Providers With Minimal Downtime

Overview

A good website migration checklist does two things at once: it reduces downtime during the cutover, and it reduces surprises after the cutover. Most migration issues do not come from the copy itself. They come from missed dependencies such as DNS records, email routing, background jobs, file permissions, TLS setup, caching rules, environment variables, or hardcoded URLs.

If your goal is to migrate hosting without downtime, think in phases rather than one big move:

• Audit the current site: know exactly what exists before touching production.
• Build the destination: match or intentionally improve the runtime, storage, networking, and security configuration.
• Sync and test: copy code, assets, databases, and settings; then validate the new host privately.
• Plan DNS carefully: lower TTL where possible, understand which records will change, and preserve email records.
• Cut over with a rollback path: switch traffic only when the new environment is verified and the old one remains available.
• Monitor after launch: watch logs, application errors, performance, forms, payments, and background tasks.

This article focuses on operational steps you can reuse whether you run a static site, a WordPress install, a custom application, or a small business site with email attached to the same domain. If you are still evaluating hosting models, it helps to compare platform fit before migration. See Shared Hosting vs VPS vs Cloud Hosting: Which Option Fits Your Site Now.

Before you begin, define success in plain terms. For example:

• No visible outage longer than a few minutes during DNS transition
• No loss of recent orders, form submissions, or user-generated content
• No breakage in email delivery for the domain
• No missing SSL coverage on public hostnames
• No post-migration decline in performance or search-critical pages

That framing keeps the migration grounded in outcomes, not just server access.

Checklist by scenario

Use the scenario that best matches your site, then layer on the universal checks underneath it.

Universal pre-migration checklist

• Inventory the current environment. Document the web server, PHP or runtime version, database engine and version, cron jobs, SSL method, file paths, redirects, firewall rules, cache layers, CDN settings, and third-party integrations.
• Export DNS records. Save the full zone or manually record A, AAAA, CNAME, MX, TXT, SRV, and verification records. This is especially important if your DNS host and web host are changing separately. For a refresher, review DNS Record Setup Guide: A, AAAA, CNAME, MX, TXT, SRV and When to Use Them.
• Check domain control. Confirm who controls the registrar, nameservers, and DNS provider. Hosting migration is easier when you know exactly where the authoritative changes will happen.
• Back up everything. Create restorable backups of files, databases, configuration, and if possible a snapshot of the current server or hosting account.
• Lower DNS TTL in advance. If you will change A, AAAA, or nameserver records, reduce TTL well before the cutover window so caches expire faster. Then verify the lower TTL is actually in effect.
• Freeze risky changes. Avoid theme updates, plugin installs, schema changes, or major application deployments right before migration.
• Prepare a rollback plan. Decide who can revert DNS, how long the old environment stays online, and what conditions trigger rollback.

Scenario 1: Static site or simple brochure site

This is usually the cleanest case when you move a website to a new host, but small details still matter.

• Copy files to the new host or deploy from version control.
• Recreate redirects, custom headers, cache rules, and compression settings.
• Test all paths, image assets, forms, and thank-you pages.
• Install SSL on the destination before DNS cutover.
• Update A or CNAME records only after the new site is verified.
• Keep the old site available until DNS propagation settles.

If the site uses a contact form, check the mail destination and SMTP settings rather than assuming the form will continue to work unchanged.

Scenario 2: Database-driven CMS, including WordPress

For CMS-based sites, the biggest risks are database consistency, plugin behavior, and hardcoded URLs.

• Export the database and copy uploads, themes, plugins, and configuration files.
• Match runtime requirements on the new host, including PHP version, memory limits, extensions, and database access.
• Update application configuration for the new database credentials.
• Search for hardcoded URLs or filesystem paths and replace them carefully.
• Test admin login, media library, forms, search, caching, image optimization, and scheduled tasks.
• Confirm that robots directives, indexing settings, and canonical behavior are correct in the staging or preview environment.

If your destination is a new WordPress platform, this companion resource can help before launch: WordPress Hosting Requirements Checklist: What You Need Before You Launch.

To reduce data loss during final cutover, consider a fresh database sync right before switching traffic, especially if the site receives comments, submissions, orders, or membership activity.

Scenario 3: Custom application on cloud web hosting

Cloud migrations add flexibility, but they also add moving parts. For developers, this is where a checklist matters most.

• Define infrastructure clearly: compute, storage, network rules, managed database, object storage, secrets handling, and deployment method.
• Set environment variables explicitly rather than relying on inherited server defaults.
• Verify worker processes, queue consumers, schedulers, and process managers.
• Review persistent storage needs. Do not assume local disk on one host behaves like another.
• Test outbound connectivity for APIs, payment gateways, SMTP relays, and webhooks.
• Confirm application logs, metrics, and alerts are working before cutover.
• Run database migrations with rollback notes, not just forward-only assumptions.

For many teams, the safest path is blue-green or parallel deployment: bring the new stack up fully, test it, then direct traffic to it with DNS or load balancer changes. That approach does not remove risk, but it narrows the cutover to a smaller and more observable step.

Scenario 4: Migrating a domain-linked business site with email

This is where migrations often go wrong. The website moves successfully, but email breaks because MX, SPF, DKIM, or verification records were overwritten.

• List every current email-related record before changing DNS.
• Preserve MX records unless the email provider is changing too.
• Keep SPF, DKIM, and domain verification TXT records intact unless they need intentional updates.
• Test sending and receiving from multiple mailboxes after the cutover.
• Warn internal users that DNS changes to the website should not automatically imply email changes.

If your migration also includes registrar or domain changes, use a separate checklist for that workstream: Domain Transfer Checklist: Move Your Domain Without Downtime or Email Breakage.

Cutover checklist for all scenarios

• Confirm the new site responds correctly over HTTPS.
• Verify the final content sync has completed.
• Pause or account for content changes during the cutover window.
• Update DNS records or point the domain to the new host.
• Use a propagation check workflow to watch public resolution. See DNS Propagation Explained: How Long Changes Take and How to Check Status.
• Monitor both old and new environments during transition.
• Do not cancel the old host immediately.

If you need a deeper walkthrough of domain routing, refer to How to Point a Domain to Your Hosting Provider: Complete Setup Guide.

What to double-check

This section covers the items most likely to cause a migration to look complete while still being incomplete.

DNS and nameservers

• Are you changing individual records or moving the whole DNS zone to a new provider?
• Did all non-web records carry over, including email, verification, and service-specific TXT records?
• Are IPv6 records present on the new host, and should they be?
• Are nameserver changes necessary at all, or can you leave DNS where it is for a simpler cutover?

Keeping DNS separate from hosting can make migrations easier because the website can move without changing the full zone. If you do migrate DNS, compare old and new records line by line.

SSL and redirects

• Is the SSL certificate active before public cutover?
• Do both apex and www hostnames resolve and redirect as intended?
• Are HTTP-to-HTTPS redirects in place and free of loops?
• Are staging domains or temporary URLs blocked from indexing?

Application behavior

• Do forms submit correctly?
• Do transactional emails still send?
• Do scheduled jobs run?
• Do uploads work with correct permissions and storage paths?
• Do payment, search, and API integrations work from the new IP or environment?

Performance and observability

• Is server-side caching configured correctly for the application?
• Are CDN settings still valid after origin changes?
• Are logs accessible and timestamped correctly?
• Do uptime checks and alerts point to the right domain and endpoints?

Security and access

• Have you rotated temporary credentials used during migration?
• Are least-privilege permissions restored after setup?
• Is directory listing disabled if it should be?
• Are firewalls, fail2ban-style controls, or WAF settings recreated where needed?

Website migrations are also a good time to review domain privacy, registrar access, and operational ownership. If that is in scope, see WHOIS Privacy and Domain Ownership: What Protection You Actually Get.

Common mistakes

Most failed migrations are not dramatic failures. They are partial failures that show up hours later. These are the mistakes worth guarding against.

• Switching DNS before the destination is truly ready. A homepage loading is not enough. Test admin paths, APIs, forms, redirects, SSL, and background tasks.
• Forgetting email records. This is one of the most common causes of post-migration disruption.
• Skipping TTL planning. If TTL remains high, your cutover can linger longer than expected across resolvers.
• Assuming the new host matches the old environment. Minor version differences, missing extensions, or changed defaults can break the app.
• Not planning for data written during migration. Orders, comments, or support tickets created during the final sync window can be lost if you do not account for them.
• Cancelling the old host too early. Leave it available until you are confident traffic, logs, and application behavior are stable.
• Using a temporary URL as a full test substitute. Some apps behave differently when the hostname changes, especially with cookies, sessions, and canonical rules.
• Ignoring cron jobs and workers. Sites can appear healthy while scheduled invoices, imports, or notifications quietly stop running.
• Forgetting hardcoded IPs or allowlists. External services may need the new outbound IP or origin IP added.
• Not documenting rollback. A rollback plan that exists only in someone’s head is not a plan.

A practical way to avoid these mistakes is to assign ownership before cutover: one person handles DNS, one handles application validation, one watches logs and metrics, and one approves rollback if needed. Even on a small team, explicit roles reduce hesitation during the critical window.

When to revisit

This checklist is worth revisiting whenever the underlying environment changes, not just when you are hours away from a migration.

Review and update it:

• Before seasonal planning cycles when you expect traffic changes or want to reduce infrastructure risk ahead of busy periods
• When workflows or tools change such as a new CI/CD pipeline, different DNS provider, new email service, or a move from shared hosting to cloud web hosting
• When the site adds complexity including memberships, ecommerce, APIs, background jobs, or multiple environments
• When domain and hosting ownership changes so access, billing, and DNS authority stay clear
• After any incident to improve the checklist based on what actually caused delay or downtime

For the next migration, keep a short operational runbook alongside this article. Include:

• The current production architecture
• The exact DNS records that matter
• Backup locations and restore steps
• Cutover commands or control panel actions
• Validation URLs and test accounts
• Rollback triggers and who approves them

If you want one final action list to copy into your task manager, use this:

1. Inventory environment, DNS, email, SSL, jobs, and integrations.
2. Back up files, database, and configuration in restorable form.
3. Build the destination to match or intentionally improve the stack.
4. Sync code and content, then test privately using the final hostname logic where possible.
5. Lower TTL before cutover and confirm the change.
6. Prepare rollback and keep the old host live.
7. Run the final sync for mutable data.
8. Update DNS or point the domain to hosting.
9. Verify HTTPS, redirects, forms, email, jobs, and critical user flows.
10. Monitor logs, uptime, and performance for at least the next day before closing the project.

A hosting migration does not need to be stressful, but it does need discipline. Treat it as an infrastructure change, not just a file copy, and your chances of a clean move go up considerably.