Moving a website to new hosting can be routine when the work is planned, but an incomplete transfer can cause broken pages, missing orders, failed emails, or avoidable downtime. This website migration checklist provides a reusable workflow for preparing the move, copying files and databases, testing the new environment, changing DNS, validating SSL and email, monitoring the cutover, and deciding when to revisit your migration plan.
Overview
A hosting transfer is more than copying website files from one server to another. A complete migration includes the application, database, domain configuration, SSL certificate, scheduled tasks, email records, redirects, integrations, and operational checks that keep the site working after the move.
The safest approach is to treat the existing host as the production environment and the new host as a test environment until validation is complete. Keep the current site online while you prepare the destination, create a recent backup, transfer the data, and test the site using a temporary URL or hosts-file override. Only then should you update DNS.
Timing matters. Lowering the DNS time-to-live (TTL) before the change may help resolvers refresh records sooner, but it does not eliminate propagation differences. For that reason, plan a monitoring window after the DNS cutover and retain access to the old hosting account until traffic, forms, transactions, and email are confirmed on the new system.
If you are comparing infrastructure before a migration, review cloud hosting, VPS, and shared hosting options. The destination should match the website's resource needs, software requirements, traffic patterns, and maintenance capacity.
What to track
1. Create an inventory before copying anything
Record the parts of the current setup that must be reproduced. At minimum, document:
- Domain names, subdomains, parked domains, and domain registrar access.
- DNS records, including A, AAAA, CNAME, MX, TXT, and verification records.
- Website files, application code, uploads, themes, plugins, and server configuration.
- Databases, database users, credentials, character sets, and connection settings.
- PHP, Node.js, Python, or other runtime versions and required extensions.
- Cron jobs, background workers, queues, webhooks, API keys, and third-party integrations.
- Email mailboxes, forwarding rules, aliases, and spam-filter settings.
- SSL certificates, redirect rules, cache settings, firewall rules, and access restrictions.
DNS is especially easy to overlook because it may be managed separately from hosting. Use the DNS records guide to identify which records support the website and which support email or external services.
2. Back up and verify the source
Take a full backup of website files and databases shortly before the final transfer. Keep at least one copy outside the current server. A backup is useful only if it can be opened or restored, so check that the archive contains the expected files and that the database export completes without errors. For a broader backup workflow, see how to back up a website and test restoration.
For a WordPress migration, include the wp-content directory, configuration file, database, media library, and any server-level rules. Put the site into maintenance mode only if the final data copy requires it; otherwise, schedule a brief content freeze for the last synchronization.
3. Prepare and test the destination
Set up the new hosting account before changing DNS. Create the database and user, configure the required runtime, upload the files, import the database, and update connection details. Confirm that file permissions are appropriate and that the application can write to directories such as uploads, cache, or temporary storage.
Test the site without exposing it as the public destination. Check the homepage, representative content pages, search, login, forms, media, checkout or booking flows, and any authenticated areas. Review error logs while testing rather than relying only on what appears in the browser.
4. Validate URLs, SSL, and redirects
Confirm that the site's canonical domain, HTTPS settings, and application URL are correct. Test both the preferred hostname and common alternatives, such as HTTP and the www or non-www version, to ensure redirects behave as intended. Check internal links, image URLs, canonical tags, robots directives, XML sitemaps, and important 301 redirects.
Do not assume SSL is ready because the certificate was installed. Load key pages over HTTPS, check for mixed content, and verify that forms and external integrations still work. The guide to SSL certificates and validation can help clarify which certificate setup your site requires.
5. Protect email and external services
Before changing nameservers or DNS records, identify every service that depends on the domain. Preserve MX records for email and copy required SPF, DKIM, DMARC, verification, and service-specific records. If email is hosted separately from the website, changing web hosting should not require moving mailboxes, but an incorrect DNS update can still interrupt delivery.
Test sending and receiving from representative mailboxes after the cutover. Also test payment providers, analytics, contact forms, CDN settings, webhooks, API callbacks, and any integrations that use the old server address or domain configuration.
Cadence and checkpoints
Use the following checkpoints as a repeatable website migration checklist:
- Several days before: choose the migration window, document the current configuration, confirm access to the registrar and both hosting accounts, and prepare the new environment.
- Before the final copy: create and verify backups, reduce DNS TTL if appropriate, freeze major content changes, and copy the latest files and database.
- Immediately before DNS changes: test the destination, confirm SSL, review redirects, verify email records, and record the rollback steps.
- At cutover: update the relevant A, AAAA, CNAME, or nameserver records. Change only what is necessary, and save the previous values.
- During the first hours: monitor DNS resolution, uptime, response times, server errors, forms, logins, transactions, and email.
- After propagation: compare the new site with the old one, review analytics and search-console signals if available, and keep the old environment intact until the migration is stable.
For a high-change website, schedule a second database or file synchronization immediately before cutover. For a mostly static site, a single verified copy may be sufficient. Ecommerce, membership, publishing, and booking sites generally need extra care because new orders, accounts, or submissions can be created while the migration is in progress.
How to interpret changes
Not every warning after a migration has the same cause. A sudden increase in server errors usually points to missing files, incompatible runtime settings, incorrect permissions, database credentials, or unavailable extensions. A site that loads but loses styling or images may have incorrect paths, blocked assets, or incomplete uploads.
If the website works but forms or payments fail, inspect API credentials, webhook URLs, firewall rules, SSL validation, and outbound connection settings. If visitors report that the site works inconsistently, compare DNS answers from different networks and check whether some records still point to the old host.
Performance changes should be measured against a baseline rather than judged from one browser session. Track representative page load times, server response time, error rates, uptime, and resource usage. A migration is not automatically an optimization project; first establish functional parity, then make performance changes separately so that problems remain easy to isolate. See the website uptime and speed guide for a practical monitoring framework.
Keep a rollback plan that names the person responsible, the previous DNS values, the last known-good backup, and the conditions that trigger a reversal. Rollback may not undo every change made after cutover, so maintain a clear content freeze or synchronization process until the new host is accepted.
When to revisit
Review this checklist before every hosting transfer, domain move, major infrastructure change, or platform rebuild. Revisit it monthly or quarterly as an operations exercise even when no migration is planned. Confirm that backups still restore, registrar access is current, DNS ownership is documented, monitoring alerts reach the right people, and the rollback procedure is still realistic.
Update the inventory after adding a subdomain, email provider, CDN, payment integration, scheduled job, or security service. Review it again after changing hosting plans, moving from shared hosting to VPS or cloud hosting, upgrading application versions, or introducing a staging environment.
For the next migration, turn the process into a recorded runbook. Mark each item as complete, capture the old and new values, note test results, and record any issue that required manual intervention. A reusable runbook reduces guesswork and makes the next hosting transfer safer.
Final action checklist: verify a restorable backup, inventory DNS and integrations, prepare the destination, test before cutover, preserve email records, validate HTTPS and redirects, monitor after DNS changes, and do not close the old hosting account until the new site has passed its post-migration audit.
