A migration is three moves, not one
People imagine moving a website as flipping one giant switch, which is exactly why it feels dangerous. It is not one switch. It is three distinct things that happen in sequence: you copy the site to the new host, you test the copy privately, and only then do you point your domain name at the new location. The copying and testing happen while your live site keeps running untouched on the old host. Nobody sees any of it. The only moment anything visible changes is the final step, and even that can be made seamless.
Hold onto that mental model, because it is the whole game. Your old site stays up and serving customers right until the new one is proven and ready. You are never in a state where the site is half-moved and broken, as long as you resist the urge to change your domain settings first. Changing DNS first is the single most common way people cause the downtime they were afraid of.
Before you touch anything
Start by taking a complete backup of the current site — every file and the full database — and downloading it somewhere safe on your own computer. This is your parachute. If anything goes wrong at any point, you have an untouched copy of the working site. Even when the new host offers to do the migration for you, take your own backup first. It costs ten minutes and it means no possible outcome can actually lose your site.
Then find one setting on your domain and write it down: the TTL. Every domain has DNS records that tell the world which server answers for it, and each record has a "time to live" — a number, in seconds, that tells other computers how long to remember the answer before checking again. A typical TTL is a few hours. That number is the lever that makes a migration either seamless or slow, and we come back to it in step three. For now, just note where it is set, because you will want to lower it a day ahead of the switch.
Finally, confirm you actually control your domain name — that you can log in to wherever it is registered and change its DNS records. If a previous developer set everything up and you have never seen that login, sort this out before you do anything else. You cannot move a website you cannot repoint.
Step one: copy the site to the new host
With a backup in hand, set the site up on the new host while the old one keeps running. For a WordPress site this usually means creating a fresh empty site on the new host and restoring your files and database into it, either with a reputable migration plugin or by hand if you are comfortable with files and databases. Many good hosts will simply do this part for you as a free service — you give them your old login, they pull the site across, and they tell you when the copy is ready to test. If a host offers free migration and does it competently, let them; they have done it a thousand times.
At the end of this step there are two identical copies of your site: the live one your customers still see on the old host, and a private copy on the new host that the public cannot reach yet because your domain still points at the old server. Nothing has changed for anyone. This is exactly where you want to be.
Step two: test before anyone sees it
This is the step careless migrations skip, and it is the one that saves you. Before you send any real visitors to the new copy, you view it privately and make sure it actually works. Good hosts give you a temporary preview URL or a way to override your own computer to see the new server while everyone else still sees the old one. Use it to click through the site as if you were a customer: load the home page, open a few articles or product pages, submit the contact form, check that images appear, and if you sell things, walk through a test order.
You are hunting for the small things that break in a move — a contact form that was wired to the old server, an image path that did not come across, a plugin that needs a licence re-entered, an SSL certificate that has not been issued yet on the new host. Every one of these is trivial to fix now, while the public still sees your untouched old site, and a genuine emergency if you discover it after you have already switched. Fix everything you find, then test again. Do not move to step three until the private copy is genuinely perfect.
Step three: the DNS switch, done safely
Now the actual move, and here is where that TTL number earns its keep. A day before you plan to switch, lower the TTL on your domain records to something short, like three hundred seconds. Wait for the old, longer TTL to expire so the whole internet picks up the new short value. What you have done is tell every computer in the world to stop remembering your DNS answer for hours and start re-checking every five minutes instead.
Then, at a quiet time for your business, change the DNS records to point at the new host. Because you lowered the TTL, the world starts noticing the change within minutes instead of hours, and visitors roll over to the new server smoothly. And because both copies of your site are identical and both are running, it does not even matter which server a given visitor lands on during the brief changeover — they see the same site either way. That is the secret to zero-downtime migration: for a short window both hosts serve the same site, so there is no moment when nobody is being served. Once everyone has moved across, you raise the TTL back to normal.
Leave the old host running for a week or two after the switch, not just a day. DNS changes take time to reach every corner of the internet, and a stray visitor or an email server may still hit the old site for a little while. Keeping it alive for a couple of weeks means nobody falls through the gap. Only once your new host has clearly been serving everyone for a while do you cancel the old plan — and even then, keep that backup you took at the start.
After the switch
Once the move is done and stable, take care of the housekeeping. Confirm the SSL certificate on the new host is valid so visitors see the padlock, not a warning. Check that email still works if your email was tied to the old host — this catches people out constantly, because website hosting and email hosting are often bundled and moving one can quietly break the other. Re-test your contact and checkout forms on the real live site. And point any monitoring or analytics you use at the new setup so you would know if something went wrong.
Give it a few days and then do one more pass through the site as a visitor. Migrations occasionally surface a slow-burning issue — a scheduled task that stopped running, a caching setting that needs tuning on the new server. Catching it in the first week, while you are still paying attention, is far easier than discovering it months later.
When to let someone else do it
You can absolutely do this yourself, and for a simple site it is a satisfying afternoon. But be honest about two things: how comfortable you are with files, databases, and DNS, and how much it would cost your business if the site went down during business hours because a step went sideways. If either answer gives you pause, this is a job worth handing to someone who does it routinely. A good host or a managed provider will migrate a site in, test it, and handle the DNS cutover as a normal part of onboarding, often at no charge — which quietly removes the fear that kept you on the wrong host in the first place.
That is a large part of what managed hosting is for. Moving businesses onto our servers cleanly, with no downtime and no drama, is something I do at Design Menu as a matter of course, precisely because the order of operations above is second nature once you have done it enough times. However you handle it, the principle does not change: copy, test, then switch — and never, ever change your DNS first.