Before moving a WordPress website to a new host, confirm that you can restore the whole site, keep business email working, test customer inquiries, preserve important URLs, switch traffic safely, and reverse the move if something breaks. That is the practical WordPress hosting migration checklist. A homepage that loads is not enough evidence that the move worked.
For a small business, the real risk is often invisible: a quote form stops delivering messages, a mailbox loses incoming mail, or a booking integration quietly points to the old server. A migration is successful when the business can keep operating—not merely when the new hosting account says “active.”
First, know what is actually moving
Your domain name, website hosting and email service may be managed by three different companies. Changing your website host does not automatically mean transferring your domain registration or moving your email. Write down who controls each one before anyone changes settings.
Ask the person managing the move to identify the current host, the destination host, the domain registrar, the DNS provider and the email provider. Include any content delivery network (CDN), external forms, payment processor or scheduling service. If nobody can answer those questions, the migration is not ready to start.
Six proofs to collect before the switch
1. A backup that can actually be restored
Get a complete, recent copy of both the WordPress files and the database. Files include uploads, themes, plugins and configuration; the database contains pages, posts and many site settings. A downloaded archive is useful, but a successful test restore is stronger evidence. Keep the backup somewhere independent of the host you are leaving.
If your site accepts orders, reservations or other changing records, agree on how new data will be handled during the move. Copying a live database once and switching hours later can leave later submissions behind. For more detail, see our WordPress backup recovery check.
2. A working copy on the destination server
Build and test the new site before sending public traffic to it. Check the homepage, at least one service page, images, navigation, mobile layouts, logins and any important plugin functionality. Confirm that the new host supports the site’s current PHP version and required extensions. Test over HTTPS with a valid certificate.
A temporary testing address or a local hosts-file preview can help, but avoid accidentally exposing an unfinished copy to search engines. Remove any temporary noindex or access restrictions from the production site at launch. The official WordPress migration documentation explains the file, database and URL considerations behind a move.
3. Business email that stays separate from the website change
Before touching DNS, record the existing MX records and relevant mail authentication records, including SPF, DKIM and DMARC where configured. Confirm whether email stays with the current provider. A website-only migration usually should not change mail routing without a separate reason and plan.
Send a message to and from a business mailbox after the change. Also test email generated by WordPress, such as form notifications and password resets; those may use a different delivery path from normal mailbox email. A successful form submission screen does not prove the notification arrived. Our contact form delivery troubleshooting guide covers that distinction.
4. Important URLs and search settings preserved
List the pages that matter: homepage, service pages, location pages, contact page, high-traffic articles and any downloadable resources. Check that each still works on the new host. Keep page addresses, canonical tags, robots directives and sitemap behavior consistent unless you are intentionally changing them.
Important distinction: moving to a new server while keeping the same domain and page URLs does not, by itself, call for a blanket set of 301 redirects. If you also change domains or URL paths, you need an old-to-new URL mapping and appropriate permanent redirects. Google’s site-move guidance specifically separates hosting-only infrastructure changes from URL changes. Do not combine a redesign, domain change and hosting move casually if they can be staged.
5. A tested DNS cutover and rollback plan
Confirm which DNS records will change, who can change them and who can restore the previous values. A records, AAAA records and sometimes CNAME records may be relevant, depending on the setup. Lowering a DNS record’s time to live (TTL) ahead of a planned switch can help some caches refresh sooner, but it does not guarantee instant global propagation.
Schedule the change for a time when someone can monitor the site. Keep the old hosting account available long enough to verify traffic and business functions on the new host. Write down the exact rollback trigger—such as a failed payment flow or unavailable site—and who has authority to act. Returning DNS to its prior values may not reverse database changes made after the switch, so the data plan matters too.
6. Evidence that real customer actions still work
Run the actions customers actually take. Submit a test inquiry and confirm both the on-screen success state and its arrival in the intended inbox or CRM. Test click-to-call links, maps, downloads, checkout if applicable, and mobile navigation. Confirm analytics and conversion tracking still fire as expected, without mistaking a test submission for a genuine lead.
Then repeat a short version of the test after DNS changes and again after the initial transition period. The destination server can be healthy while a third-party integration remains broken.
A simple go/no-go decision
Before approving the move, ask for six pieces of evidence: a restorable backup, a tested destination copy, verified email routing, preserved key URLs, a written cutover/rollback plan, and a successful end-to-end customer inquiry. If one is missing, identify the gap and resolve it before switching. This is a practical decision framework, not a promise that every possible issue has been eliminated.
For example, suppose the new homepage loads perfectly but the quote form sends messages to an old mailbox. That move is not finished. Likewise, a working form is not enough if a domain change leaves your main service pages returning errors. The checks protect different parts of the same customer journey.
What to request from your website provider afterward
Ask for a short handoff record showing the migration date, current hosting and DNS ownership, where backups are stored, who maintains the SSL certificate, which forms and integrations were tested, and any remaining follow-up items. You do not need a fifty-page technical report. You need enough information to know who is responsible if something stops working next week.
Moving hosting can be a sensible improvement, but it should not become a mystery project. If you’re planning a WordPress move and want help defining a safe scope, request a discovery conversation with Grassroots. The first step is understanding what your site depends on and what must keep working.
Built in collaboration with ChatGPT.
