How to Move Your Website to a New Host

A reusable checklist for moving your website to a new host with less downtime, fewer DNS mistakes, and a cleaner post-migration review.

Moving a site to a new host is usually less about copying files and more about controlling risk. This guide gives you a reusable website migration checklist you can follow before, during, and after the move, whether you run a static site, WordPress installation, custom app, or traditional database-backed website. The goal is simple: move website to new host with minimal downtime, preserve email and DNS settings, and avoid the common mistakes that cause broken pages, missing data, SSL warnings, or traffic loss.

Overview

A good host migration starts long before you change nameservers or update DNS records. The safest approach is to treat migration as a controlled rollout: audit the current site, prepare the new hosting environment, test thoroughly on a temporary URL or hosts-file override, lower DNS risk where possible, and only then cut over traffic.

This checklist is designed to work across common hosting models, including shared hosting, VPS hosting, cloud hosting, managed WordPress hosting, and developer hosting environments. The exact tools may differ, but the migration logic stays the same.

Core principle: never use DNS changes as your first test. Build the new environment first, verify it privately, and switch traffic only after you know the new host can serve the site correctly.

Before you begin, collect the basics:

Current hosting control panel access
Domain registrar and DNS management access
Application or CMS admin login
Database credentials
SSH, SFTP, or file manager access if available
SSL certificate method on the old host and planned method on the new host
Email routing details for the domain
Backup copies stored outside both hosts

If you are still comparing environments, it helps to understand the operational tradeoffs between shared hosting, VPS hosting, and cloud hosting before the move. Cost, root access, scaling, support quality, and control panel options all affect the migration path and your long-term maintenance burden. For related planning, see Web Hosting Cost Breakdown: What You Really Pay for Domains, SSL, Email, and Renewals and Best Hosting Control Panels Compared: cPanel vs Plesk vs DirectAdmin.

Universal pre-migration checklist

Inventory every site component: web files, database, cron jobs, email, SSL, redirects, subdomains, and external integrations.
Check software requirements on the new host: PHP or runtime version, database engine version, memory limits, web server type, Node or Python support, and required modules.
Create a full backup of files and databases.
Export DNS records before making any changes.
Document current DNS values, including A, AAAA, CNAME, MX, TXT, SPF, DKIM, and DMARC if used.
Review TTL settings and lower them ahead of the cutover if your DNS provider allows it and if the timing makes sense.
Plan a migration window that avoids your busiest traffic period.
Freeze content changes during final sync if the site is database-driven.
Confirm how you will test the new host before public cutover.

Checklist by scenario

Use the scenario that matches your site type, then add the universal checklist above. Most failed migrations happen because teams follow generic hosting migration steps and skip the details unique to their stack.

Scenario 1: Static website migration

Static sites are the simplest to move because there is usually no database and little application state. The main concerns are file integrity, redirects, SSL, and CDN behavior.

Copy the full site output, including hidden files such as .htaccess if you use Apache-based redirects.
Verify assets load with correct paths: CSS, JavaScript, images, fonts, and downloadable files.
Recreate redirects and custom error pages.
Reconfigure CDN or edge caching if the old host handled it automatically.
Test compression headers, cache headers, and canonical URLs.
Install SSL and verify there is no mixed-content issue.
Check contact forms or third-party scripts that may still point to old endpoints.

If you are rebuilding deployment while migrating, How to Deploy a Static Website Fast With Domain, SSL, and CDN Setup is a useful companion.

Scenario 2: WordPress hosting migration

WordPress moves are common, but they are not always simple. Themes, plugins, caching, image paths, scheduled jobs, and serialized data can all complicate the process.

Back up both files and database before touching DNS.
Note the current PHP version, WordPress version, plugin set, and active theme.
Set up WordPress on the new host or copy the full application directory.
Import the database carefully and update configuration values as needed.
Handle URL changes safely if you test on a temporary domain or staging URL.
Clear all caching layers: plugin cache, server cache, CDN cache, and browser cache where relevant.
Check media library paths, permalinks, form submissions, and search functionality.
Confirm cron tasks, backups, and security plugins still work on the new host.
Retest admin login, editors, uploads, checkout, and transactional email.

After migration, performance tuning matters as much as the move itself. See How to Speed Up a Slow Website on Shared Hosting if your new environment needs optimization.

Scenario 3: Traditional CMS or custom PHP app

For Joomla, Drupal, Laravel, Magento, or older custom stacks, compatibility checks are often the deciding factor.

Match or intentionally upgrade PHP and database versions only after compatibility testing.
Confirm required extensions, modules, and rewrite rules are available.
Move file permissions carefully; do not preserve insecure settings from the old host.
Review environment-specific settings in config files.
Test writeable directories such as uploads, cache, session storage, and logs.
Recreate cron jobs and background tasks.
Verify payment, search, API, or webhook integrations after cutover.

Scenario 4: Node.js or developer hosting migration

Application hosting adds process management, environment variables, build steps, and deployment workflows to the migration checklist.

List runtime versions, package manager requirements, environment variables, and process manager settings.
Confirm the new host supports persistent app processes, reverse proxy configuration, and the required ports or socket routing.
Test build and deploy steps in a non-production environment.
Recreate secrets securely rather than copying them loosely between servers.
Set up logs, restart policies, health checks, and monitoring before go-live.
Verify file storage strategy if uploads were previously stored on local disk.
Check webhook origins, CORS settings, and callback URLs.

