Moving a website to a new host does not require a visible outage when the work is planned in the right order. This guide explains how to migrate files, databases, DNS, email, SSL, and redirects while the existing site remains available, then provides a practical checklist and monitoring schedule for the days and weeks after the switch.
Overview
A hosting migration is a controlled change of the server that delivers your website. The domain name can remain the same, but the DNS records eventually need to point visitors to the new host. The safest approach is to build and test the new copy before changing those records.
Most migration problems come from treating the DNS change as the entire project. In practice, you also need to account for application files, databases, configuration values, scheduled jobs, SSL certificates, email records, forms, payment workflows, analytics, and search-engine redirects. A site can appear to load normally while a contact form, checkout process, or business email quietly fails.
The workflow below is suitable for many conventional websites and can be adapted for WordPress, custom applications, and content-managed sites. The exact control-panel labels will vary between providers. If you are comparing plans before a move, review the practical differences in how to choose web hosting for a small business, including storage, backups, access, and support requirements.
The no-downtime principle
Keep the old site active until the new site has been tested and DNS has had time to update. Do not cancel the old hosting account immediately after changing nameservers or DNS records. Visitors, crawlers, and mail servers may continue using cached DNS information for a period of time, so both environments may receive traffic during the transition.
What to track
1. Access and ownership
Before starting, confirm that you can access the domain registrar, current host, new host, DNS provider, website administration area, database, and email service. Record renewal dates and note which service controls the authoritative nameservers. A domain transfer is different from a hosting transfer: you can usually change web hosting without moving the domain registration.
2. A complete, restorable backup
Create a backup of the website files and database, and store a copy outside the current hosting account. For WordPress, include the uploads directory, themes, plugins, configuration file, and database. Export any custom DNS records and document email settings before changing them. A backup is only useful if it can be restored, so verify that the archive opens and, where practical, test it in a temporary environment. The website backup strategy for small businesses provides a useful framework for deciding what to retain and how often to test it.
3. DNS records and TTL
List the current A, AAAA, CNAME, MX, TXT, and any other records used by the domain. Pay particular attention to records for email authentication, subdomains, verification services, APIs, and staging environments. Lowering the TTL of web-related records before the migration may allow changes to be recognized sooner, but it does not instantly clear every cached result. Make the change far enough in advance to be useful, and return the TTL to a normal operating value after the migration is stable.
4. Application behavior
Track more than whether the homepage loads. Test internal links, images, search, login, forms, file uploads, comments, shopping carts, payment handoffs, account areas, and scheduled tasks. Check that the new server uses compatible PHP, database, runtime, extensions, permissions, and environment variables. For WordPress, clear temporary caches only after confirming that the copied site points to the correct database and domain.
5. Email continuity
Web hosting and business email may be on the same provider or on separate services. Identify the current MX records and do not replace them with the new host's suggested records unless you intend to move email too. Preserve relevant SPF, DKIM, and DMARC records, along with autodiscover or mail-client records where they are used. Send and receive test messages from more than one mailbox after the DNS change.
6. SSL, redirects, and search signals
Install or activate an SSL certificate on the new host before directing public traffic there. Test both the secure and non-secure versions, then confirm that HTTP redirects to HTTPS work as intended. Preserve existing URL paths whenever possible. If URLs must change, prepare one-to-one permanent redirects rather than sending every old page to the homepage. Review canonical tags, robots directives, XML sitemaps, analytics, and Search Console or equivalent verification after the move. For certificate planning, see the SSL certificate guide for website owners.
Reusable hosting migration checklist
- Confirm access to the registrar, DNS, old host, new host, CMS, database, and email systems.
- Record DNS records, server settings, cron jobs, redirects, subdomains, and scheduled integrations.
- Create and verify an off-server backup of files, databases, media, and configuration.
- Reduce relevant DNS TTL values in advance if your migration plan calls for it.
- Copy files and databases to the new host without changing public DNS yet.
- Configure the application, database credentials, runtime version, permissions, caching, and environment variables.
- Test the new copy using a temporary URL, hosts-file entry, staging domain, or provider preview method.
- Install SSL and test forms, logins, ecommerce functions, redirects, images, email, and scheduled tasks.
- Change only the required DNS records and keep the old host active.
- Monitor uptime, error logs, traffic, conversions, forms, email, and search-crawl signals.
- Take a final backup and retain the old environment until the migration is confirmed stable.
Cadence and checkpoints
Several days before the move
Inventory the current setup and decide what is actually changing. Confirm the new host's supported software and resource limits. Create the first backup, copy the site, and begin testing. If you use WordPress, a staging workflow can reduce the risk of testing directly on the live site; see how to set up staging for WordPress safely.
One day before the move
Review DNS records, TTL settings, email routing, and the migration runbook. Freeze nonessential content changes if the database will be copied only once. Notify team members who manage marketing, support, orders, or email. Confirm who can make an emergency DNS rollback and where the latest backup is stored.
During the switch
Perform a final database and file sync if the site has changed since the initial copy. Put a busy transactional site into maintenance mode only if needed, and keep that window as short as possible. Change the relevant A, AAAA, or CNAME records, or update nameservers if that is part of the plan. Avoid changing unrelated DNS records at the same time because it makes diagnosis harder.
First few hours
Check the website from different networks and devices. Review the new host's access and error logs, then test the highest-value journeys: contact submission, login, purchase, booking, download, or account renewal. Verify that email can be sent and received. Use DNS lookup tools to compare results, but remember that different resolvers may update at different times.
First two to seven days
Monitor uptime, response errors, server resource usage, page speed, forms, transactions, crawl errors, and unusual traffic changes. Keep the old host available during this observation period. If the site has frequent content or order activity, compare the old and new databases to ensure that late changes were not missed. Once performance and functionality are stable, restore normal DNS TTL values and schedule the old-account shutdown only after confirming that no services still depend on it.
How to interpret changes
If some visitors see the old site and others see the new one, DNS caching is a likely explanation during the transition. Do not immediately switch records back and forth; first identify which resolvers or regions are returning each destination. Keep both environments consistent while propagation is in progress.
A sudden increase in server errors usually points to an application, permission, runtime, database, or configuration problem rather than DNS alone. Compare the new host's error logs with the old environment and confirm that required extensions and environment variables exist. A blank WordPress page, for example, may require checking PHP compatibility, plugin errors, memory settings, and database credentials.
If the website works but email stops arriving, inspect MX records first, then review SPF, DKIM, DMARC, mailbox settings, and spam-folder behavior. If HTTPS produces warnings, verify that the certificate covers the exact hostname being visited and that all required intermediate certificates are installed. If search traffic or indexed URLs change, check redirects, canonical tags, robots rules, sitemap availability, and whether the new site accidentally uses a noindex setting.
When the new site is slower, compare more than the hosting brand. Check cache configuration, image sizes, database queries, third-party scripts, geographic distance, server resource limits, and whether a temporary staging or preview URL is being measured. A migration is a good opportunity to identify bottlenecks, but avoid making several unrelated performance changes before the baseline is understood.
When to revisit
Revisit this migration plan before any future hosting change, domain change, major platform upgrade, or DNS restructuring. A monthly check is sensible for active business sites: confirm that backups complete, test a restore when appropriate, review SSL status, inspect error logs, and verify that contact forms and critical integrations still work. The WordPress hosting maintenance checklist can help turn these checks into a repeatable routine.
Review the setup quarterly or after a major business change. Update the DNS inventory when you add a subdomain, email provider, payment service, analytics platform, or verification record. Recheck hosting capacity when traffic, media storage, transactions, or application complexity grows. Also revisit the plan after an incident, an unexplained traffic decline, repeated downtime, or a failed backup.
Before you close the old hosting account, complete this final action list:
- Confirm that DNS results consistently point to the new host from several networks.
- Check the homepage, key URLs, forms, accounts, transactions, email, SSL, and redirects.
- Review logs and monitoring for errors rather than relying only on a manual visit.
- Verify that the latest backup is stored outside the hosting account.
- Document the new host, DNS provider, renewal dates, credentials location, and rollback process.
- Keep the old environment until the agreed observation period has passed, then cancel it only after confirming that no email, subdomain, cron job, or integration still depends on it.
A careful migration is less about moving files quickly than about preserving every dependency around the website. By tracking DNS, backups, application behavior, email, SSL, redirects, and post-launch signals on a defined schedule, you can change hosting providers with a much lower risk of downtime or hidden service failures.
