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

Overview

A host migration is rarely just a file copy. In most cases, you are moving a combination of application code, databases, DNS records, SSL configuration, cron jobs, email routing, cache rules, redirects, and environment-specific settings. The safest way to move website to new hosting is to treat it like a controlled change, not an emergency task.

A good website migration checklist should answer five questions before anything changes publicly:

• What exactly is moving?
• What depends on the current host?
• How will you validate the new environment?
• What is the cutover method?
• How will you roll back if something fails?

That framing helps whether you are moving from shared hosting to cloud hosting, from one managed WordPress platform to another, or from an older VPS to a cleaner developer hosting setup.

Use this pre-move workflow in order:

1. Inventory the current site and services.
2. Back up everything you cannot afford to lose.
3. Build the new environment to match production needs.
4. Migrate code, data, media, and configuration.
5. Test privately before any public DNS change.
6. Cut over with a documented sequence.
7. Monitor and keep rollback available until stable.

If you are still deciding between environments, it helps to read How to Choose a Cloud Server for a Web App and VPS Hosting for Developers: What Specs Matter Most? before you provision the destination.

Core pre-move checklist

• List all domains, subdomains, and DNS records in use.
• Record current hosting details: OS, runtime version, database version, web server, control panel, storage layout, and scheduled jobs.
• Identify application dependencies: PHP modules, Node version, Python packages, image libraries, Redis, search services, queues, or background workers.
• Export a full backup of files and databases.
• Back up DNS zone records separately.
• Document current SSL certificates and renewal method.
• Check whether the site sends or receives email through the same provider.
• Reduce DNS TTL in advance if your DNS provider allows it.
• Create a staging or test validation plan.
• Write a rollback checklist before cutover day.

For staging discipline, see Staging vs Production Environments: Hosting Setup Best Practices.

Checklist by scenario

The exact migration path depends on the type of site and the type of host you are leaving. Use the scenario below that is closest to your setup, then add the shared checks from the rest of the article.

Scenario 1: Static site or simple business website

This is usually the lowest-risk migration, but basic sites still break when redirects, SSL, or DNS are overlooked.

• Download all site files, including hidden files such as .htaccess if applicable.
• Recreate directory structure on the new host.
• Confirm web root path on the destination host.
• Copy redirects, custom error pages, and rewrite rules.
• Verify SSL provisioning on the new server before the cutover window.
• Test forms, thank-you pages, and outbound email delivery.
• Review image paths, relative links, and hard-coded URLs.

If the site relies on a CDN or proxy layer, review how origin changes affect caching. CDN vs Hosting: What Each One Does for Speed and Reliability is a useful reference before changing the origin server.

Scenario 2: WordPress or another database-backed CMS

This is the most common type of move and the one most likely to fail because of plugin conflicts, serialized URLs, cache issues, or version mismatches.

• Export both files and database.
• Match supported runtime versions on the new host as closely as practical before upgrading anything.
• Move media libraries completely, especially custom upload paths.
• Update configuration files with new database credentials.
• Use the correct search-and-replace method for site URLs if domain or path changes are involved.
• Disable or purge application caches before final sync.
• Check plugin or extension requirements, especially for image processing, email, security, and page caching.
• Validate login, admin actions, forms, comments, search, checkout, and scheduled tasks.

If your new environment is managed WordPress hosting, pay attention to provider-specific caching and file access rules. Some hosts handle backups, caching, and SSL differently than a general-purpose web hosting or cloud hosting setup.

Scenario 3: Custom application on VPS or cloud server

When you migrate an app stack, the application is only part of the move. Your runtime, process manager, deployment flow, secrets, and networking often matter more than the code transfer itself.

• Document the current deployment process step by step.
• Inventory all services: app server, database, object storage, cache, search, queue, scheduler, workers, and reverse proxy.
• Rebuild environment variables securely rather than copying them casually between servers.
• Match system packages and runtime versions first, then deploy the app.
• Verify firewall rules, open ports, SSH access, sudo roles, and fail2ban or equivalent controls if used.
• Confirm process supervision for app workers and scheduled jobs.
• Test asset compilation, background tasks, and file permissions.
• Validate log output and alerting before production traffic arrives.

If containerization is part of your move, Docker Hosting Options Explained: VPS, Managed Cloud, and Platform Services can help you decide whether to keep the current model or simplify it.

Scenario 4: Domain remains with current registrar, hosting changes only

This is often the cleanest route, but it requires accurate DNS management.

• Do not transfer domain ownership unless there is a separate reason to do so.
• Copy all current DNS records before editing anything.
• Identify the records that need to change: usually A, AAAA, CNAME, and possibly TXT records for verification.
• Check MX, SPF, DKIM, and DMARC if email is involved.
• Lower TTL ahead of time if possible.
• Plan who will update DNS and when.

For the cutover sequence, see How to Point a Domain to a New Host Safely.

Scenario 5: Domain transfer and hosting migration at the same time

This is usually avoidable and increases risk. If possible, separate the two tasks. Migrate hosting first, confirm stability, then transfer domain registration later.

• If you must combine them, verify registrar lock status, authorization steps, and admin contact access well in advance.
• Preserve the DNS zone during the registrar move or confirm where authoritative DNS will live after transfer.
• Do not assume nameserver settings will stay untouched without checking.
• Schedule a wider support window because more systems are changing at once.

If domain management is part of your longer-term cleanup, Domain Name Registration Checklist for New Businesses provides a useful ownership and record-keeping model.