Scenario 5: Email and domain hosting on the same account

This is the scenario most likely to cause accidental downtime because a site move is often bundled with DNS changes that also affect mail delivery.

Determine whether your email will stay with the old provider, move to the new host, or remain with a separate email service.
Copy or recreate MX, SPF, DKIM, and DMARC records exactly if email is staying outside the web host.
Do not assume nameserver changes will preserve custom DNS records.
Verify webmail, IMAP, SMTP, and forwarding behavior after the cutover.
Test inbound and outbound email from multiple destinations.

Scenario 6: Multiple websites on one hosting plan

If one account hosts several domains or subdomains, migration gets more procedural. Inventory matters even more than usual.

List every domain, addon domain, subdomain, parked domain, and redirect.
Map each site to its document root and database.
Check SSL coverage for each hostname.
Export all DNS zones and verify dependencies between sites.
Move each site in a controlled order, starting with the least business-critical property.

For account consolidation and layout planning, see How to Host Multiple Websites on One Server or Hosting Plan.

What to double-check

This is the part many migration guides treat too lightly. The site may look fine on the homepage but still fail in ways that only appear hours later. Use this review list before and after changing DNS.

DNS management and domain routing

Confirm whether you are changing nameservers or only updating A and AAAA records.
Check that the root domain and www host both resolve correctly.
Verify subdomains, staging hosts, API hosts, and mail-related records.
Review TTL settings and allow time for propagation variance.
Keep a copy of the previous DNS zone so you can roll back if needed.

Database integrity

Confirm row counts where practical for critical tables.
Check character encoding and collation consistency.
Test admin actions that write to the database, not just public page loads.
Make sure recent content created near cutover is present after final sync.

SSL certificate hosting and security

Install SSL before public cutover when possible.
Verify automatic renewal is configured on the new host.
Check for mixed content on HTTPS pages.
Reapply firewall rules, malware scanning, rate limits, and backup schedules.

Security hardening should not end at launch. Use Website Security Checklist for Small Business Hosting Accounts as a post-migration follow-up.

Application behavior

Test forms, uploads, login, logout, password reset, search, and checkout.
Confirm redirects, rewrites, and custom error pages.
Check external APIs, webhook callbacks, payment gateways, and analytics tags.
Verify cron jobs, queues, scheduled publishing, and backup jobs.

Performance and caching

Compare response times before and after migration using the same representative pages.
Clear caches at every layer after switching traffic.
Confirm the new host is not serving stale content from old cache entries.
Review image optimization, compression, HTTP caching, and CDN status.

Access and rollback readiness

Keep old hosting active until the new environment is stable.
Verify admin credentials, SFTP access, and emergency console or SSH access.
Document a rollback plan: what gets reverted, who does it, and how long it should take.

Common mistakes

If you want to change web host without downtime, avoid these predictable errors. They are more common than complicated server issues.

Changing DNS too early. If the new site has not been fully tested, DNS changes turn your users into testers.
Forgetting email records. A site migration can accidentally break business email if MX and related TXT records are not preserved.
Relying on one backup. Keep at least one backup outside both the old and new host.
Ignoring version compatibility. Newer PHP, database, or runtime versions can break older applications.
Skipping final data sync. Dynamic sites can lose recent orders, comments, tickets, or content edits if you do not account for data written during the migration window.
Testing only the homepage. Hidden failures usually appear in forms, admin panels, checkout paths, scheduled jobs, and attachments.
Assuming control panel migration is complete migration. Automated copy tools often miss custom configs, cron jobs, DNS edge cases, or external integrations.
Turning off the old host too soon. Keep it available until traffic, email, SSL, and scheduled tasks are fully verified.
Neglecting security reset tasks. After a move, rotate passwords or review credentials if they were shared during the migration.

If your old host felt inexpensive but costly in support time, migration is also a chance to reassess what "cheap web hosting" actually costs in operations. Reliable web hosting is not just server space; it includes usable DNS management, clean SSL workflows, practical backups, and support that can help during edge cases.

When to revisit

This checklist is worth revisiting any time the inputs change, not just when you are actively moving a site. Hosting environments evolve, and migration risk usually appears where old assumptions meet new tooling.

Review and update your migration plan in these situations:

Before renewing or replacing your current web hosting plan
Before seasonal traffic periods, launches, or marketing campaigns
When changing CMS versions, major plugins, runtimes, or database engines
When moving DNS management to a new provider
When separating domain registration, email, and hosting across different vendors
When redesigning deployment workflows or adding staging environments
After adding new subdomains, external integrations, or transactional email services

For practical maintenance, keep a simple migration runbook with the following items:

A current export of your DNS records
A list of all apps, domains, and services tied to the hosting account
Backup and restore instructions that someone else on the team could follow
A cutover checklist with owners and timing
A rollback plan tested at least once in a low-risk environment

If you only do one thing after reading this site migration guide, do this: document your current environment before you touch anything. The act of inventorying DNS, email, SSL, databases, and scheduled tasks will prevent more migration issues than any single tool.

A host move should leave you with better reliability, cleaner management, and a setup you can support over time. Use this checklist before the next migration, after major infrastructure changes, and whenever your domain hosting, DNS management, or deployment workflow is updated.