A hosting migration is one of those jobs that looks easy right up until someone realizes the contact forms stopped sending, the site is showing an old version, or email disappeared on a Monday morning. Knowing how to migrate website hosting is less about moving files and more about protecting the business systems connected to your website while you do it.
For a small business or nonprofit, the goal is simple: move to better hosting without creating a mystery outage for customers, donors, staff, or Google. That takes a plan, a little patience, and a healthy reluctance to click “cancel account” before everything has been checked.
Start with the reason for the move
Not every hosting frustration requires a migration. A slow website might be caused by oversized images, an outdated theme, too many plugins, or poor site maintenance rather than the hosting plan itself. Likewise, a site that goes down occasionally may have a software or security issue that new hosting will not magically fix.
Still, moving makes sense when your host has unreliable uptime, weak security, poor support, limited backups, outdated server technology, or a plan that cannot support your traffic and tools. It can also be a good move when a business has outgrown a bargain hosting package that was fine for a five-page brochure site but is now carrying online appointments, ecommerce, a membership area, or regular marketing campaigns.
Before choosing a new host, make a short list of what the site actually needs. Consider storage, traffic, WordPress compatibility if applicable, automatic backups, security monitoring, staging access, support quality, and whether email is hosted there too. The cheapest option is not always the least expensive once downtime and cleanup work enter the picture.
Inventory what is connected to the website
A website is rarely just a website. It may be connected to domain registration, DNS records, business email, forms, analytics, payment tools, appointment scheduling, CRM systems, newsletter platforms, and third-party services that quietly keep things running.
This is the part people skip because it is not glamorous. It is also the part that prevents a migration from becoming an all-day scavenger hunt.
Document where each core service lives and make sure you can access every account. In particular, identify:
- Your domain registrar, where the domain name is renewed and owned
- Your current hosting account and website administrator login
- Your DNS provider, which may be the registrar, host, or a separate service
- Business email provider and mail settings
- Website platform, theme, plugins, licenses, and any custom code
- Form recipients, payment gateways, booking tools, CRM connections, and tracking codes
- Backup locations and the date of the most recent usable backup
Domain registration, DNS, hosting, and email are related, but they are not the same thing. Treating them as one thing is a common source of trouble. For example, you can move hosting without transferring the domain name. In many cases, that is the simpler and safer choice.
Back up the site before you touch DNS
Create a complete backup before the migration begins. For a WordPress site, that means both the site files and the database. Download a copy somewhere independent of the current host, such as secure cloud storage. Do not rely solely on the host saying that backups exist. Confirm that you can see a recent backup and that it includes what you expect.
If the website includes ecommerce orders, event registrations, donation records, or user accounts, timing matters. You will want to know what changes are made between the initial backup and the final switch. A store receiving orders all day has different migration needs than a site that mostly publishes static information.
It is also wise to take screenshots of important pages and record current settings for forms, redirects, and tracking. They give you a simple reference point if something looks different after the move.
How to migrate website hosting safely
The safest approach is to build and test the website at the new host before changing public DNS. That creates a controlled handoff instead of moving the site live and hoping for the best.
Set up the new hosting account
Choose the right environment for your site. If you use WordPress, install a current version of WordPress or use the host’s migration process. Many hosts offer free migrations, but “free” does not always mean comprehensive. Ask whether they move the database, email, SSL certificate, redirects, and any custom configurations. Ask who tests the result.
If the site is custom-built, confirm the new server supports the required PHP version, database type, server rules, scheduled tasks, and software dependencies. A developer may need to handle this portion, especially if the site is older or has custom functionality.
Copy files and database, then test privately
Move the website files and database to the new hosting account. For WordPress, a reputable migration tool can work well for standard sites. Larger sites, ecommerce sites, and sites with unusual server settings may need a manual migration or professional support.
Then test the migrated copy using a temporary URL, staging URL, or hosts-file preview. Check more than the homepage. Open key service pages, review images, test site search, submit every major form, check confirmation emails, log in to protected areas, and walk through a test purchase or donation if relevant.
Look closely for mixed-content warnings, broken links, missing images, formatting issues, and unexpected redirects. This is also a good time to confirm that analytics, cookie notices, spam protection, and conversion tracking are present. A website can look perfectly fine while its lead form quietly goes nowhere.
Prepare the DNS change
DNS tells browsers where to find your website. When you are ready to point the domain to the new host, you may update nameservers or individual records such as the A record and CNAME record. Which method is right depends on where DNS is managed.
A day or two before the change, lower the DNS TTL if your provider allows it. TTL is the amount of time other systems are told to remember your existing DNS information. A lower TTL can help the update spread more quickly, although DNS changes can still take several hours and occasionally up to 48 hours to fully propagate.
Be cautious with nameserver changes if business email is involved. Changing nameservers without recreating MX, SPF, DKIM, and other needed email records can interrupt sending or receiving. That is an unpleasant way to find out how many customer conversations happen by email.
Make the switch during a quieter window
Schedule the DNS update for a lower-traffic time, but not when no one can monitor it afterward. Friday evening may be quiet for site visitors, but it is not ideal if you will not notice a problem until Monday.
For a brochure-style site, update the DNS after final testing and monitor both the old and new environments while records propagate. For a busy store, membership site, or organization accepting registrations, plan a brief content freeze or coordinate a final database sync immediately before the switch. This reduces the chance that an order, submission, or account update lands only on the old server.
Do not cancel the old hosting account yet. Keep it active for at least several days, and preferably until you have confirmed the new site is stable, backups are running, and no old services are still depending on it.
Check the marketing details after launch
A successful migration is not just a site that loads. It is a site that still supports your marketing.
Check that the SSL certificate is active and visitors see the secure version of the site. Confirm that your preferred domain version redirects properly, whether that is the www or non-www version. Review important redirects, especially if the migration happened alongside a redesign or URL cleanup.
In Google Search Console and analytics, watch for crawl errors, traffic drops, or unusual changes in conversions over the following days and weeks. A hosting-only migration should not require changing URLs, page titles, or core SEO settings. If those elements changed unintentionally, search visibility can suffer for reasons that get blamed on the host.
Test forms again from the live domain and check the inbox where messages should arrive. If you use a CRM, make sure submissions create the right records, tags, or notifications. Test appointment bookings, donation forms, payment processing, and newsletter signups too. These are the parts of the website that turn visitors into actual business.
Common migration mistakes to avoid
The most common mistake is assuming the hosting company handles everything. Some do excellent work, but scope varies widely. Get specifics in writing or at least in a support ticket before the migration begins.
Another is moving the domain registration unnecessarily. Domain transfers can be useful, but they add timing rules and another moving part. If the immediate problem is hosting, keep the domain where it is until the site is stable unless there is a clear reason to move it too.
Finally, avoid treating maintenance as optional once the move is complete. Better hosting helps, but it does not replace software updates, security checks, tested backups, and regular reviews of the tools attached to your site.
If this process feels like more technical coordination than your team has time for, that is a reasonable signal to get help. A careful migration should be fairly boring from the visitor’s perspective. For a business owner, boring is a very good outcome.