Most people stay on bad hosting for one reason. They’re frightened of the move. The site is earning, the phone rings when it’s down, and nobody wants to be the person who broke it on a Tuesday afternoon.
Here’s the thing worth knowing before you start: a WordPress migration doesn’t have to take the site offline at all. Done properly, the old site keeps serving every visitor right up until the moment the new one takes over, and nobody outside your business notices anything happened.
This is how that works, and where the downtime actually comes from when a move goes wrong. If you’re still deciding whether the hosting is even the problem, start with the signs your current host is slowing down your site.
The 2 kinds of downtime
The obvious one is the site being unreachable. Someone deletes the old copy before the new one is ready, or points the domain at a server that isn’t finished, and visitors get an error page.
The sneaky one is worse. Your site stays up the whole time, but for a few hours some visitors land on the old server and some land on the new one. Both are live. Both accept orders. Then you switch off the old host and 6 orders, 4 enquiries and yesterday’s blog post vanish with it.
Nobody logs that as downtime. It costs a lot more than downtime does.
The rule that prevents both
You never turn the old site off. You build a complete copy on the new host, test it properly while the live site carries on as normal, then point the domain at the copy. The old site stays running for weeks afterwards as your rollback.
Everything below is in service of that.
Step 1: Take stock before you touch anything
Write down what you actually have. PHP version, WordPress version, plugin and theme list, database size, how big the uploads folder is, any scheduled jobs, and anything custom that a previous developer bolted on.
Two things catch people out here. Hard-coded URLs sitting in theme files or plugin settings, and email. If your domain’s email runs through the same provider as your hosting, changing nameservers can take your mailboxes down along with everything else. Find out before, not after.
Step 2: Drop your DNS TTL a day early
TTL is how long the rest of the internet is allowed to remember your old server’s address. Set to the common default of 24 hours, some networks will keep sending visitors to the old host for a full day after you’ve switched.
Drop it to 300 seconds at least 24 hours before cutover. Now the switch propagates in minutes rather than a day, and your split-brain window shrinks from hours to almost nothing. Put it back to normal a few days later.
This single step is the difference between a clean move and a messy one, and it’s the one that gets skipped most often.
Step 3: Copy the site, don’t rebuild it
Files and database, complete, onto the new host. Rebuilding by hand on a fresh install introduces small differences you’ll discover weeks later, usually in the settings nobody documented. A copy means what you test is what you get.
When the URLs get updated for the new environment, they have to be updated with a tool that understands serialised data. A plain find and replace across a database dump will corrupt widget settings, theme options and half your plugin configuration, and the damage often doesn’t show up until a week later.
Step 4: Test on a temporary address
Every decent host gives you a temporary URL, or a staging site you can test against, or you can point your own machine at the new server with a hosts file entry so you see the new site on the real domain while the world still sees the old one.
Then behave like a customer, not like an admin:
- Buy something, or book something, all the way to the confirmation screen.
- Submit every form and check the notification email arrives.
- Log in as a customer and open the account pages.
- Open 10 pages at random, including a category page and a search result.
- Check images load from the new server rather than the old one.
If the site uses payment gateways, this is also when you confirm the gateway will accept requests from the new server’s IP address. Some do care.
Step 5: Get the SSL certificate issued before you switch
A surprising amount of what people call migration downtime is a browser security warning. The domain moved, the certificate on the new host hadn’t been issued yet, and for 20 minutes every visitor saw a red screen telling them your site isn’t safe.
Have the certificate in place on the new host first. Most platforms can issue one for a domain that isn’t pointing at them yet.
Step 6: Final sync, then switch
Between the day you copied the site and the day you cut over, real things happened on the live site. Orders, enquiries, a new post, a price change.
So on cutover day you stop editing the old site, run one last sync of the database and uploads, and switch DNS immediately after. Pick a genuinely quiet hour. For most New Zealand businesses that’s early morning; for a store selling to the northern hemisphere it might be the middle of your afternoon.
With a 300 second TTL, traffic lands on the new host within minutes.
Step 7: Watch the first 48 hours
Check that order and contact form emails are arriving, because transactional email is the thing most likely to break quietly on a new server. Check scheduled tasks are firing. Watch for 404s and mixed content warnings.
Leave the old hosting account alive for 2 to 4 weeks. It costs one more month and it’s the only real rollback you have. Take a full backup off it before you cancel.
Stores, memberships and anything that writes data
If you run a WooCommerce store or a membership site, the split-brain problem is the whole game. A visitor whose network still resolves to the old server can place an order on a database you’re about to abandon.
Three ways to handle it, in order of preference. Cut over in your quietest hour with a short TTL, which keeps the exposure to minutes. Or hold new orders for that window with a brief maintenance notice. Or sync the order tables across once more after DNS has settled, which needs someone who knows what they’re doing with a live store.
Whichever you pick, decide it deliberately. A store migration that ignores this is where the “we lost 3 orders” stories come from. If you’re moving a shop, it’s worth reading what to look for in WooCommerce hosting before you pick the destination.
The mistakes that cause real downtime
- Changing nameservers before the new site exists, which points the domain at nothing.
- Changing nameservers without copying the MX and TXT records across, which takes email down and breaks SPF and DKIM.
- Cutting over with a 24 hour TTL still in place.
- Cancelling the old host the same day.
- Testing only the homepage while logged in as an administrator.
Or let someone else carry the risk
This is all doable yourself if you enjoy that sort of thing, and it’s the natural moment to ask whether you want to stay on the same kind of plan at all. Managed versus shared hosting covers where that line sits, and the benefits of managed WordPress hosting covers what changes once you move.
It’s also the kind of job that goes badly once and teaches you an expensive lesson. We do free WordPress migrations on every plan: we copy the site, test it, agree a cutover time with you, and handle the DNS. Typically 24 to 48 hours from your go-ahead, and your site stays up the whole way through.
PrestoWP is managed WordPress hosting for New Zealand businesses, NZ-owned and operated, with support from Auckland in NZ hours and billing in NZD plus GST. Have a look at the hosting plans, check the hosting FAQs, or tell us what you’re running and we’ll tell you honestly whether moving is worth it.