Website Migration Without Downtime: DNS, Staging, and Cutover

“Website pindah hosting” searches usually mean one fear: downtime and broken forms the morning after. A careful cutover keeps the old site online until the new stack is proven.

This is the migration sequence I use for client sites.

Principle: run two environments until DNS flips

1. Build and test on staging (temporary URL or hosts-file override).
2. Sync content again just before cutover.
3. Lower DNS TTL ahead of time.
4. Point DNS only when HTTPS, redirects, and smoke tests pass.
5. Keep the old host available for a short rollback window.

True “zero seconds” is rare on shared DNS—but minutes of controlled overlap beats hours of surprise outage.

Phase 1 — Inventory

• current DNS records (A, AAAA, CNAME, MX, TXT);
• SSL provider and CDN (Cloudflare proxy on/off);
• CMS version, plugins, cron jobs, email transactional sender;
• large media / database size;
• hard-coded URLs in theme, Elementor, and options tables.

Export a screenshot of DNS before touching anything.

Phase 2 — Staging on the new host

• clone files + database;
• search-replace old domain → staging domain carefully (serialized PHP data aware tools for WordPress);
• disable cache/CDN conflicts on staging;
• test login, forms, checkout (if any), and major templates on mobile;
• fix PHP version mismatches early.

Phase 3 — Pre-cutover hardening

• lower TTL to 300s (or lower) 24–48 hours before flip when possible;
• issue SSL on the new host (or confirm Cloudflare Full Strict readiness);
• prepare 301 map for old permalinks / HTTP→HTTPS / www↔apex;
• schedule a content freeze or final sync window with the client.

Phase 4 — Cutover

1. Final DB/media sync from production to new host.

2. Put the new site in maintenance or read-only only if writes are active during sync.

3. Update DNS A/CNAME to the new origin (or swap Cloudflare origin IP).

4. Purge CDN cache.

5. Verify:

   • homepage + contact form;
   • HTTPS padlock;
   • Search Console property / sitemap;
   • email still sending (SMTP credentials often break after host changes).

Phase 5 — Stabilize

• monitor 404s and server logs for 48 hours;
• keep old hosting paid through the TTL drain period;
• raise TTL again once stable;
• document new credentials for the client.

WordPress-specific notes

• update siteurl / home correctly;
• regenerate permalinks once;
• re-save Elementor/CSS if assets 404;
• reconnect object cache / cron if the new host differs;
• never leave DISALLOW_FILE_EDIT off on production if it was part of hardening.