Website Migration Checklist: How to Move Hosts With Minimal Downtime

Overview

A good website migration checklist does two things: it reduces avoidable risk, and it gives you a clear order of operations. Most migration problems do not come from copying files. They come from missing dependencies, incomplete DNS records, untested redirects, expired SSL settings, unplanned email changes, or switching traffic before the new environment is ready.

If your goal is a site migration without downtime, think in phases rather than one big move:

• Audit the current setup: understand exactly what is live today.
• Build the destination: recreate the environment on the new host before sending traffic there.
• Sync content and data: move files, databases, media, and any dynamic content with care.
• Test privately: check the new host before public DNS changes.
• Cut over with control: update DNS at the right time and monitor closely.
• Keep rollback options: do not cancel the old host too early.

Before you start, separate three related but different actions:

• Hosting migration: moving the website from one host to another.
• Domain transfer: moving domain registration between registrars.
• DNS change: pointing the domain to a new hosting environment.

These do not have to happen together. In many cases, they should not. Keeping the domain at the current registrar while you complete the hosting migration is often simpler because it reduces the number of moving parts. If you also need to move the domain, treat that as a separate project and review a dedicated domain transfer checklist.

For readers managing WordPress launches or replatforming existing WordPress sites, the same rule applies: build and test first, then switch traffic. If you need help with DNS basics before cutover, see how to connect a domain to your hosting provider.

Checklist by scenario

Use the scenario that matches your setup, but keep the core migration sequence the same.

Scenario 1: Basic website transfer to a new host for a brochure or business site

This is the most common case: one domain, one site, limited dynamic data, and no complex app dependencies.

1. Inventory what exists now. Record the current host, registrar, DNS provider, nameservers, IP addresses, SSL method, CMS version, plugins or modules, cron jobs, redirects, forms, and email routing.
2. Confirm what the new host supports. Check PHP or runtime versions, database versions, control panel access, SSH/SFTP availability, SSL options, backup tools, and staging support. If panel differences matter, compare workflows before migration. A hosting control panel comparison can help if the new environment uses a different interface.
3. Take a complete backup. Export the database, copy site files, save configuration files, and keep an offline copy. Do not rely on a host's backup system alone.
4. Build the destination environment. Create the site on the new host, add the database, configure the app, and install SSL if possible.
5. Copy the site. Move files and import the database. Update connection settings such as database credentials or environment variables.
6. Preview without changing public DNS. Use a temporary URL, staging URL, local hosts file, or the new host's preview method to test the site privately.
7. Check forms, media, redirects, and contact paths. Test every high-value function rather than just the homepage.
8. Lower DNS TTL in advance if practical. If you control the DNS zone, reducing TTL ahead of time may help speed up the final cutover window. Do this well before the migration, not at the last minute.
9. Update DNS when ready. Change the necessary A record, CNAME, or nameserver settings only after validation is complete.
10. Monitor propagation and traffic. Watch for mixed responses while DNS changes spread. If you need a refresher, read DNS propagation explained.
11. Keep the old host live temporarily. Leave the previous environment in place until you are sure traffic, SSL, forms, and email-related functions are stable.

Scenario 2: WordPress hosting migration

WordPress is often straightforward to move, but the details matter. Theme settings, cached assets, serialized data, image paths, and plugin behavior can create subtle issues after migration.

1. Update and clean up first if appropriate. Remove unused plugins and themes, resolve known plugin errors, and document your current versions.
2. Export both files and database. WordPress needs the wp-content directory, core files if required, and the full database.
3. Check wp-config.php and environment settings. Update database credentials, salts if needed, table prefix assumptions, and any hardcoded URLs or custom constants.
4. Handle URL changes carefully. If the domain stays the same, this is simpler. If the domain or path changes, perform a safe search-and-replace method that understands serialized data.
5. Rebuild caching and performance settings. Clear plugin caches, server caches, CDN caches, and image optimization caches after import.
6. Validate permalinks and redirects. Visit key pages, posts, category archives, and custom post types. Save permalink settings if rewrite rules need to refresh.
7. Test logins, forms, search, checkout, and admin actions. A WordPress site can appear fine on the front end while admin tasks fail.
8. Confirm SSL and mixed-content behavior. If the new host provides free SSL hosting options, check certificate issuance timing and force HTTPS rules. See best free SSL hosting options for broader SSL context.
9. Freeze content during final sync if needed. If comments, orders, or submissions are changing often, set a content freeze window or plan a final database sync right before DNS cutover.

If you are choosing a destination platform as part of the project, your migration outcome will depend on fit as much as process. Teams moving from basic shared plans to managed WordPress or higher-performance infrastructure should compare hosting types carefully rather than only shopping for the cheapest option.

Scenario 3: Ecommerce or high-change site migration

Stores, membership sites, booking systems, and community platforms need more caution because data changes constantly.

1. Map all write activity. Identify where new data is created: orders, form submissions, user accounts, comments, inventory updates, support tickets, and API writes.
2. Schedule a low-traffic cutover window. Even a site migration without downtime benefits from a quieter period.
3. Plan a final sync strategy. You may need maintenance mode, a brief content freeze, or a database sync near cutover.
4. Test transactional email and payment integrations. Confirm order emails, SMTP, webhooks, tax tools, and payment callbacks in the new environment.
5. Verify cron jobs and scheduled tasks. Background jobs often break silently after migration.
6. Review file permissions and writable directories. Uploads, cache directories, sessions, and export folders must work on the new host.
7. Monitor logs during cutover. Watch access logs, PHP errors, application logs, and checkout behavior in real time.

