A client’s WordPress site, roughly 10GB of it, needed to move to new hosting. It was live on the new server the same working day, and visitors saw nothing.
Both of those facts sound like they are about speed. Neither of them is.
10GB is a media problem, not a website problem
A 10GB WordPress site is not 10GB of WordPress. It is a normal site plus years of uploads: images, PDFs, a few videos nobody remembers adding.
That distinction is what makes the schedule work. The media is large but almost entirely static, so it can be copied across well ahead of the cutover while the old site carries on serving every visitor as usual. By the time anything time-critical happens, the bulk of the transfer is already done and only the handful of files added since need syncing.
The database goes last, when it is smallest, freshest, and takes minutes rather than hours.
No downtime comes from the ordering
The new server was serving a complete, tested copy of the site, correct PHP version, database imported, TLS issued, caching configured, while DNS still pointed entirely at the old host. Verification happens through a local hosts file entry, not by moving DNS and refreshing hopefully.
DNS only moves once both servers would give a visitor the same correct answer. That is the whole trick: there is never a moment where the right destination does not exist. Whichever server a visitor’s resolver knows about, they get a working site.
The TTL drop happens the day before, not on the day. Records are cached for their previous TTL, so lowering it at cutover time does nothing for the resolvers that already hold the old value.
The old host stays up
The old hosting kept running after go-live. Some resolvers ignore TTLs, and a rollback path you can actually use is worth more than one saved month of hosting fees.
I wrote up the full sequence separately in Moving off shared hosting without downtime, if you want the version with the reasoning behind each step.
One working day is a planning result
Nothing here was rushed. The transfer ran in the background while the site stayed live, the risky steps were reduced to a database import and a DNS change, and everything else had already been proved on the new server first.
Migrations that overrun are usually migrations where the DNS moved before the destination was genuinely ready. Everything after that point is damage control, in public, on someone else’s schedule.
We do migrations of this size as project work, and most sites stay with us afterwards on a Care Plan so the new server does not drift back into being unmaintained. If you have a move you have been putting off, get in touch with the size of the site and where it is hosted now.