How to Migrate a Website to a New Host: Pre-Move Checks, DNS Cutover, and Rollback Plan

Overview

If you are searching for how to migrate a website to a new host, the core goal is simple: reproduce the site accurately on the new platform, cut traffic over in a controlled way, and avoid irreversible changes until you know the new environment is stable.

A good migration plan usually covers five areas:

1. Inventory: know exactly what the current site depends on.
2. Backups: create restorable copies before touching anything.
3. Build and test: prepare the new hosting stack and verify functionality before DNS changes.
4. Cutover: update DNS, proxy, or load balancer settings carefully and monitor the result.
5. Rollback: keep the old host intact long enough to reverse course if needed.

This applies whether you are moving from shared hosting to VPS hosting, from a traditional provider to cloud hosting, or from one managed platform to another. The exact mechanics vary by stack, but the migration logic stays the same.

Before you begin, define the scope of the move. Are you migrating only files and databases, or also email, DNS management, SSL certificates, cron jobs, firewall rules, object storage, CDN settings, and scheduled backups? A migration goes wrong most often when one of those secondary systems is assumed rather than documented.

It also helps to separate three related tasks that are often confused:

• Hosting migration: moving site code, databases, and runtime configuration.
• DNS cutover: pointing traffic to the new infrastructure.
• Domain transfer: moving the domain registration itself to a new registrar.

You do not need to transfer domain registration in order to move website hosting. In many cases, it is safer to keep those steps separate. If your project also includes registrar changes, review a dedicated domain transfer checklist separately: How to Transfer a Domain Name Without Downtime.

Checklist by scenario

Use this section as the working migration playbook. Start with the universal checklist, then add the scenario-specific steps that match your hosting stack.

Universal pre-move checklist

1. Record the current environment. Note PHP, Node, Python, database, web server, and control panel versions. List installed modules, extensions, and background jobs. If the new host runs a different version stack, confirm compatibility before you copy data.
2. Map all DNS records. Export or manually review A, AAAA, CNAME, MX, TXT, SRV, and CAA records. This prevents incomplete DNS recreation during cutover. If you need a refresher, your team should maintain internal DNS notes or a records inventory because missing a single mail or verification record can create a side problem that looks unrelated to the website.
3. Audit the application dependencies. Check environment variables, API keys, third-party callbacks, payment gateway webhooks, SMTP relays, object storage buckets, image processors, queue workers, and firewall allowlists.
4. Take full backups. Create separate copies of website files, databases, configuration files, and any user uploads. Store backups offsite, not only on the source server. For a deeper backup framework, see Website Backup Strategy Guide and How Often Should You Back Up a Website?.
5. Confirm you can restore. A backup is useful only if it can be restored. If possible, test a restore in a staging environment before migration day.
6. Lower DNS TTL in advance. If you control DNS management, reduce the TTL on the main records well before cutover so changes propagate faster later. Do this early enough that the lower value has time to take effect.
7. Build the new hosting environment. Create the destination site, provision the database, configure the web server, install runtime dependencies, and set file permissions.
8. Install SSL certificates. Prepare HTTPS before cutover if possible. If certificate issuance depends on live DNS, plan the order of operations carefully. Related reading: How to Set Up SSL Certificates for Any Website.
9. Copy data to the new host. Migrate files, import the database, sync uploads, and update configuration values such as database credentials and environment variables.
10. Test without changing public DNS. Use a temporary URL, hosts file override, preview domain, tunnel, or provider staging feature to validate the site on the new host.
11. Freeze high-risk changes. Avoid plugin updates, code deploys, schema changes, and content-heavy edits immediately before migration. Stability beats convenience during the move.
12. Define your rollback trigger. Decide in advance what counts as failure: checkout errors, broken login, database write issues, missing media, major performance regression, or SSL problems. A rollback plan works only if the threshold is agreed on before the cutover.

Scenario 1: Static site or simple brochure site

This is usually the lowest-risk migration path. You still need a checklist, but there may be no database and no write activity to reconcile.

• Export the site files or repository.
• Recreate redirects, cache headers, and compression rules.
• Check forms, analytics tags, robots directives, and sitemap location.
• Verify HTTPS, canonical URLs, and www/non-www redirects.
• Run a final visual QA on key pages before DNS cutover.

Even simple sites can fail in small but important ways, especially if redirects or SSL certificates are handled differently by the new provider.

Scenario 2: CMS site such as WordPress, Joomla, or Drupal

CMS migrations are common and usually fail at the edges: serialized data, file ownership, plugin caching, scheduled tasks, and search-and-replace errors.

• Export both files and database.
• Move uploads and generated assets, not just theme or application files.
• Review config files for database settings, salts, cache backends, and debug flags.
• Disable aggressive caching layers until the site is validated on the new host.
• Check scheduled jobs such as cron-based publishing, cleanup, and backups.
• Verify admin login, media library, forms, search, and any ecommerce flow.

If the destination is managed WordPress hosting, compare which tasks are handled by the platform versus the old host. Platform assumptions differ. For broader platform fit, see Best WordPress Hosting for Growing Sites.

Scenario 3: Database-backed custom application

For dynamic applications, the difficult part is not copying the first dataset. It is handling changes that happen while the site is still live on the old server.

• Plan for a content freeze, maintenance window, database replication, or final delta sync.
• Check application secrets, API endpoints, queue workers, and webhooks.
• Review background job infrastructure and outbound email configuration.
• Test file uploads, sessions, authentication, and payment flows.
• Validate time zones, locale settings, and filesystem paths.

