Moving a website to a new hosting provider is manageable when the work is treated as a controlled change rather than a single upload. This website migration checklist covers preparation, backups, staging, DNS, email, testing, launch sequencing, rollback planning, and the recurring checks that help you protect data and search visibility after the move.
Overview
A hosting migration usually involves more than copying website files. Depending on the site, you may need to move a database, preserve scheduled tasks, recreate email accounts, install an SSL certificate, update DNS records, and verify that external services still work. The safest approach is to separate the migration into four stages:
- Prepare: document the current environment, reduce avoidable risks, and create recoverable backups.
- Build: reproduce the website on the new host without changing the live site.
- Test: check content, functionality, performance, forms, integrations, and technical SEO.
- Launch and monitor: change traffic routing, confirm the new site is serving correctly, and retain a rollback option.
The exact controls differ between shared hosting, managed WordPress hosting, cloud platforms, and VPS environments. The underlying principle remains the same: make the new environment ready before changing the domain's DNS, and keep the old environment available until the new one has been verified.
If you are still comparing providers, assess support, backup controls, server access, resource limits, and the migration tools included in each plan. A practical starting point is this comparison of web hosting for small businesses.
What to track
1. Record the current environment
Before copying anything, create a migration record. Note the current host, control panel, PHP or application runtime version, database type, document root, SSL setup, DNS provider, CDN configuration, cron jobs, and third-party integrations. Also list every subdomain that must continue working.
Capture the current DNS records, including the website's A or AAAA records, CNAME records, MX records for email, and TXT records used for verification or email authentication. DNS changes are easier to troubleshoot when you know what existed before the migration. For background, see DNS records explained.
2. Create and verify backups
Make at least one complete backup of the website files and one database export. If email is hosted on the old provider, identify how mailboxes and messages will be preserved. Store backups outside the server being replaced, and check that the archive can be opened or restored. A backup that has never been tested is only an assumption, not a reliable rollback plan.
For a database-driven website, record the database name, username, host, character set, and table prefix where relevant. Keep credentials in a secure password manager rather than in a shared document or public repository.
3. Prepare the destination
Create the domain, database, users, mailboxes, and application environment on the new host. Match the required runtime and extensions before importing the site. Upload the files and restore the database using the host's tools, command-line utilities, or a migration tool appropriate to the application.
Do not point the public domain to the new host yet. Use a temporary hostname, hosts-file entry, staging URL, or provider preview address to inspect the copied site. If the application stores its base URL, configure it carefully so that testing does not create unwanted redirects or duplicate content.
4. Test the parts that are easy to overlook
- Homepage, key landing pages, navigation, search, and contact forms.
- Logins, account areas, checkout flows, subscriptions, and other transactional paths.
- Images, downloadable files, embedded media, and internal links.
- Database writes, comments, orders, bookings, or other content created by visitors.
- Scheduled tasks, background jobs, webhooks, API connections, and analytics tracking.
- Robots.txt, XML sitemaps, canonical URLs, redirects, and indexability settings.
- HTTPS, certificate coverage, mixed-content warnings, and both www and non-www versions.
For WordPress sites, review the site URL, permalink structure, active plugins, media library, scheduled actions, and administrator access. Avoid making broad plugin or theme changes during the migration unless they are necessary for compatibility; changing too many variables makes problems harder to isolate.
Cadence and checkpoints
Use a written checklist and assign a status to each item: not started, in progress, verified, or blocked. A simple migration log should include the task, owner, timestamp, evidence of completion, and rollback action if it fails.
Before the migration window
- Confirm that the new host can run the application and handle its storage, memory, and traffic requirements.
- Lower DNS TTL in advance if your DNS provider permits it and if you understand the effect on existing resolvers.
- Take a fresh file and database backup close to launch.
- Freeze nonessential content changes or record every change made after the initial copy.
- Confirm access to the domain registrar, DNS provider, old host, new host, and email administration.
- Choose a low-risk launch window and define who can approve a rollback.
During launch
Complete one final database sync if the site receives ongoing orders, registrations, form submissions, or other writes. Update the relevant DNS records, then monitor propagation from several networks or DNS-checking tools. DNS changes may not appear everywhere at the same time, so do not immediately cancel the old hosting account.
As traffic begins reaching the new host, test the canonical domain over HTTPS. Confirm that redirects resolve once, forms deliver messages, email continues to send and receive, and no maintenance or staging setting remains enabled.
After launch
Review server logs, application logs, uptime checks, error reporting, analytics, and search performance. Compare the new site's key URLs and response behavior with the old environment where possible. Keep the old site intact for an agreed observation period, subject to your backup and data-retention requirements.
How to interpret changes
Not every difference indicates a failed migration. DNS visibility can vary by resolver, and a cache or CDN may temporarily serve older content. Look for patterns rather than reacting to one isolated check.
A sudden rise in 404 errors usually points to missing files, changed permalinks, or an incomplete database import. A rise in 500-level errors can indicate incompatible runtime versions, missing extensions, incorrect permissions, exhausted resources, or application configuration problems. If forms stop working, inspect SMTP settings, API credentials, firewall rules, and application logs rather than assuming the DNS change is the only cause.
A traffic decline deserves a technical review before it is attributed to the host. Check that the site is indexable, the canonical domain is correct, redirects preserve important paths, the XML sitemap is accessible, and analytics tracking still loads. Use a redirect map for any URLs that genuinely changed, and send each old URL to its closest relevant destination rather than sending every page to the homepage.
Performance should also be interpreted in context. Compare like with like: the same page, cache state, device type, geographic test location, and CDN configuration. If the new site is slower, investigate caching, image delivery, database queries, server resources, and application configuration. This guide to caching, CDNs, and image optimization can help structure that review.
When to revisit
Revisit this migration checklist at least monthly during the first few months after launch, then include it in a quarterly website maintenance review. The goal is not to repeat the migration, but to confirm that the controls created for it still work.
At each review, verify that backups complete and can be restored, DNS and SSL details are documented, domain and hosting access are current, monitoring alerts are active, and the old migration notes still describe the live environment. Check storage usage, database growth, error rates, scheduled tasks, email delivery, and the status of critical integrations.
Repeat a full or partial review sooner when the application, domain, host, DNS provider, CDN, payment system, email platform, or server runtime changes. Also revisit the plan after a security incident, unexplained traffic loss, recurring downtime, or a major website redesign.
Final action checklist: export current DNS records, confirm a tested backup, document the rollback path, stage the destination, test important user journeys, schedule the DNS change, monitor logs and analytics after launch, and retain the old environment until the new one is demonstrably stable. Treat these records as living operational documentation so the next website move is faster, safer, and easier to audit.
