Moving a small business website to a new host is more than copying files. This chronological website hosting migration checklist covers backups, staging, DNS, SSL, email, redirects, forms, analytics, search visibility, uptime monitoring, and rollback planning so you can switch providers with fewer surprises.
Overview
A hosting migration changes where your website is stored and how visitors, email systems, search engines, and third-party tools reach it. The safest approach is to treat the move as a controlled release rather than a single transfer event.
Before beginning, identify every service connected to the website. This may include the domain registrar, hosting account, database, content management system, business email, payment tools, contact forms, analytics, advertising tags, booking software, customer relationship tools, and security services. Record the current setup before changing anything.
Keep a simple migration log with dates, account names, DNS records, test results, and responsible contacts. This record gives you a reference point if something behaves differently after launch. For background on records that commonly affect websites and email, see the small business DNS records maintenance checklist.
A migration normally has five stages: preparation, backup and staging, technical transfer, DNS cutover, and post-launch monitoring. Do not cancel the old hosting account immediately. Keeping it available for a planned overlap gives you a safer recovery option.
What to track
1. Ownership, access, and dependencies
Confirm that you can access the domain registrar, current host, new host, DNS provider, email administration, website administrator account, database, analytics, and payment or form platforms. Check whether any service uses the old server address or hosting provider in its configuration.
Write down renewal dates and billing contacts separately from technical credentials. Use a secure password manager rather than placing passwords in the migration document. If another person controls the domain or email, include them in the schedule before the transfer begins.
2. A complete backup
Create and verify a backup of the website files, database, uploads, configuration files, and email data where applicable. A backup is useful only if it can be restored, so test at least the most important parts on a temporary environment or retain clear restoration instructions.
Record the backup date and location. Take a second backup immediately before the final cutover if the site continues receiving orders, form submissions, comments, or other changing data.
3. Staging and functional tests
Build the site on the new host using a temporary address, staging domain, or host-provided preview method. Protect the staging version from public indexing while it is being tested, and remove that restriction from the production site after launch.
Compare the new version with the live site. Test the homepage, navigation, internal links, images, downloads, search, login areas, checkout or booking flows, contact forms, cookie preferences, and any restricted content. Check both desktop and mobile layouts.
4. DNS, SSL, and email
List the existing DNS records before editing them. Pay particular attention to A, AAAA, CNAME, MX, TXT, and verification records. Some records point the website to its host; others support email delivery, domain verification, security settings, or external services. Changing all records when only the website needs to move can interrupt unrelated systems.
Confirm how the new host will issue and renew the SSL certificate. Test the HTTPS version, confirm that HTTP redirects to HTTPS where intended, and check for mixed-content warnings. Do not assume that an SSL certificate on the old host transfers automatically.
If email is hosted separately, avoid changing MX records unless the migration includes email. If email is moving too, document mailboxes, forwarding rules, aliases, authentication records, and any required export or import process. Send and receive test messages using more than one mailbox.
5. SEO and measurement settings
Save a crawl or URL inventory before the move. Include important pages, canonical URLs, title and description fields, XML sitemaps, robots.txt, structured data, and any pages receiving organic visits or links. A host change alone should not require new URLs, but a simultaneous redesign often does.
If URLs will change, prepare a one-to-one redirect map from every important old URL to its closest relevant new URL. Avoid sending many unrelated pages to the homepage. Confirm that the redirects are server-side and do not create chains or loops. For broader local visibility work after a website or business change, use the local citation audit guide to review external business information separately from the hosting move.
Check analytics, tag management, conversion tracking, search verification, consent settings, and advertising pixels on staging and production. A page can look correct while measurement has silently stopped working.
6. Performance and availability
Record representative page load results from the current site before migration, using the same pages and testing conditions after migration. Look for missing assets, slow database queries, oversized images, server errors, and unexpected caching behavior. Test the homepage, a deep content page, a form page, and any revenue-critical page.
Set up uptime checks for the main domain and, where practical, key subdomains. Monitoring should check more than whether a server responds: review the page status, HTTPS validity, forms, and important transactions manually during the first post-launch period.
Cadence and checkpoints
Use this schedule as a practical migration tracker:
- One to two weeks before: inventory services, confirm access, select the migration window, review backups, and document DNS and email records.
- Several days before: copy the website to staging, test the database and forms, configure SSL, review redirects, and confirm analytics.
- Immediately before cutover: create a fresh backup, check that the new site contains the latest content, lower DNS time-to-live only if appropriate for your setup, and notify anyone handling orders or support.
- During cutover: point the required DNS records to the new host, avoid unrelated DNS edits, and note the exact change time.
- First hour: test the domain with HTTPS, review key pages, submit a test form, check email, and look for server or application errors.
- First day: test from different networks and devices, review analytics and search access, check redirects, and monitor uptime and error logs.
- First week: review traffic, conversions, crawl errors, email delivery, page speed, and customer reports before deciding when to close the old hosting account.
Keep the migration log current as each checkpoint is completed. Mark items as passed, failed, or not applicable rather than relying on memory.
How to interpret changes
A temporary variation after a hosting move is not automatically a failure, but it deserves a clear explanation. A drop in traffic may result from an indexing block, broken redirects, inaccessible pages, changed tracking, DNS propagation, or a simultaneous content change. Compare the timing of the change with your migration log before drawing conclusions.
If visitors report that the site works for some people but not others, investigate DNS resolution, caching, SSL configuration, and network-specific behavior. If the site loads but forms fail, check application credentials, outbound email settings, spam filtering, database permissions, and third-party API restrictions.
For search issues, first confirm that the production site is crawlable and that important pages return the expected status. Review robots.txt, canonical tags, redirects, sitemap access, and accidental password protection. If the move included a domain, brand, address, or phone change, keep website migration tasks separate from local listing updates and maintain consistent business information. The free local business directory submission checklist can help organize those citation tasks.
When a critical function is broken and the cause is not quickly identifiable, use the rollback plan. Restore DNS to the previous host if it is still available, communicate the temporary status internally, preserve logs, and fix the problem in staging before attempting another cutover. Do not delete the old site until the new environment has demonstrated stable operation.
When to revisit
Review this checklist before every hosting change, domain transfer, major redesign, email-provider move, or recovery from a prolonged outage. Even without a planned migration, perform a light review monthly or quarterly. Confirm that backups still run, restoration instructions are current, domain and SSL renewals are visible, contact forms work, analytics records visits, and uptime alerts reach someone who can respond.
Revisit the checklist after adding a subdomain, payment system, booking tool, customer portal, CDN, security service, or new email provider. These additions can introduce DNS, certificate, authentication, or redirect dependencies that were not present during the original move.
To make the next migration easier, keep an up-to-date URL inventory, DNS record list, service ownership register, backup location, and rollback procedure. Review the local business domain and website setup guide when planning a new low-cost web presence, and use the directory submission checklist and citation tracker when a domain or business change also affects local discovery.
Before closing the old host, confirm that the new site, email, forms, redirects, analytics, SSL, and monitoring all pass their checks. Save the final migration log and backup with your operational records. A carefully documented move is not only safer today; it gives you a repeatable process for the next change.