Scenario 6: Ecommerce or dynamic site with frequent data changes

These moves need special care because content may change every minute.

• Identify write-heavy areas: orders, user accounts, form submissions, inventory, bookings, comments, support tickets.
• Plan a final sync window close to DNS cutover.
• Decide whether the site will enter maintenance mode briefly.
• Avoid long content freezes unless business constraints allow it.
• Test payment callbacks, transactional email, webhooks, and tax or shipping integrations in the new environment.
• Prepare a post-cutover reconciliation step for records created during the transition window.

For backup discipline on high-change sites, review Website Backup Strategy for Small Business: What to Back Up and How Often.

What to double-check

These are the items that most often delay a launch or create partial failures after a site appears to be live.

DNS and domain hosting details

• Authoritative nameservers are correct.
• Apex and www records point where expected.
• Subdomains used by apps, APIs, staging, mail, or login flows are accounted for.
• TTL changes were made early enough to matter.
• Old records that should remain in place, especially MX and TXT, are not removed by mistake.

SSL and certificate coverage

• The certificate matches every hostname in use.
• Redirects from HTTP to HTTPS are configured correctly.
• Mixed-content warnings are resolved if assets still reference old URLs.
• Renewal method is understood on the new host.

If you are consolidating hostnames, check Wildcard SSL vs Single-Domain SSL vs Multi-Domain SSL before you provision certificates.

Application configuration

• Environment variables are present and accurate.
• Database hostnames, ports, usernames, and passwords work from the new app server.
• Writable directories have the right ownership and permissions.
• Temporary storage, sessions, and cache locations are valid on the new system.
• Absolute paths from the old host are not hard-coded in the app or automation scripts.

Background tasks and automation

• Cron jobs were recreated, not forgotten.
• Scheduled tasks do not run twice on both old and new servers after cutover.
• Queues and workers connect to the right backend services.
• Backups, cleanup jobs, and report generation tasks are enabled again after testing.

Email and third-party services

• Contact forms send correctly.
• Application mail uses the intended SMTP or API provider.
• DNS verification records for external tools remain intact.
• Webhook endpoints, OAuth callbacks, and API allowlists are updated if IPs or domains changed.

Performance and security baseline

• Caching layers are configured intentionally, not inherited by accident.
• Compression, HTTP headers, and CDN settings align with the new host.
• Access to admin tools, SSH, database ports, and control panels is limited appropriately.
• Monitoring, uptime checks, and log review are in place before traffic switches.

If your new environment adds an easier hosting control panel, use that to simplify recurring operational tasks, but confirm that convenience features do not silently change your previous behavior.

Common mistakes

Most migration problems are not dramatic engineering failures. They are small omissions that combine at the worst possible time. Watch for these recurring issues:

Moving without a rollback plan

A rollback plan should define what triggers a rollback, who decides, how DNS or traffic will be pointed back, and how recent data created on the new host will be handled. Even if you never use it, writing it down makes the cutover cleaner.

Changing too many variables at once

Try not to migrate hosting, redesign the site, change the domain, upgrade the runtime, switch email routing, and enable a new CDN in one event. If something breaks, root cause becomes harder to isolate. Sequence the changes when possible.

Skipping private testing

Testing only after public DNS changes is risky. Use a temporary URL, hosts file override, or staging domain to validate the destination environment before traffic moves.

Assuming email is separate when it is not

Many site owners focus on web files and databases, then discover that mailboxes, forwarding, or DNS-based mail authentication lived with the old host. Keep email on a separate checklist even if you think the site move will not affect it.

Forgetting the final database sync

On dynamic sites, an early database export may already be stale by cutover time. Plan a final sync close to launch or define a maintenance window to freeze writes briefly.

Leaving the old host too soon

Do not cancel the previous host immediately after DNS changes. Keep the old environment available until you are confident traffic, forms, jobs, and integrations are stable. This makes rollback practical instead of theoretical.

Not documenting the new environment

Once the migration succeeds, update your operational notes. Record where DNS is managed, how SSL renews, how backups run, what the deployment process is, and who has access. This turns a one-time move into a maintainable setup.

When to revisit

This checklist is most useful when you return to it before a change window, not just when you are already under pressure. Revisit and update it in these situations:

• Before seasonal traffic periods or major campaigns.
• Before changing hosting plans, such as moving from shared hosting plans to cloud hosting or a VPS.
• When the application stack changes, including new runtime versions, containers, workers, or managed services.
• When your DNS management or registrar setup changes.
• When you add new subdomains, SSL requirements, or external integrations.
• When your backup and disaster recovery process changes.
• After a previous migration incident, so lessons are captured while fresh.

For a practical next step, turn this article into your own migration runbook. Create a versioned checklist with these headings:

1. Scope: domains, apps, databases, services, owners.
2. Pre-move backups: what was backed up, where, and how restore was tested.
3. Destination build: server specs, software versions, access, firewall, SSL.
4. Validation: test URLs, smoke tests, performance checks, form tests.
5. Cutover: exact DNS or proxy changes, order of operations, communication plan.
6. Rollback: triggers, timing, ownership, restoration steps.
7. Post-cutover: monitoring, cache purge, log review, final signoff.

If you want to make future moves easier, build around repeatable infrastructure choices rather than one-off fixes. That may mean a cleaner cloud server design, a more predictable developer hosting workflow, or a better separation between domain registration, DNS, web hosting, backups, and email services.

The best hosting migration guide is the one you can trust under pressure. Keep it current, keep it specific to your stack, and update it whenever your tools or workflows change.