A hosting migration is more than copying website files. This checklist gives you a repeatable process for moving web hosting, domains, DNS, email, databases, and SSL with controlled risk, clear checkpoints, and a practical rollback plan.
Overview
Website hosting migration means transferring a website and its supporting services from one hosting environment to another. Depending on the setup, that may include application files, databases, scheduled jobs, domain settings, DNS records, email, SSL certificates, backups, and third-party integrations.
The safest approach is to treat the move as a controlled change rather than a single switch. First, document the current environment. Then build and test the destination, reduce avoidable DNS delays, copy the latest data, and change traffic only when the new host is ready. Keep the old hosting account available until the new environment has passed a defined observation period.
This workflow applies to many sites, including content-managed websites, online stores, business websites, and custom applications. The exact commands will differ by platform, but the checkpoints remain useful whether you use shared hosting, managed cloud hosting, or a developer-oriented deployment workflow.
For broader planning, compare your requirements against a cloud hosting selection process before beginning the migration. A new host should match the site’s software, resource needs, security requirements, and operational skills.
What to track
1. Build an inventory before changing anything
Record every service that depends on the current host or domain. At minimum, capture:
- All domains, subdomains, aliases, and redirects.
- DNS records, including A, AAAA, CNAME, MX, TXT, and verification records.
- Website files, databases, uploads, configuration files, and environment variables.
- Email accounts, forwarding rules, mailboxes, and external email providers.
- SSL certificates, renewal arrangements, and HTTPS redirect rules.
- Cron jobs, background workers, webhooks, APIs, payment connections, and analytics tools.
- Current PHP, runtime, database, web server, and operating system versions where relevant.
- Access details for the registrar, DNS hosting provider, hosting control panel, deployment system, and backup storage.
Do not rely on memory or on a hosting control panel’s summary page. Export the DNS zone if the provider supports it, and save a copy of important configuration files in a secure location. This inventory becomes the migration checklist and the reference for post-cutover verification.
2. Verify backups and recovery options
Create separate backups of the website files, database, email data where supported, and DNS configuration. A backup is useful only if it can be restored, so test at least one restoration path before the move. Check the backup date, file size, database completeness, and storage location.
For a site that receives orders, registrations, comments, or other changing data, identify the final data synchronization step. Copying the database several hours before cutover may leave new records behind. A short maintenance window, temporary write restriction, or final database export may be appropriate depending on the application. The website backup strategy guide provides a useful framework for reviewing this part of the process.
3. Prepare the destination without changing public traffic
Set up the new hosting account, application runtime, database, storage, users, permissions, and deployment process. Copy the site to a temporary hostname or staging address. If the application uses environment variables, update them carefully for the destination database, cache, storage, email, and third-party services.
Test the site using a hosts-file entry, a provider preview URL, or another private method. Check pages that are easy to overlook: login forms, search, contact forms, file uploads, checkout steps, image processing, redirects, admin areas, API calls, and scheduled tasks.
4. Review DNS and email separately
Website traffic and email do not necessarily use the same destination. Change only the records required for the website unless the migration also includes email. Preserve MX, SPF, DKIM, DMARC, verification, and service records when they are still valid. Removing an unrelated TXT or CNAME record can disrupt email delivery or an external service.
Before cutover, lower the TTL for records you expect to change, subject to the existing provider’s controls. This may make future resolver refreshes more frequent, but it does not force every cached result to update immediately. Use a DNS propagation checker and troubleshooting process to compare results from different networks after the change.
5. Plan SSL before the domain points to the new host
Confirm how the new platform issues or imports SSL certificates. If certificates are automatically issued, ensure the domain resolves correctly and that any required validation records or HTTP paths are available. If you are importing a certificate, confirm the certificate, private key, and intermediate chain are handled securely.
Test both HTTP and HTTPS behavior, including redirects, canonical URLs, mixed-content warnings, cookies, and administrative pages. Do not assume that an active certificate means the whole website is correctly configured. A site can have valid encryption while still pointing some assets or subdomains to the old environment.
Cadence and checkpoints
Use the following sequence as a migration runbook. Assign an owner to each task and record the completion time.
- One to two weeks before: document the inventory, confirm account access, select the destination, check compatibility, and verify backups.
- Several days before: build the destination, copy files and databases, configure SSL, recreate scheduled jobs, and test the site privately.
- Before cutover: review DNS records, confirm email routing, lower relevant TTL values, communicate the maintenance window, and freeze nonessential changes.
- At cutover: take a final backup, synchronize changing data, place the site in maintenance mode if needed, update only the planned DNS records, and record the exact change.
- Immediately after: test DNS answers, HTTPS, the homepage, important templates, forms, logins, database writes, email sending and receiving, redirects, and third-party integrations.
- During the observation period: monitor error logs, uptime, response times, resource use, certificate status, email delivery, and user reports. Keep the old host intact until these checks are satisfactory.
- After stabilization: take a fresh backup of the new environment, update documentation, remove temporary access, and cancel the old service only after confirming that no required service still depends on it.
For a more detailed zero-downtime sequence, compare this runbook with the cloud hosting migration checklist. The practical objective is not to promise that every migration will have no interruption; it is to make any interruption brief, visible, and recoverable.
How to interpret changes
Unexpected results after a migration are easier to diagnose when you separate DNS, application, infrastructure, and email symptoms.
- Some networks show the old site: DNS caching or multiple records may be involved. Compare authoritative DNS answers with recursive resolver results before changing records again.
- The domain resolves but displays an error: Check the web server’s virtual host, application configuration, database connection, file permissions, runtime version, and error logs.
- HTTPS fails or redirects incorrectly: Verify certificate coverage, the selected domain, proxy settings, redirect rules, and application-generated URLs.
- Email stops arriving: Review MX records first, then SPF, DKIM, DMARC, mailbox provisioning, forwarding, and any changes to the email provider.
- The site is slower: Compare page-level response times, database queries, cache behavior, image delivery, geographic routing, and resource saturation rather than judging the entire platform from one test.
- Orders or form submissions are missing: Check whether writes reached the old database during the transition and compare application logs with transaction records.
A rollback should be based on predefined conditions, such as unrecoverable application errors, failed transactions, broken email, or unacceptable data inconsistency. If rollback is required, restore the previous DNS records, confirm the old site is still operational, preserve logs from both environments, and investigate before attempting another cutover.
After stabilization, use the website speed testing workflow and the uptime and performance checklist to establish a new baseline rather than comparing results informally.
When to revisit
Review this migration checklist monthly during the first quarter after a move, then at least quarterly for an active business website. Revisit it immediately when the domain, DNS hosting provider, email system, SSL process, hosting plan, application stack, or deployment workflow changes.
At each review, confirm that backups still run and can be restored, domain and certificate renewals have an owner, DNS records are documented, monitoring alerts reach the right people, and the rollback instructions still match the live environment. Check resource trends as well: sustained increases in traffic, storage, database size, or background jobs may require a hosting adjustment before performance becomes a user-facing problem. The cloud hosting sizing guide can help structure that review.
Keep a short change log with the date, reason for each infrastructure change, records modified, tests completed, and unresolved issues. This turns a one-time hosting migration checklist into an operating document. When the next move is needed, the team can work from verified information instead of reconstructing the website’s dependencies under pressure.
Final action: copy this checklist into your operations system, assign owners to the inventory, backup, cutover, monitoring, and rollback tasks, and schedule the next quarterly review before closing the migration.