If the site cannot tolerate write loss, treat the migration as a data synchronization project, not just a file copy.

Scenario 4: Shared hosting to VPS or cloud hosting

This move often improves control and performance, but it also transfers responsibility to your team.

• Recreate the old environment manually where needed: web server config, PHP modules, mail handling, cron jobs, and backup schedules.
• Set up server hardening, firewall rules, SSH access, and least-privilege user accounts.
• Install monitoring before launch, not after.
• Benchmark performance and tune caching, database settings, and compression.

After the migration, review optimization opportunities with How to Speed Up a Slow Website.

Scenario 5: DNS cutover plan

If you want to move website without downtime, DNS cutover is the step to rehearse most carefully.

1. Confirm the new host answers correctly for the domain over HTTP and HTTPS.
2. Take one final backup and, if needed, a final database sync.
3. Pause content edits or place the site into maintenance mode for write-heavy applications.
4. Update the required DNS records or switch the origin behind your proxy/CDN.
5. Monitor traffic, error logs, application logs, and uptime checks immediately.
6. Keep the old host online until propagation is complete and core workflows are verified.

Do not cancel the old plan as soon as the new site appears live from your location. DNS propagation and cached records can produce split traffic for a period of time.

Scenario 6: Rollback plan

A hosting migration rollback plan should be short, explicit, and tested in principle before cutover.

• Keep the old site intact and capable of serving traffic.
• Preserve the pre-cutover backups and exported configuration.
• Document the exact DNS records needed to point traffic back.
• Know whether any data created on the new host must be preserved before rollback.
• Assign an owner for the rollback decision so the team does not lose time debating during an incident.

Rollback is not a sign of failure. It is a normal control for production changes.

What to double-check

Before and after cutover, these are the areas most likely to create hidden issues.

DNS and domain settings

• Main site records point to the correct destination.
• Mail-related records are unchanged if email is staying elsewhere.
• SPF, DKIM, DMARC, and verification TXT records remain intact.
• CAA records allow the certificate authority you plan to use.

If registrar and DNS responsibilities are split across vendors, note which panel actually controls live records. This is a frequent source of confusion during domain registration and DNS management changes.

SSL, redirects, and canonical behavior

• HTTPS loads cleanly without mixed content warnings.
• HTTP redirects to HTTPS as intended.
• www and non-www variants resolve consistently.
• Canonical tags match the preferred hostname.

These are small checks with outsized impact on trust, search visibility, and user sessions.

Application integrity

• Logins work.
• Forms send successfully.
• Media files load.
• Search works.
• Checkout or lead capture completes end to end.
• Cron jobs and scheduled tasks run on the new server.

For admin-heavy or transactional sites, test both anonymous and authenticated user paths.

Backups, security, and monitoring

• New backup jobs are enabled and writing to the correct destination.
• Retention settings are appropriate for the site’s risk profile.
• Server logs, application logs, and uptime alerts are active.
• Access policies reflect the new environment.

If your site stores user data or critical assets, pair the migration review with a security check: Cloud Storage Security Checklist and Website Uptime Monitoring Comparison are useful companions.

Common mistakes

Most migration failures are not dramatic. They are the result of ordinary omissions that stack up.

• Changing too many variables at once. Moving hosts, redesigning the site, changing DNS providers, and upgrading runtime versions in one step makes troubleshooting slower and riskier.
• Skipping the restore test. Teams often back up data but never confirm that the backup is usable.
• Forgetting non-web services. Email routing, background jobs, API callbacks, and offsite website backup jobs are easy to overlook.
• Relying on local spot checks only. A page that works for one administrator may still fail for real users due to redirects, cookies, permissions, or stale caches.
• Ending the old hosting too early. Keeping overlap between the old and new website hosting environments is one of the simplest ways to reduce operational risk.
• Ignoring performance after launch. A site can be technically live yet materially slower on the new stack. Hosting migration should include post-cutover performance checks, not just availability checks.
• No written rollback plan. In a tense moment, memory is unreliable. Write the rollback steps down before the cutover.

If the move also includes a new control panel or managed dashboard, expect some operational differences in file paths, cron configuration, backup tools, and SSL handling. This is worth reviewing in advance: cPanel vs Plesk vs Managed Dashboards.

When to revisit

This checklist is most useful when treated as a living runbook rather than a one-time article. Revisit it any time the underlying stack or workflow changes.

Update your migration plan when:

• You switch from shared hosting to VPS hosting or cloud hosting.
• You add a CDN, reverse proxy, WAF, or separate DNS provider.
• You move backups to a different cloud storage destination.
• You change your CMS, ecommerce platform, or application runtime.
• You adopt managed WordPress hosting or a new control panel.
• You change SSL issuance workflows or certificate providers.
• You prepare for seasonal traffic, product launches, or infrastructure consolidation.

A practical habit is to maintain a one-page migration worksheet for each site you operate. Include:

1. Current hosting details and server versions.
2. DNS zone summary and registrar ownership.
3. Backup locations and restore notes.
4. Application dependencies and webhook endpoints.
5. Cutover steps with timestamps and owners.
6. Rollback criteria and reversal steps.
7. Post-launch validation checklist.

For teams managing multiple properties, this worksheet becomes more valuable over time. Every move gets easier when you do not have to rediscover how the site is wired together.

Final practical step: before your next migration, schedule a dry run. Build the new environment, restore the latest backup, test through a hosts file or staging URL, and measure how long the final sync and DNS cutover actually take. A dry run turns migration anxiety into a sequence of known tasks. That is the most reliable way to move a site without downtime, or at least without unnecessary downtime.