solobuild
Moving your website to a new host sounds like a job for a developer, and most solo founders put it off for exactly that reason. They stay on a slow or overpriced plan for another year because they are afraid of breaking the site, losing email, or waking up to a blank page and a pile of angry messages. The fear is reasonable, since a careless move can take a site offline for hours. The good news is that downtime during a migration is almost always caused by doing the steps in the wrong order, not by anything technically hard. This guide walks through the order that works, so your visitors never notice you moved.
Why migrations cause downtime in the first place
To understand how to avoid downtime, it helps to know what actually happens when you switch hosts. Your domain name does not point at your website directly. It points at a set of DNS records, which are like an address book entry that tells browsers which server holds your site. When you move hosts, you change that address to point at the new server. The problem is that the internet caches the old address for a while, and different visitors see the change at different times.
That caching period is controlled by a setting called TTL, short for time to live. TTL is a number of seconds that tells other servers how long they can remember your DNS record before checking again. Many domains ship with a TTL of 3600 seconds (one hour) or even 86400 seconds (a full day). If your TTL is set to a day and you switch servers, some visitors could keep hitting the old server for up to 24 hours. That by itself is not downtime, as long as the old server is still running. Downtime happens when people cancel the old host too early, or when the new host is not fully ready at the moment traffic starts arriving.
There is also a quieter kind of breakage that feels like downtime to visitors. The site loads, but images are missing, forms fail, the checkout throws an error, or the browser shows a security warning because the SSL certificate was not set up on the new server. None of these are dramatic, but each one costs you trust and sales. A good migration plan treats all of them as part of the job rather than cleanup for later.
So the core principle is simple, even if the steps take some care. Build the new site completely while the old one keeps serving visitors, test the new one privately, and only then point the domain at it. Keep the old host alive until you are certain nobody is reaching it anymore.
The prep work that makes cutover boring
The most useful thing you can do happens a day or two before you move anything. Log into wherever your DNS is managed, which is usually your domain registrar or your current host, and lower the TTL on your main records to 300 seconds, which is five minutes. You want to do this at least 24 to 48 hours ahead so the old, longer TTL has time to expire in caches everywhere. When you finally switch, the change will spread in minutes instead of most of a day.
While you wait for that, take a full backup of the site from your current host. That means both the files and the database if you run WordPress or another database-driven platform. Download a copy to your own computer or cloud storage, not just a backup that lives on the old server. If anything goes wrong later, this copy is your safety net, and it is worth the ten minutes it takes to confirm the download actually opens.
This is also the right time to write down everything the old host does for you besides serving web pages. Solo founders often forget that their host also runs their email, stores a cron job that sends a weekly report, or handles a redirect they set up two years ago. Check your DNS records for MX entries (the records that route email), TXT records used for email authentication and domain verification, and any subdomains. If you do not copy these to the new setup, your site may move perfectly while your inbox quietly stops receiving mail.
Finally, pick a quiet window for the switch. Look at your analytics and find the lowest-traffic period, which for most small sites is late at night or early morning on a weekday. If you sell anything, avoid the days right after a newsletter or promotion. You are not expecting problems, but if one shows up, you want it to affect as few people as possible.
Setting up and testing the new host
With prep done, sign up for the new host and add your site there. If you are on WordPress, many hosts now include a migration plugin that copies the site for you. SiteGround, for example, offers a free WordPress Migrator plugin that transfers files and the database without you touching either one directly. You install the plugin on your old site, paste in a token from your new account, and it handles the copy. For non-WordPress sites, the usual method is to upload your files over SFTP and import your database through a tool like phpMyAdmin.
Pricing matters here, because the reason many people move hosts is a renewal bill that jumped. Based on published pricing tracked by several review sites this year, SiteGround's StartUp plan starts at an introductory rate of about $2.99 per month and renews at $17.99 per month, while GrowBig starts around $4.99 and renews at $29.99. That renewal jump is common across the hosting industry, so read the renewal price on any host before you commit. It would be frustrating to go through a careful migration only to face the same problem at a new company in a year.
Once the copy is complete, set up SSL on the new host before you do anything else. SSL is the certificate that gives your site the padlock and the https address. Most hosts now issue free Let's Encrypt certificates, but some can only finish issuing one after your domain points at them. Check your new host's documentation for how they handle this, because it affects the next step. If they support issuing the certificate before the DNS change, do it now so there is no gap.
Now test the new site privately. The trick most guides skip is editing your computer's hosts file. This is a small text file that lets you override DNS for your own machine only, so you can tell your browser to load your real domain from the new server while everyone else still sees the old one. Your new host will give you the server's IP address. Add a line with that IP followed by your domain, save the file, and load your site. You are now looking at the migrated version under its real address, which catches problems that a temporary preview URL would hide.
Click through everything that matters. Load the homepage, a few posts, and your most important landing pages. Submit your contact form and confirm the message arrives. If you sell products, run a test purchase in your payment provider's test mode. Log into your admin area and make sure plugins are active and nothing threw an error during the import. When you are satisfied, remove the line from your hosts file so your computer goes back to normal.
Making the switch
If your site takes regular new content, comments, or orders, you need to handle the gap between your copy and the switch. The simplest approach for a solo site is a short content freeze. Stop publishing and editing for the few hours around the move, then run one final sync of the database right before you change DNS so any late orders or comments come along. Some migration plugins let you rerun the transfer, which does this for you.
Now change the DNS. You have two options depending on your setup. If you are keeping your DNS at your registrar, update the A record (the record that points your domain to an IP address) to the new server's IP, along with the www record if it is separate. If your new host wants to manage DNS for you, you will instead change your domain's nameservers at the registrar. Changing the A record is usually faster and less risky, because nameserver changes can take longer to spread and you have to recreate every other record at the new DNS provider first.
Because you lowered the TTL earlier, most visitors will start reaching the new server within minutes. During this period, both servers are live and serving the same content, which is exactly the point. A visitor who still has the old address cached sees the old site, a visitor with the new address sees the new one, and nobody sees an error. You can check progress with a free DNS propagation checker, which shows what your domain resolves to from servers around the world.
Watch the site for the next few hours. Check that your SSL certificate is active on the new server, look at your error logs if the host provides them, and keep an eye on your analytics to make sure traffic is still arriving. If something is badly wrong, you can point the A record back to the old IP and you are back where you started within minutes. This rollback option only exists because you kept the old host running, which leads to the last rule.
Cleaning up without cutting corners
Do not cancel your old host the same day. Give it at least a week, and two is safer. Some networks and devices ignore TTL settings and hold onto old addresses much longer than they should, and you want those stragglers to still land on a working site. If your old host had any content changes during the overlap, such as a late order on a store, you will want access to recover it.
After a few days, raise your TTL back to a normal value like 3600 seconds. A very low TTL is useful during a move, but leaving it there means more DNS lookups and slightly slower first visits for new people. Then verify your email one more time by sending a message to your domain from an outside account. Email problems tend to show up days later, when someone mentions they never got your reply.
Once the old host has gone quiet for several days, download one last backup from it for your records and then cancel. Keep that archive somewhere safe for a few months. It is rare to need it, but it costs nothing to keep and it is the only complete snapshot of the site as it lived on the old server.
Frequently asked questions
How long does it take to migrate a website to a new host?
For a typical small WordPress site, the actual copy takes anywhere from a few minutes to an hour, depending on how large your media library is. The full process takes longer because of the waiting built into it. You lower the TTL a day or two ahead, and you keep the old host running for one to two weeks afterward. The hands-on work, including testing, usually fits into a single afternoon.
Will changing hosts hurt my SEO?
A clean migration that keeps the same domain, the same URLs, and the same content should not hurt your rankings. Search engines care about whether your pages stay reachable and load properly. Problems come from changing URL structures without redirects, leaving the site broken for a stretch, or losing SSL. If your new host is faster, the move can even help slightly, since page speed is one of many signals search engines consider.
Do I need to move my domain when I change hosting?
No, and in most cases you should not do both at once. Your domain registration and your web hosting are separate services, even if you bought them together. You can leave the domain where it is and simply point its DNS records at the new host. If you want to transfer the domain too, do it as a separate project a few weeks after the hosting move is finished, so you are only changing one thing at a time.
What happens to my email when I switch web hosts?
It depends on who runs your email. If you use a separate service like Google Workspace or Microsoft 365, your email is controlled by MX records that you just need to leave untouched or copy over exactly. If your old host provided your email accounts, you will need to recreate those mailboxes at the new host or move to a dedicated email provider before canceling. This is the step solo founders most often miss, so check it before you start.
The bottom line
A downtime-free migration comes down to a handful of habits rather than technical skill. Lower your TTL well ahead of time, back everything up to a place you control, build and test the new site while the old one keeps working, and switch DNS during a quiet window. Then leave the old host running long enough that nobody can still reach it. Each step removes one specific way the move could fail, which is why the order matters more than the tools.
If you are moving because of slow load times or a painful renewal, it is worth checking a host that includes a migration tool and clearly lists its renewal price, such as SiteGround, before you start. Whichever host you choose, the process above stays the same. Block out an afternoon, follow the steps in order, and you will likely find that the job you have been avoiding for months was mostly waiting.