Client login

JOURNAL · 14 JULY 2026

Zero-downtime hosting migration: exactly how we do it

The complete playbook we use to move websites, databases, and email between hosts with no visitor-facing downtime — TTLs, parallel running, checksums, and the DNS switch.

“Migration” scares business owners because they have seen it done badly: a weekend of downtime, contact forms silently broken for a month, email vanishing into the gap between hosts. None of that is inherent to moving. It is what skipping steps looks like. Here is the full playbook — usable even if you never hire us.

The principle: run in parallel, switch at leisure

A safe migration never involves a moment where the old server is off and the new one is not yet ready. The site runs in both places at once; DNS decides which one the world sees; you switch only after the new copy is proven. Downtime is not minimized — it is designed out.

Step 1 — Lower the TTLs a day early

DNS records carry a TTL: how long resolvers cache the answer. If your records sit at 24 hours, any switch takes up to a day to propagate — this is where the myth of “48 hours of downtime” comes from. Drop the TTL to 300 seconds a day before the move, and the eventual switch completes worldwide in minutes.

Step 2 — Copy, then prove the copy

Files move by rsync, databases by dump and import. Then — the step most skipped — verify: checksums on files, row counts and spot queries on databases, and a character-set check, because a migration that turns Urdu text into question marks is not a migration. For WordPress, the database URL rewrite happens now, on the new copy, touching nothing live.

Step 3 — Test on a preview URL

The copied site gets a temporary address on the new server. Click through it like a hostile customer: log in, search, place a test order, submit every form. Payment callbacks and cron jobs are re-pointed and test-fired here. Nothing is live yet; mistakes cost nothing.

Step 4 — Move the mail before the mailboxes matter

Mailboxes copy via IMAP sync, which preserves folders and read state. SPF, DKIM, and DMARC are written on the new side before the switch, so the first message sent from the new server is already authenticated. Messages in transit during the switch are queued and retried by the sending servers — that is how SMTP has worked since the 1980s — so nothing is lost in the gap.

Step 5 — Switch when you say so

DNS changes at an hour you approve — for most businesses a quiet weekday morning, not a mysterious 3 a.m. With the lowered TTLs, traffic moves to the new server within minutes, while the old host keeps serving stragglers identically. There is no cliff.

Step 6 — Watch, then decommission

The old account stays paid and untouched as a fallback until logs on the new side show clean traffic, working forms, and authenticated mail flow — typically a week. Only then does the old host get cancelled. Cancelling on day one to save a few days of overlap fees is how horror stories start.

What this costs at Aibuz

Nothing, on any annual plan — the process above is included and done by us, typically completing within 48 hours of receiving access, with the DNS switch scheduled at your convenience. It is also, deliberately, our best sales pitch: how a host treats your migration is how it will treat everything after.

NEXT/STEP

Want this level of care on your own infrastructure?

Start with the free domain audit — real measurements, written report, no obligation.

REPLIES WITHIN ONE BUSINESS DAY · USUALLY MINUTES