Scenario 4: VPS, cloud, or developer-managed hosting migration

When you move website hosting to a VPS or cloud platform, the migration usually includes more infrastructure work: web server setup, firewall rules, package versions, and deployment automation.

1. Document the current stack. Record OS version, web server, database engine, language runtime, worker processes, queue services, caching layers, and container setup if used.
2. Recreate infrastructure as consistently as possible. Use scripts or configuration management where available instead of rebuilding manually from memory.
3. Review security rules early. Firewall access, SSH settings, fail2ban policies, WAF rules, and allowed outbound connections can affect application behavior.
4. Test backups and restore before launch. On self-managed systems, backup validation matters more than backup presence.
5. Benchmark after migration. A new VPS or cloud host may be faster, but only if caching, database tuning, and worker configuration are correct. Readers evaluating infrastructure options may also find best VPS hosting for developers useful.

Scenario 5: Migration where email is tied to the domain

Email is one of the most common sources of accidental disruption. Many site owners move the website and unintentionally break mail delivery because MX, SPF, DKIM, or related DNS records were not preserved.

1. Identify where email is hosted. It may be at the old host, a dedicated provider, or bundled with another service.
2. Export the entire DNS zone. Preserve MX, TXT, SPF, DKIM, DMARC, autodiscover, and any mail-related subdomains.
3. Avoid changing more than necessary. If email hosting is staying where it is, keep those records intact while only changing the records required for the website.
4. Test inbound and outbound mail after cutover. Send and receive messages from multiple accounts.
5. Review mailbox needs separately. If you are also changing providers, compare requirements against a dedicated email service rather than assuming web hosting email is sufficient. See best email hosting for small business domains for planning context.

What to double-check

This is the short list worth reviewing before you declare the migration complete.

• DNS records: A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC, and any verification records.
• SSL certificate status: certificate issued, correct hostname coverage, HTTPS redirect rules, and no mixed-content warnings.
• Canonical URLs and redirects: make sure www and non-www behavior is consistent, and legacy redirects still work.
• Database connectivity: no stale credentials, permission errors, or hardcoded localhost assumptions that do not fit the new host.
• Forms and notifications: contact forms, lead forms, password resets, and admin notifications reach the right inboxes.
• Uploads and media: image thumbnails, downloadable files, and writable upload directories function properly.
• Scheduled jobs: cron tasks, backup jobs, cache warmers, feeds, imports, and cleanup tasks run on the new server.
• Robots and indexing controls: staging noindex settings or password protection should not remain enabled on production.
• Performance basics: page caching, compression, image delivery, CDN behavior, and origin response time are all worth checking.
• Monitoring: enable website uptime monitoring, error alerts, and at least a basic manual smoke test list for the first 24 to 72 hours.

If your migration also includes a registrar change later, review domain renewal timing and transfer windows first. A rushed transfer near expiration adds unnecessary risk. For budgeting and planning, see how much a domain name really costs.

Common mistakes

Most failed hosting migration projects are not caused by one dramatic mistake. They are caused by small assumptions stacking up.

• Changing host, DNS, and registrar all at once. Separate projects are easier to test and easier to reverse.
• Skipping a full backup because the host offers migration help. A website migration service can be useful, but you still want your own recoverable copy.
• Ignoring email records. Website traffic may recover quickly, but broken email can go unnoticed for hours.
• Testing only the homepage. Always test forms, login, checkout, admin tasks, media, redirects, and search.
• Canceling the old host too early. Keep the prior service active until logs, SSL, and content updates are stable.
• Forgetting TTL timing. DNS changes do not become universal instantly, even if the update itself is correct.
• Leaving staging protections in place. Password prompts, noindex headers, and blocked assets can survive the move if you do not review them.
• Assuming better hosting automatically means better speed. Performance still depends on application tuning, caching, DNS setup, and image handling.
• Not documenting the original environment. Rollback is much harder if you do not know exactly what changed.

If you are still selecting where to move, a hosting comparison should go beyond headline pricing. Support quality, control panel fit, migration tooling, backup access, and DNS clarity often matter more during a real migration than promotional discounts.

When to revisit

This checklist is worth revisiting any time the inputs change, not just when you are actively moving a site. Review it before seasonal traffic spikes, before renewing or replacing hosting, when your CMS or stack changes significantly, or when you add services such as a CDN, new email hosting, staging workflows, or a separate DNS provider.

A practical routine looks like this:

1. Quarterly: confirm backups restore correctly, DNS records are documented, and monitoring alerts still reach the right team.
2. Before renewal season: review current host performance, support quality, renewal pricing, and migration options so you are not forced into a rushed decision.
3. Before major site changes: update your inventory of plugins, integrations, cron jobs, webhooks, and third-party dependencies.
4. Before launching on a new host: walk through this checklist from top to bottom and assign owners for DNS, app testing, content freeze decisions, and rollback.

If you want one action list to keep on hand, make it this:

• Document the current environment.
• Take independent backups.
• Build and test the new host privately.
• Preserve all DNS and email records.
• Switch traffic only after validation.
• Monitor closely after cutover.
• Keep rollback options until the move is clearly complete.

That sequence is the foundation of a reliable website transfer to a new host. Tools and hosting platforms will change, but disciplined preparation, careful DNS handling, and post-migration verification remain the difference between a smooth move and a preventable outage.