Moving a website to a new host without downtime requires more than copying files. This reusable migration checklist covers DNS preparation, backups, database synchronization, SSL, staged testing, cutover, and rollback so you can change hosting providers with a controlled interruption risk.
Overview
A successful website migration separates the work into two tracks: preparing and testing the new server, then directing visitors to it. Keep the old hosting account active until the new environment has passed functional checks and the DNS change has had time to take effect.
In most cases, the domain itself does not need to move with the website. You can leave registration at the current registrar and change the domain’s DNS records to point to the new host. This is usually simpler than combining a hosting migration with a registrar transfer. If you also need to transfer the domain, use the separate domain transfer checklist and treat that as an additional project.
Migration checklist at a glance
- Inventory the site, DNS records, email services, cron jobs, integrations, and certificates.
- Create and test independent backups of files, databases, and configuration.
- Build the site on the new host using a temporary URL, hosts-file entry, or staging domain.
- Lower relevant DNS TTL values before the planned cutover.
- Synchronize the database and recently changed files immediately before switching traffic.
- Confirm SSL, redirects, forms, logins, payments, email, and scheduled tasks.
- Change DNS, monitor both hosts, and keep the old environment available for rollback.
Checklist by scenario
All website migrations
- Record the current state. Write down the current DNS provider, A and CNAME records, MX records, TXT records, nameservers, PHP or Node version, database engine, webroot, redirects, scheduled jobs, and third-party integrations. A DNS record inventory prevents an apparently successful website move from breaking business email or verification services. See DNS Records Explained for a record-by-record reference.
- Choose a maintenance window. Select a period with lower traffic and avoid launches, campaigns, billing runs, or content releases. For stores, membership sites, forums, and other database-driven sites, plan a short write freeze or a final synchronization procedure.
- Back up before changing anything. Save a complete copy of site files, databases, environment variables, deployment configuration, and DNS records. Store at least one copy outside the old host. Verify that the database backup can be opened or restored; a backup that has never been tested is not a reliable rollback plan.
- Prepare the new account. Match required runtime versions and install the application, database, dependencies, and server configuration. Do not assume the new provider uses the same document root, permissions, rewrite rules, firewall defaults, or mail settings.
- Test privately. Use the host’s preview address, a temporary subdomain, a local hosts-file override, or another access method that does not alter public DNS. Check representative pages, administrator access, forms, uploads, search, redirects, APIs, and error logs.
WordPress
For WordPress, copy the wp-content directory, database, and any required configuration files. Confirm the site URL and home URL, database credentials, filesystem permissions, permalink rules, and PHP compatibility. A migration plugin can simplify a small site, while command-line tools such as database export and search-and-replace utilities may be more predictable for larger installations. Test with caching and security plugins enabled, because they can change redirects, cookies, or access rules.
If content, orders, comments, or user registrations continue during the copy, perform a final database export near cutover or temporarily disable writes. Do not rely on an old database snapshot for a busy site.
Static sites
Build the site from the same commit or release artifact that is currently live. Verify the output directory, asset paths, canonical URLs, redirects, custom error pages, forms, and cache headers. Static deployments are often easier to roll back: keep the previous build available and repoint the deployment or DNS target if testing reveals a defect.
Node.js and PHP applications
Document runtime versions, package-lock or equivalent dependency files, process managers, environment variables, database migrations, web server rules, and background workers. Keep secrets out of copied public directories. Run health checks against the new instance and confirm that logs, queues, file uploads, and scheduled jobs operate under the new account.
DNS and email
Reduce the TTL of records you will change, commonly to a few minutes, at least several hours and preferably a day or two before the cutover. The useful lead time depends on the previous TTL and resolver behavior; lowering it immediately before the change cannot reliably accelerate caches that already hold the old value. Do not change MX, SPF, DKIM, or DMARC records unless email is also moving. For broader DNS troubleshooting, use the DNS propagation guide.
What to double-check
Database consistency
Compare the newest content on the old and new environments. Check timestamps, user accounts, orders, comments, and uploaded media. If the application accepts writes, place it in maintenance mode or freeze writes during the final export. For high-change applications, a one-time copy may not be enough; use a documented synchronization method or schedule a short, controlled outage.
SSL and HTTPS
Test both HTTP and HTTPS, the certificate chain, automatic HTTP-to-HTTPS redirects, and every hostname in use, including www and any API or staging hostname. Certificates are generally tied to domain names rather than a hosting account, but the new server still needs the certificate, private key, or a fresh issuance process.
With Let’s Encrypt or another ACME client, verify that the new host can complete domain validation and that DNS, HTTP, or TLS validation paths are available as required. Avoid repeatedly requesting certificates while troubleshooting: certificate authorities apply issuance and validation limits, and failed attempts can delay further testing. Test renewal before the migration is considered complete, and confirm that port access, webroot permissions, and renewal hooks are correct. See SSL Certificate Errors Explained for common HTTPS failures.
Application behavior
- Open the homepage, key landing pages, and representative deep links.
- Submit forms and confirm delivery, spam handling, and CRM or webhook integrations.
- Test login, logout, password reset, sessions, uploads, search, and checkout where applicable.
- Check redirects, canonical tags, robots rules, XML sitemaps, and analytics identifiers.
- Review server, application, PHP, Node, database, and security logs for errors.
- Confirm backups, monitoring, cron jobs, queues, and deployment access on the new host.
Cutover and rollback
At cutover, complete the final file and database sync, apply any maintenance notice, change only the necessary DNS records, and record the exact time and values. Check the site from multiple networks and use DNS lookup tools to observe which address different resolvers return. Keep the old host intact while traffic shifts.
Define rollback in advance: restore the previous DNS values, stop writes on the new system if needed, preserve logs, and identify which database is authoritative. Rollback is safest when the old site has not accepted conflicting changes. Do not delete the old account until the new site has remained stable through normal traffic, scheduled tasks, email flows, and at least one verified backup cycle.
Common mistakes
- Changing nameservers too early: this can make it harder to correct one missing record and may affect email unexpectedly. Change the smallest necessary DNS element.
- Copying files but not configuration: environment variables, rewrite rules, cron definitions, database credentials, and secrets are easy to overlook.
- Testing only the homepage: broken forms, uploads, redirects, APIs, and administrator routes often appear only on deeper workflows.
- Forgetting non-web DNS: MX, TXT, DKIM, verification, and subdomain records may belong to services unrelated to the website.
- Requesting SSL certificates repeatedly: diagnose DNS and validation first, then issue or renew once the new host is ready.
- Closing the old host immediately: premature cancellation removes your easiest comparison point and rollback option.
- Ignoring caching: purge application, server, CDN, and browser caches only after confirming that the new origin is correct.
When to revisit
Use this checklist before every planned move to new web hosting, major DNS change, platform rebuild, or infrastructure upgrade. Revisit it before seasonal traffic periods and before campaigns that make rollback more difficult. It is also worth updating whenever a provider changes its control panel, migration utility, SSL workflow, backup system, or runtime defaults.
After migration, schedule a short review to confirm certificate renewal, backups, monitoring, billing ownership, access credentials, and DNS documentation. Compare performance and resource use with the previous host using the web hosting performance audit. Finally, update your internal runbook with the actual DNS values, cutover time, rollback steps, and any provider-specific commands. That record turns the next website migration from an improvised outage risk into a repeatable launch process.
