A business website hosting migration checklist should start with a simple question: what depends on the current host? Your site may be the most visible part, but customer inquiries, business email, domain settings, and backups can involve different accounts and providers. Sorting out those connections before the move makes it easier to spot problems while you can still fix them.
Use the checkpoints below whether someone else is handling the technical work or you are coordinating it yourself. A host-only move is also different from a redesign or a change to your page URLs. If either is planned, treat it as a separate project rather than adding it to the hosting switch at the last minute.
Before choosing a new host: map what you have
Make a short inventory that you and the person handling the move can both use. For a small business, it should answer these questions:
- Domain: Where is it registered, who can sign in, and who receives account notices?
- DNS: Where are the authoritative DNS records managed, and who can edit them?
- Website: What software, database, files, forms, integrations, and scheduled tasks does it use?
- Email: Who provides the mailboxes, and does any website form send through that service?
- Backups: Where is a recent copy stored, who can access it, and has a restore been tested?
- Inquiries: Where do contact-form submissions go, and are copies saved inside the website?
Do not assume that your domain, website, and email are all with the same company. Moving the website does not, by itself, require transferring the domain registration. Find out who controls each account before agreeing to a migration plan.
Ask the prospective host how your particular site will be moved and tested. A static site may have different requirements from a site with a database or customer-facing forms. Confirm who will handle backups, the test environment, DNS changes, and post-launch checks. If you want to understand the ongoing responsibilities as well as the move, read about what managed hosting typically includes.
Before changing DNS: prepare a recoverable copy
Back up the parts needed to rebuild the working site, not just the files you can see in a browser. Depending on how the site is built, that may include a database, uploaded images and documents, application settings, configuration files, and form data stored on the old server. Keep the backup somewhere you can access independently of the hosting account you may later close.
A backup is more useful when someone has confirmed it can be restored. Ask who will do that test and what they will check afterward. If backup decisions are still unclear, this guide to website backup planning can help frame the conversation.
Next, copy the site to the new environment and test it before public traffic is directed there. Your provider may offer a private preview or staging method. The important point is to view the new site without assuming that its working homepage proves the whole migration is ready. Keep any temporary test site from being treated as the public version, and check that test-only settings do not carry over to the live site. Here is a closer look at using a staging environment for website changes.
Run a plain-language acceptance test
- Open important pages on a computer and a phone. Check navigation, images, downloads, and any page customers use to contact you.
- Confirm the expected domain loads securely over HTTPS without browser warnings.
- Send a test inquiry through each important form. Verify that it reaches the intended inbox and, if applicable, appears in the website's saved submissions.
- Check features that depend on a database, an outside service, or a scheduled task.
- Confirm that the public site can be accessed and that temporary restrictions meant for testing are not left in place.
Before the switch: compare DNS and protect email
DNS tells visitors and other services where to find your website and mail. A hosting change often calls for updating the records that direct web traffic, such as A, AAAA, or CNAME records. It does not necessarily call for changing records used by business email. Record the current settings before editing anything, and have the person making the change explain which entries will change and which will stay.
If DNS is being moved to a new provider, compare the proposed records against the current DNS zone entry by entry. Do not rely on an automatic import as your only check: Cloudflare's DNS scan documentation explains that a scan may not find every record. Custom entries for mail, verification, or other services deserve particular attention.
Ask specifically about MX records and mail-related TXT or CNAME records. If email remains with its current provider, its required DNS settings generally need to remain in place even though the website is moving. Confirm where business mailboxes live, then test sending and receiving after the DNS change. A website form that sends email needs its own test too: a working mailbox does not prove that form notifications are arriving.
Plan who will make the DNS change and who will be available to check the result. DNS changes can take time to be seen everywhere, so avoid making the switch just before the old environment becomes unavailable. Keep the old site available while you verify the new one, and agree in advance on what would trigger a rollback.
Immediately after launch: follow the customer journey
Open the site using its public domain and repeat the acceptance test. Check the homepage, but also follow the path a customer would take: find a service page, open a download, submit an inquiry, and look for the resulting message. Confirm that HTTPS works on the public domain and that both expected versions of the domain behave as intended.
Pay special attention to forms during the cutover. While DNS changes are being picked up, some visitors may reach the old site while others reach the new one. If submissions are stored on the website, check both locations and make a plan to preserve any inquiries that arrive during that period. Do not assume that copying the database before the switch captured the final submissions.
Check that the pages you expect search engines to access are available and that any testing restrictions have been removed from the public site. If the move keeps the same visible URLs, follow Google Search Central's guidance for changing hosting without changing URLs. If you are also redesigning pages or changing URLs, that is a broader migration with additional checks. A hosting move alone is not a reason to change every address.
Before canceling the old host: close the gaps
Wait until the new site has passed its public checks and you have reviewed the old environment for late form submissions or content changes. Confirm that business email still sends and receives, important DNS records match the intended setup, and the person responsible for the site can access a usable backup of the new environment. Save anything from the old account you may need later, including records of settings or files that were not part of the site copy.
Then confirm which account can be canceled. The old hosting account may be separate from the domain registration, DNS service, or email service. Canceling the wrong one could affect a service you meant to keep.
Make the move a verified handoff
A successful migration is not simply a new homepage loading. It is a working site, delivered inquiries, functioning email, correct DNS, and a backup you can use. Your next step is to share your inventory with the person planning the move and ask them to walk through each pre-launch and post-launch check before scheduling the switch.