How to Migrate a Website to a New Host: Complete Pre-Move Checklist

Overview

A website migration is rarely just a file copy. In most cases, you are moving several connected systems at once: website files, databases, DNS records, SSL, email, redirects, cron jobs, forms, analytics, and application settings. A good website migration guide starts with one principle: do not treat the new host as live until you have confirmed that the site works there.

If you want a simple way to think about the process, break it into five stages:

1. Audit the current setup. Identify what exists today, how it is connected, and what cannot be lost.

2. Prepare the new host. Set up hosting, software versions, access, staging, and security before moving anything.

3. Copy and test. Migrate files and databases, then test on a temporary URL, staging domain, or hosts-file preview.

4. Switch traffic carefully. Update DNS only when the new environment is confirmed ready.

5. Verify after launch. Check pages, forms, SSL, email, redirects, caching, logs, and search visibility.

Before you move website to new host, create a short migration record. Even for a small site, keep a document with:

• Current host and control panel login
• Registrar login and DNS provider login
• CMS admin login
• Database name and access details
• PHP or runtime version currently in use
• List of active plugins, themes, or extensions
• Cron jobs and scheduled tasks
• SSL method currently used
• Email provider and MX records
• Third-party services tied to the site, such as CDN, firewall, forms, SMTP, analytics, and backups

This one document prevents a lot of last-minute confusion. It also makes future migrations easier, which matters if you review hosts regularly or compare renewal costs over time. If you are still deciding whether to keep hosting and domain services together, see How to Buy a Domain and Hosting Together Without Overpaying.

Checklist by scenario

Use the checklist below based on the type of site you run. The core migration steps are similar, but the risk points change depending on your setup.

Checklist for any website

This is the universal hosting migration checklist. If you do nothing else, do these steps before you switch web hosting:

• Confirm why you are moving. Are you solving slow performance, support issues, missing features, poor uptime, or rising renewal pricing? Your reason helps you choose the right target host and testing criteria.
• Inventory the site. List every domain, subdomain, application, database, email mailbox, DNS record, SSL certificate, and scheduled task connected to the site.
• Download full backups. Keep at least one backup off the host. Ideally save website files, database exports, and a copy of DNS zone records.
• Lower DNS TTL in advance if practical. Do this before the move, not during it, so DNS changes can spread faster later.
• Check software compatibility. Compare the old and new hosting environments. Look at runtime version, database engine, memory limits, extensions, and server rules.
• Create the new hosting account before canceling the old one. Keep both active during the transition.
• Set up SSL on the new host. Plan whether you will use host-provided SSL, a CDN certificate, or another certificate option. For background, see Best Free and Paid SSL Options for Small Websites.
• Replicate DNS-related services. If email, verification records, or CDN settings depend on DNS, copy them carefully.
• Test before pointing the domain. Use a staging URL or preview method to confirm the site loads correctly.
• Schedule the cutover. Choose a lower-traffic period and avoid active promotions, launches, or major content updates.

Checklist to migrate WordPress site

To migrate WordPress site setups safely, add these WordPress-specific steps:

• Update WordPress, themes, and plugins cautiously before the move. If the site is already fragile, avoid stacking major updates on top of a migration. In some cases, migrating first and updating after validation is the safer path.
• Export both files and database. WordPress content lives in the database, while themes, plugins, and uploads live in files.
• Check serialized data and URL references. If the domain changes or the site uses hard-coded URLs, use a reliable search-and-replace method that handles serialized values properly.
• Review caching and security plugins. Clear caches, note firewall or login protection settings, and be prepared to reconfigure IP-based allowlists on the new server.
• Confirm file permissions. Incorrect ownership or permissions can break uploads, updates, or plugin behavior.
• Test permalinks. Open several posts and pages after migration to make sure clean URLs still work.
• Check media paths. Broken images often point to incomplete uploads, incorrect file paths, or mixed-content issues.
• Reconfigure backup plugins if needed. Some backup destinations and server paths change after migration.

If you are comparing hosts before the move, see Best WordPress Hosting for Beginners, Bloggers, and Small Stores.

Checklist for ecommerce or lead-generation sites

Sites that process orders, bookings, or leads need extra care because data can change minute by minute.

• Freeze major site changes before migration. Avoid theme edits, plugin installs, and catalog updates during the final move window.
• Review payment gateway settings. Check callbacks, webhooks, firewall rules, and SSL requirements.
• Confirm transactional email delivery. Test order emails, contact forms, and SMTP configuration after launch.
• Plan for final data sync. If orders or leads continue to arrive while you prepare the new server, decide how you will capture the latest data before cutover.
• Test checkout or form submission on the new environment. Do not assume a homepage test is enough.
• Verify redirects and thank-you pages. Broken post-conversion pages affect tracking and user trust.

Checklist for sites with separate email hosting or complex DNS

Many problems during a move come from DNS rather than the website itself. If your domain, hosting, and email are split across providers, slow down and map every record.

