Moving a Website Without Downtime

You move a website without downtime by building the new site in parallel, preparing DNS properly, and switching the domain only when the new setup is tested and ready. There is no need for an under-construction page if the migration is planned well.

This part scares owners because DNS sounds mysterious and permanent. In reality, the clean migration feels more like moving shop premises next door, fitting it out fully, then changing the sign once the new space is ready. Customers mostly keep walking through the front door without noticing the backstage work.

What is the shop-refit method?

The shop-refit method means you build the new site separately while the old one keeps serving the public. You do not tear the current site apart in front of customers if you can avoid it.

This is how I prefer to handle WordPress rebuilds, platform migrations, and more serious refreshes. The current site stays live. The new site gets designed, tested, and reviewed in a private or staging environment. Only once the content, redirects, forms, and email settings are ready do you switch traffic over.

The benefit is obvious once you picture the alternative. Rebuilding in place means customers may see half-finished pages, broken links, changing layouts, or random plugin conflicts while the work is happening. A parallel build keeps the messy part away from the public.

This is also where redirects and content mapping fit in. If the migration includes URL changes, read this together with work or pricing. Downtime and SEO loss are different risks, but they often show up together when migrations are rushed.

What are DNS and TTL in plain words?

DNS is the system that tells the world where your domain should point. TTL is how long other systems may keep the old answer before asking again.

You do not need to become a networking person to manage this well. What matters is knowing that a domain change does not update every corner of the internet in one instant. There is a handover window where some visitors may still be getting the old destination while others get the new one.

That is why preparation matters. Lowering the TTL ahead of the move can shorten that overlap in some setups. More importantly, it lets you plan the cutover instead of treating the switch like a leap into darkness.

What actually happens during the cutover hour?

During the cutover hour, you update the DNS or hosting target, then monitor closely while traffic shifts across. The website is not usually “off”. It is more like the sign outside is being updated while both premises still exist.

If the new site is ready and tested, most visitors will either hit the old working site briefly or the new working site shortly after. The drama comes when people switch too early, forget forms or email routing, or never tested the production-like environment properly.

I prefer quieter cutover times for service businesses, usually outside their busiest lead windows. Not because traffic must stop, but because support is easier if anything small needs adjusting. The key is not the exact hour. The key is choosing it intentionally.

Why do you still need a rollback plan?

You need a rollback plan because confidence is not a rollback plan. Even clean migrations can hit a surprise with DNS, plugins, SSL, or email routing.

A rollback plan answers simple questions fast. If forms fail, what is the fallback? If DNS points wrong, who has access to reverse it? If a plugin behaves differently on the new host, can the old environment stay intact while you fix it? The best migrations never use the rollback, but they still have it ready.

This is another reason parallel builds are safer. You have not destroyed the old site to launch the new one. You can step back if needed.

How do you stop email from breaking in the move?

By treating email as part of the migration, not as an afterthought. Website moves break email most often when DNS records, SMTP settings, or form notifications were tied to the old environment and no one checked them.

After cutover, test the contact form, the notification route, and any password reset or order emails immediately. If the site runs CRM workflows or GoHighLevel handoffs, test those too. A site that loads fine but stops sending enquiries is not a successful migration.

This is where clear migration scope and platform migration overlap. Owners notice visible downtime instantly. They often notice email downtime weeks later, which is much more expensive.

Quick answers

Will customers notice anything?

If the migration is handled well, most customers will notice nothing or only a brief normal refresh. The goal is a boring cutover.

What time or day should I cut over?

Choose a quieter business period when the right people are available to monitor and fix anything small quickly.

What if something breaks after?

That is why you keep the rollback plan and test checklist ready. Small issues happen. The difference is whether you prepared to catch them fast.

Thinking of moving? Send me your site on WhatsApp and I’ll tell you what a clean migration needs: platform migration.