Migrate Website Without Downtime

The Problem

You need to migrate hosting but can't afford any visible downtime — an e-commerce store, a busy site, or simply a business that can't risk looking offline even briefly during the switch.

About this problem

Most migrations have some unavoidable downtime at the DNS propagation stage, but with the right approach — low TTLs set well in advance, a fully tested destination server, and careful sequencing of the cutover — the actual visitor-facing gap can be reduced to seconds or avoided almost entirely for most traffic. The key is treating the DNS switch as the very last step after everything else is already proven to work, not as part of the testing process itself.

This matters most for e-commerce sites losing sales during downtime, high-traffic sites where any gap is visible, or businesses with reputational risk tied to uptime.

What's Included

• Lowering DNS TTL well in advance of the migration to speed up propagation
• Fully building and testing the site on the new server using a temporary access method, with zero impact on the live site
• A database sync step immediately before cutover to capture any last-minute changes (orders, form submissions, etc.)
• A carefully sequenced DNS cutover, with the old server kept live as an instant fallback
• Post-cutover verification and monitoring during the propagation window

What's NOT Included

• Guaranteeing absolute zero downtime in every case — propagation behaviour varies slightly by ISP/DNS resolver, though the visitor-facing impact is minimised as much as technically possible
• Paying for or provisioning the new hosting
• Code-level changes to make a dynamic application natively support true zero-downtime blue-green deployment, unless that's specifically what's being asked for

How It Works

1. Lower the DNS TTL on key records days in advance so any future change propagates fast when it matters.
2. Build and fully test the site on the new server via a temporary hosts override or staging subdomain, with the live site completely unaffected.
3. Put the old site into a brief, controlled read-only or maintenance state only at the very last moment, if the platform needs it to avoid data loss during the final sync.
4. Run a final database sync capturing anything that changed since the main migration (new orders, new comments, form submissions).
5. Switch DNS to the new server and closely monitor traffic and error rates during the propagation window.
6. Keep the old server live and ready as an instant rollback option until the new one is confirmed fully stable.

In practice: you buy the service, send over whatever access or details the job needs, I investigate and do the work, and you confirm it's resolved before we call it done.

Frequently Asked Questions

Is zero-downtime website migration really possible?

Effectively yes for the vast majority of visitors, by testing everything on the new server before switching and keeping any final data-sync window as short as possible — a tiny theoretical gap can exist during DNS propagation, but it's minimised as much as technically achievable.

Why does lowering DNS TTL help with migration downtime?

TTL controls how long DNS resolvers cache a record — a high TTL set days before migration means some visitors would keep hitting the old server for hours after the switch; lowering it in advance means the switch takes effect for almost everyone much faster.

What happens to new orders or form submissions during the migration?

A final database sync captures anything that changed on the old site right up to the cutover moment, so nothing submitted during the migration window gets lost.

Does this work for e-commerce sites with live orders?

Yes, it's exactly the kind of site this approach is built for, with extra care taken around the final data sync to avoid losing or duplicating orders.

How far in advance should I plan a zero-downtime migration?

Ideally a few days ahead, mainly to lower DNS TTL in advance — the actual migration and cutover itself can happen on your schedule once that's in place.

What if something goes wrong during the cutover?

The old server is kept live and untouched as an instant fallback, so DNS can be pointed back if anything unexpected comes up during the switch.