Friday 5 p.m.: DNS switches to the new host. At 5:05, the site responds—but orders since 4 p.m. are gone because the database was exported at noon and nobody resynced. At 5:30, images 404: uploads were missing from the last rsync. The "one-click migration" tool looked flawless.
Migrating without outage is not about host brand. It is a timeline: what to copy, when to freeze writes, when to change DNS, how to roll back.
Phase 0: inventory and window
List: database, files, cron, mail, DNS, certificates, webhooks, IP allowlists, object storage. Pick a low-traffic window. Warn stakeholders of a short maintenance window for the final dump—not the entire migration.
| Item | Pre-migration | D-day |
|---|---|---|
| DNS TTL | 300 s | Already propagated |
| TLS certificate | ACME or import ready | Valid on new IP |
| Cron / workers | Off on old after cutover | On on new |
| MX unchanged or planned | SPF/DKIM checked |
Phase 1: cold sync, no cutover
- Bulk copy files + initial DB export to new infra.
- Configure nginx, PHP,
.env, aligned versions. - Functional test via hosts file or preview URL—not public DNS.
- Delta sync files until D-1.
Do not touch public DNS while tests fail.
Phase 2: D-day — strict sequence
Recommended order:
- Put old site read-only (maintenance flag or app config).
- Final DB dump + final file rsync.
- Smoke test on new infra (login, cart, critical API).
- Switch DNS A/AAAA or CNAME to new target.
- Monitor logs and errors 30–60 min.
- Enable cron on new; disable on old.
- Keep old environment intact 48–72 h for rollback.
Changing DNS before the final dump accepts silently lost data.
WordPress, SaaS, and object storage cases
WordPress — migration plugins are handy but check serialized URLs in DB, permalinks, wp-cron.php. Search-replace domains only after validation.
SaaS with workers — stop consumers before dump; restart after DNS cutover to avoid double processing.
Media on S3 — no disk rsync: same bucket or cross-region replication; migrate only config and keys.
Rollback: prepare the reverse path
If the new site breaks after DNS:
- Low TTL allows quick repoint to old IP.
- Do not destroy old server before 72h validation.
- Document DNS panel access for both hosts.
The climax: marketing "zero downtime" vs data downtime
This is the gap between sales demo and Monday accounting. Measure success on data consistency, not ping alone.
Decide and move forward without blind spots
- Lower TTL a week ahead.
- Test on preview until fully green.
- Run D-day sequence with frozen final dump.
- Monitor post-cutover; keep rollback ready.
- Compare migration offers in directory—read free migration investigation.
See staging to rehearse migration dry-run before prod.
Frequently asked questions
How long before migration should I lower DNS TTL?
Set 300 s at least 24–48 hours ahead—ideally a week if old TTL was long.
Migrate files or database first?
File sync first; read-only database at D-day for coherent final dump.
Must the site go offline during migration?
Not for hours. Short maintenance at final dump is enough if prepared.
How to test before pointing DNS?
Hosts file, temporary hostname, or host preview URL. Validate login, forms, mail, cron.
The right migration tool is the one your team can run in the right order—with a DNS plan B ready before pressing Enter.