Website Migration Checklist: Move Hosts Without Breaking Your Site

Overview

A website migration can mean several different changes: moving files to a new server, changing DNS hosting, switching email providers, transferring a domain registration, or rebuilding the stack on a different platform. Problems usually happen when these are treated as one task instead of separate layers.

A safer approach is to break the move into five parts:

1. Inventory what exists now. Know where your domain registration, DNS hosting, web hosting, SSL, email, backups, and application data live.
2. Prepare the destination. Build the new environment before touching live traffic.
3. Copy and validate the site. Move files, databases, media, environment variables, cron jobs, and dependencies, then test privately.
4. Cut over traffic carefully. Update DNS only after the new host is ready, and avoid changing unrelated services at the same time.
5. Keep a rollback path. Leave the old host intact until the new setup has passed real-world checks.

If your migration also includes domain transfer, treat that as a separate project with its own timing and checks. Domain registration and domain transfer are not the same as moving web hosting. Many site owners safely move a domain without downtime, but the operational steps are different from a hosting migration.

Before you begin, clarify which of these are changing:

• Web host only
• DNS hosting only
• Web host and DNS together
• Email provider
• SSL setup
• Domain registrar
• Application stack, such as shared hosting to cloud hosting

If you are still comparing environments, it helps to decide first whether your next setup should stay simple or become more scalable. For that planning step, see Shared Hosting vs Cloud Hosting vs VPS: Which Should You Choose?.

Pre-migration master checklist

• Record current providers for domain and hosting, DNS hosting, SSL, email, CDN, and backups.
• Export or save current DNS records: A, AAAA, CNAME, MX, TXT, SRV, and any custom records.
• List every website dependency: database, object storage, cache, cron jobs, queues, API keys, business email with domain, firewall rules, and SSL certificates.
• Take full backups of files and databases.
• Verify that backups can be restored, not just downloaded.
• Reduce DNS TTL in advance if you control the zone and expect a DNS cutover.
• Provision the new hosting account or server.
• Install the runtime and dependencies: web server, database version, PHP or Node version, modules, and extensions.
• Create a temporary testing method, such as a staging URL, hosts file override, or preview domain.
• Migrate site content and configuration.
• Test the new environment without changing public DNS.
• Issue or prepare SSL on the destination.
• Freeze content updates if the site is dynamic and you need a final sync.
• Schedule the cutover during a lower-risk window.
• Monitor after launch and keep the old host online until stable.

Checklist by scenario

Use the scenario that matches your move. The steps overlap, but the risks differ.

1) Static website or small brochure site

This is usually the simplest migration because there may be no database and few moving parts.

1. Download the current site files.
2. Upload them to the new host, preserving paths and permissions.
3. Confirm redirects, custom error pages, forms, and assets load correctly.
4. Set up SSL hosting on the new environment before cutover.
5. Test via preview URL or hosts file override.
6. Update DNS records to point the domain and hosting to the new destination.
7. Monitor HTTP to HTTPS behavior, canonical tags, and redirect loops.

If you need a refresher on records involved in connecting a domain to hosting, review How to Connect a Domain to Web Hosting: DNS Records Explained.

2) WordPress or CMS migration

WordPress hosting for beginners often looks simple until plugins, media libraries, scheduled tasks, and caching are involved. Treat it as an application migration, not just a file copy.

1. Back up site files and the database.
2. Record the current PHP version, database version, theme, plugins, and active caching layers.
3. Provision the destination with compatible versions.
4. Copy files, including uploads and configuration files.
5. Export and import the database.
6. Update configuration values if database host, credentials, or paths change.
7. Check serialized data issues if the domain or path changes.
8. Disable page caching or CDN caching temporarily while testing.
9. Verify login, contact forms, search, checkout, media, and scheduled tasks.
10. Issue SSL and enforce HTTPS only after confirming the site works.
11. Perform a final content sync if comments, orders, or posts changed during testing.
12. Update DNS and monitor logs after cutover.