• Export or copy all existing DNS records. That includes A, CNAME, MX, TXT, SPF, DKIM, DMARC, verification records, and subdomains.
• Decide whether you are changing nameservers or only specific records. A full nameserver switch is broader and easier to get wrong if records are missing.
• Protect email first. If business email runs elsewhere, preserve MX and related TXT records exactly. For provider context, see Business Email Hosting Compared: Google Workspace, Microsoft 365, Zoho, and More.
• Document the current DNS zone before edits. Screenshots are helpful, but a text record is easier to reuse.
• Check propagation expectations. Some visitors may reach the old host for a while after DNS changes, which is why both accounts should stay active temporarily.

For deeper DNS help, read DNS Records Explained: A, CNAME, MX, TXT, NS, and When to Use Them and How to Point a Domain to Your Host, Website Builder, or Store.

What to double-check

Once the site is copied to the new host, the job is not finished. This is the quality-control stage that prevents avoidable outages.

Before DNS cutover

• Homepage and key templates load correctly. Check the homepage, top service pages, blog posts, category pages, and contact page.
• Internal links work. Click through menus, buttons, and footer links.
• Forms submit and deliver email. Test contact, quote, newsletter, booking, and checkout forms.
• SSL loads properly. Make sure the certificate is active and there are no mixed-content warnings.
• Admin login works. Confirm you can log in to the CMS and save changes.
• Media files display. Check image-heavy pages and downloadable files.
• Redirects still work. If you use manual redirects or rewrite rules, test them now.
• Robots and indexing settings are correct. A staging noindex setting accidentally left live can affect search visibility.
• Cron jobs or scheduled tasks run. This matters for backups, publishing, cleanups, and ecommerce background tasks.

Immediately after DNS cutover

• Monitor both hosts. Keep the old host active long enough to catch straggling traffic and compare logs if needed.
• Retest forms, checkout, and logins. These fail more often than static pages.
• Check canonical tags and sitemap access. These should reflect the live domain and preferred URL format.
• Verify analytics and tracking. Traffic drops are easier to diagnose when tracking still works.
• Watch for 404s and 500s. Server logs and crawl tools can reveal hidden issues.
• Confirm caching behavior. Purge server, plugin, or CDN caches so visitors see the new environment.

A useful final review is to compare the old and new environments side by side: number of pages, media folder size, active plugins, important DNS records, SSL status, and email routing. Simple comparisons catch missing pieces fast.

Common mistakes

Most migration problems are not caused by the move itself. They come from skipped documentation, rushed DNS edits, or assumptions that one copied component includes everything else.

• Canceling the old host too early. Keep the old account live until you have confirmed the new server is stable and DNS has fully shifted for your users.
• Forgetting email dependencies. Website traffic may move cleanly while mail stops because MX, SPF, DKIM, or SMTP settings were overlooked.
• Changing too many variables at once. A host move, redesign, plugin update, and domain change at the same time makes troubleshooting harder.
• Skipping a manual backup because the host says it has backups. Host backups are useful, but you still want your own copy before a major change.
• Testing only the homepage. Important issues often appear on forms, dynamic pages, logged-in areas, search pages, or checkout.
• Ignoring PHP or software version changes. A new host may use newer defaults that expose compatibility issues.
• Overwriting DNS records during a nameserver switch. This is one of the easiest ways to break email, verifications, or subdomains.
• Not documenting custom rules. Redirects, .htaccess changes, Nginx rules, firewall exceptions, and cron jobs are often missed because they are not visible in the CMS.
• Leaving staging blocks in place. Password protection, noindex rules, and test URLs should be reviewed before launch.
• Assuming the new host matches performance expectations automatically. After migration, benchmark speed and resource use. Better hosting still needs correct caching, image handling, and database cleanup.

If you are moving because your current host became more expensive than expected, it helps to review long-term cost structure before choosing the next provider. A migration is a good moment to compare first-year pricing against renewal pricing, not just the signup offer. See Web Hosting Renewal Prices Compared: What You Will Actually Pay After Year One.

When to revisit

The best migration checklist is one you update before every move, not one you use once and forget. Revisit this process whenever the underlying setup changes.

Review your checklist again in these situations:

• Before seasonal planning cycles. If your busiest period is coming, confirm whether a migration should happen now or wait until traffic is lower.
• When workflows or tools change. New CDN settings, a different email provider, a new security layer, or a revised backup method can all change migration steps.
• After adding ecommerce, memberships, or automation. Dynamic features increase risk during cutover and require more testing.
• When your DNS structure becomes more complex. Extra subdomains, verification records, and third-party services justify a fresh audit.
• When moving from a website builder to WordPress, or the reverse. That is more than a host switch; it affects templates, content structure, SEO handling, and maintenance. For broader platform planning, see Website Builder vs WordPress: Costs, Flexibility, SEO, and Maintenance and Best Website Builders for Small Business in 2026.

To make this article actionable, turn it into your own standard operating list. Save a copy and add three custom sections: your login inventory, your DNS record map, and your post-cutover test pages. Then, before you move website to new host next time, work through this short action plan:

1. Document the current setup.
2. Take and store independent backups.
3. Prepare the new host to match the old environment as closely as needed.
4. Test the migrated site before public cutover.
5. Change DNS only after validation.
6. Retest high-value functions immediately after launch.
7. Keep the old host active until the move is clearly complete.

That process is simple, but it is also what makes migrations repeatable. If you approach hosting changes as an operations task rather than a last-minute technical chore, you reduce downtime, protect SEO, and make future moves easier.