A hosting move is safest when treated as a controlled change rather than a single upload. This website migration checklist shows how to inventory the current environment, prepare DNS, copy files and databases, test a staging version, protect email delivery, plan the cutover, and monitor the new host after launch. It also gives you recurring checkpoints so migration records remain useful for future moves, platform changes, and troubleshooting.
Overview
Moving a website to new hosting can often be completed with little or no visible interruption, but that depends on preparation. The objective is not simply to transfer files. You must reproduce the application, preserve its data, maintain domain and email services, verify security settings, and keep a rollback option available until the new environment has proved stable.
Start by deciding what is actually moving. A basic site may include web files, a database, uploaded media, scheduled tasks, SSL certificates, DNS records, email-related records, and third-party integrations. A WordPress installation may also depend on plugins, themes, configuration values, caching rules, and PHP or database versions. Record these dependencies before making changes.
Hosting capacity and architecture matter as well. If you are changing from shared hosting to VPS hosting or cloud hosting, document the differences in web server software, storage paths, permissions, firewall rules, backups, and deployment procedures. The guide to shared hosting, VPS, and cloud hosting can help frame this comparison before you select the destination environment.
What to track
1. Create a current-state inventory
Record the domain names, subdomains, aliases, application URLs, hosting account details, DNS provider, registrar, database names, database users, runtime versions, and storage locations. Include any services that may be overlooked during a transfer:
- Transactional or business email accounts
- Contact forms and SMTP credentials
- Payment, analytics, advertising, and customer-support integrations
- CDN, firewall, cache, and image-optimization settings
- Cron jobs, queue workers, webhooks, and scheduled backups
- SSL certificates and HTTP-to-HTTPS redirect rules
Export or document the existing DNS zone before changing it. Pay particular attention to A and AAAA records for the website, CNAME records for subdomains, MX records for email, and TXT records used for verification or email authentication. The DNS records explained guide provides a useful reference for reviewing these entries.
2. Prepare backups and a rollback copy
Take a complete website backup before the migration. For a database-driven site, save both the database export and the application files. Confirm that the backup can be opened, identify where it is stored, and note the time it was created. Keep an independent copy in offsite or cloud storage rather than relying only on the source host. For a broader process, see the website backup strategy guide.
Do not cancel the old hosting account immediately. It is your fallback while DNS changes are propagating and while you compare the old and new environments.
3. Lower DNS TTL before the move
If you control the DNS zone, review the TTL values before the cutover. A lower TTL may allow resolvers to refresh records sooner, although cached responses can still remain available for a period of time. Make this change well before the planned switch, and record the original values so you can restore them later. DNS propagation is not a single global event; use multiple networks or DNS lookup tools to check what different resolvers return.
4. Build and test the destination
Create the new hosting environment before changing the live DNS records. Transfer the files using the method supported by the hosts, import the database, create the required database user, and update the application configuration with the new connection details. Check file ownership and permissions, runtime versions, rewrite rules, environment variables, and storage paths.
Use a temporary hostname, hosts-file override, or protected staging URL to test the copied site. Avoid exposing a duplicate site to search engines; use access controls and an appropriate noindex approach where applicable. For WordPress, check the site URL, permalink structure, media library, administrator login, plugin compatibility, theme behavior, scheduled tasks, and forms. Test both logged-in and logged-out experiences.
5. Protect email continuity
If email remains with a separate provider, do not replace its MX records with records from the new web host. Confirm that the new server does not accidentally alter MX, SPF, DKIM, or DMARC records. If email is moving too, treat it as a separate migration with its own mailbox export, DNS plan, testing, and rollback procedure. Send and receive test messages before and after the website cutover.
Cadence and checkpoints
Use a simple migration log with an owner, timestamp, change made, result, and next action. This turns a stressful cutover into a sequence of verifiable checkpoints.
- One to two weeks before: inventory the source, choose the target plan, confirm access, review compatibility, and create a tested backup.
- Several days before: prepare the destination, copy the site, lower DNS TTL if appropriate, and test the staging version.
- On cutover day: place the site in maintenance mode if content changes must be paused, take a final database backup, copy any recent uploads, and change only the required DNS records.
- Immediately after: check DNS responses, homepage status, key pages, redirects, forms, logins, checkout or other critical workflows, SSL certificates, email, and error logs.
- After the initial observation period: compare traffic, error rates, response times, storage usage, scheduled jobs, and backup results. Restore normal DNS TTL values once the system is stable.
Keep the old host available until you have confirmed that users are reaching the new server and that no important data is still being written to the old environment. If the site receives orders, registrations, comments, or other frequent updates, plan how to synchronize or freeze those writes during the final transfer.
How to interpret changes
A temporary difference between users is often a DNS caching issue, but do not assume every problem is propagation. If some networks show the new host and others show the old one, compare DNS answers for the relevant A, AAAA, and CNAME records. The guide to DNS propagation explains how to investigate these differences.
If all networks reach the new host but the site fails, inspect application and server configuration instead. A database connection error points toward credentials, hostnames, permissions, or imported data. Missing styles or images may indicate incorrect absolute URLs, file permissions, rewrite rules, or a CDN still pointing to the old origin. A certificate warning usually requires checking the hostname covered by the certificate, the certificate chain, and whether HTTPS redirects were configured correctly.
Watch for less obvious regressions. A successful homepage load does not prove that forms send mail, cron jobs run, backups complete, APIs respond, or authenticated areas work. Review server logs and application logs, then test representative workflows from different networks and devices. If error volume, latency, or failed transactions rises after the switch, use the rollback plan rather than making numerous unrecorded changes under pressure.
When to revisit
Revisit this checklist before every hosting change, major application upgrade, domain transfer, DNS provider change, or infrastructure redesign. A quarterly review is useful for sites that change frequently; a monthly review may be appropriate for high-traffic or business-critical systems. At minimum, review the inventory whenever a new subdomain, integration, email service, scheduled task, or backup destination is added.
During each review, confirm that contact details and account access are current, backups can be restored, DNS records still reflect the intended services, SSL certificates are renewing, and monitoring checks cover the pages and workflows that matter. Remove obsolete records and document exceptions rather than relying on memory.
Before your next move, run this final action list: export the DNS zone, create and verify an offsite backup, record the rollback point, test the destination privately, schedule the cutover during a low-change period, assign someone to monitor it, and keep a written record of every DNS and hosting change. If a DNS problem appears afterward, use the step-by-step DNS troubleshooting guide instead of changing several records at once. That discipline makes future migrations faster, safer, and easier to explain.