If cost is part of your hosting review, compare setup and renewal assumptions before moving. This is where many “cheap web hosting with SSL” offers become less simple over time. See Web Hosting Pricing Guide: What You Really Pay in Year 1 and Renewal.

3) Database-driven custom app

For custom applications, most migration failures come from environment mismatches and hidden dependencies.

1. Inventory app services: database, cache, queue, storage, secrets, cron jobs, workers, and third-party integrations.
2. Match runtime versions and system packages on the destination.
3. Migrate application code using the same deployment method you use in production where possible.
4. Restore the database into a test environment and run migrations carefully.
5. Load environment variables and secrets securely.
6. Confirm file storage paths, permissions, and background jobs.
7. Test authentication, sessions, webhooks, and outbound email.
8. Plan for write freeze or replication during final cutover if the app changes data constantly.
9. Run smoke tests and a rollback drill before changing DNS.
10. Cut over traffic and monitor error rates, logs, queue depth, and response times.

4) Migration that includes email

Email is where otherwise successful website migrations become messy. If your site uses business email with domain, treat MX, SPF, DKIM, and DMARC records as critical assets.

1. Export all existing DNS records before touching mail settings.
2. Document current mail routing and mailbox provider.
3. Recreate MX, SPF, DKIM, and DMARC records exactly where needed.
4. If mailboxes are moving too, migrate mailbox contents separately from the website.
5. Test inbound and outbound email on a noncritical account first.
6. Avoid deleting the old mail service until new delivery is verified.
7. Check transactional email from forms, apps, and order confirmations after cutover.

A hosting migration does not require changing email providers. If email is stable, leave it alone unless there is a clear reason to move it.

5) Migrate site without downtime

Zero downtime is not always literal, but you can often make the transition quiet enough that users do not notice.

1. Build the full site on the new host before any public DNS change.
2. Lower TTL on relevant DNS records in advance if you control them.
3. Keep the same URL structure and SSL coverage.
4. Use a final content sync close to cutover time.
5. Put dynamic writes into maintenance mode briefly if exact consistency matters.
6. Switch only the necessary DNS records, not the entire zone unless required.
7. Leave the old host serving traffic during propagation.
8. Monitor both environments until requests stop reaching the old origin.

For a practical explanation of timing during propagation, read DNS Propagation Checker Guide: How Long DNS Changes Really Take.

6) Moving from shared hosting to cloud hosting or VPS

This is a common upgrade when you outgrow entry-level web hosting. It also introduces more operational responsibility.

1. Identify what your old host managed for you: backups, SSL renewal, security patches, firewall rules, malware scans, and email.
2. Recreate those protections on the new stack.
3. Check web server config, PHP handlers, process managers, and database tuning.
4. Set up monitoring, log access, and automatic backups before launch.
5. Test permissions carefully, especially uploads, sessions, and cache directories.
6. Document who owns server updates and incident response after migration.

Fast web hosting matters, but secure web hosting and operational clarity matter just as much. Performance gains are not worth much if backups and SSL hosting are left unfinished.

What to double-check

These are the items most worth reviewing just before and just after cutover.

DNS and domain settings

• Are A, AAAA, CNAME, MX, TXT, and any verification records present and correct?
• Did you update only the records needed for the website migration?
• Are nameservers unchanged unless you intended to switch DNS hosting?
• Is the domain registration active and not close to expiration?
• If you use WHOIS privacy or domain privacy protection, does it remain enabled where appropriate? Related reading: Domain Privacy Protection Explained: Is WHOIS Privacy Worth It?.

SSL and HTTPS

• Is a valid certificate installed for the primary domain and www variant if both are used?
• Do redirects send all traffic to the preferred HTTPS hostname without loops?
• Are there mixed-content warnings from old asset URLs?
• Have you decided whether a free or paid certificate matches your setup and support needs? See Free SSL vs Paid SSL: What Website Owners Actually Need.

Application behavior

• Can users log in, submit forms, reset passwords, and complete purchases?
• Do background jobs, webhooks, and scheduled tasks run correctly?
• Are file uploads writing to the right location?
• Are environment variables loaded on the new host?
• Did caching or CDN rules carry over in a way that hides real errors?

Data consistency

• Was the latest database copied after the final content freeze?
• Did user-generated content change during the migration window?
• Were media files and attachments fully transferred?
• Are search indexes or object caches rebuilt if needed?

Monitoring and rollback

• Can you view access logs and application logs on the new host?
• Do you know the exact DNS or routing step needed to revert if something breaks?
• Is the old host still intact and ready for temporary rollback?
• Did you define a point at which the migration is considered complete?

A useful rule: do not cancel the old account the same day the new site goes live. Wait until logs, traffic, email, backups, and SSL all look normal.

Common mistakes

Most migration pain comes from rushing basics rather than from rare technical edge cases.

Changing too many things at once

A common error is combining a host move, a domain transfer, DNS hosting change, email move, redesign, and application upgrade into one event. Each added change expands the failure surface. If possible, move one layer at a time.

No tested backup

A backup is only useful if you know it restores cleanly. Before cutover, confirm you can recover the site or database from the backup you took.

Forgetting email records

Website owners often update web records and accidentally disrupt business email with domain by replacing or omitting MX and TXT records. Always export the full zone before edits.

Skipping private testing

Pointing live DNS to an untested host is avoidable. Use a staging URL, temporary subdomain, or hosts file override to verify the destination first.

Assuming SSL will sort itself out

Some platforms provision certificates automatically; others need a completed DNS state before issuance works. Confirm the order of operations so the site does not launch with certificate errors.

Ignoring propagation behavior

DNS changes are not instant everywhere. During the transition, some users may still reach the old host. That is why the old environment should stay available until traffic clearly drains away.

Missing scheduled jobs and background workers

The website may load normally while backups, imports, reports, renewals, or notifications silently fail because cron jobs or worker processes were never recreated.

Canceling the old host too early

Even if the homepage works, hidden pages, forms, or admin tasks may still fail. Keep the previous host available until you finish a full post-launch review.

Overlooking registrar and DNS separation

You can buy domain services from one provider and use DNS hosting or web hosting elsewhere. If you are unsure where a setting lives, slow down and map the stack first. That separation is normal in domain and hosting workflows, especially for more technical teams.

When to revisit

This checklist is most useful when treated as a living playbook rather than a one-time article. Revisit it whenever the inputs behind your hosting migration change.

Review this checklist before:

• Moving to a new host for performance, support, or pricing reasons
• Shifting from shared hosting to cloud hosting or VPS
• Changing DNS hosting providers
• Launching a redesign on a new environment
• Adding SSL, CDN, or security layers that affect routing
• Migrating email or transactional mail services
• Seasonal traffic windows, product launches, or marketing campaigns
• Renewal periods when you are reevaluating domain and hosting arrangements

Update your internal version when:

• Your stack changes, such as a new framework, CMS, or deployment workflow
• You add third-party integrations, payment tools, or webhooks
• You change where backups are stored or how they are restored
• Your team changes ownership of DNS, infrastructure, or application support
• You learn from a past migration and want to prevent the same issue next time

Action plan for your next migration

1. Create a one-page inventory of current domain registration, DNS hosting, web hosting, SSL, backups, and email.
2. Choose the migration scenario above that best fits your site.
3. Turn the relevant checklist into a dated runbook with owners and rollback steps.
4. Test the destination privately before any public DNS change.
5. Cut over during a low-risk window and monitor actively.
6. Keep the old host live until you can verify traffic, data, email, and certificates are stable.

If you return to this checklist before every move, you will catch most migration risks early. That is the real goal: not a perfect theory of website transfer steps, but a repeatable process for moving a site to a new host with fewer surprises and less downtime.