Migrasi Website Tanpa Downtime: DNS, Staging, dan Cutover

Pencarian “website pindah hosting” biasanya menyimpan satu ketakutan: downtime dan form rusak keesokan paginya. Cutover yang hati-hati menjaga situs lama tetap online sampai stack baru terbukti.

Ini urutan migrasi yang saya pakai untuk situs klien.

Prinsip: jalankan dua environment sampai DNS berpindah

1. Bangun dan uji di staging (URL sementara atau override hosts-file).
2. Sync konten lagi tepat sebelum cutover.
3. Turunkan TTL DNS lebih awal.
4. Arahkan DNS hanya setelah HTTPS, redirect, dan smoke test lolos.
5. Biarkan host lama tersedia untuk jendela rollback singkat.

“Nol detik” sejati jarang terjadi di DNS shared—tapi overlap terkontrol dalam hitungan menit lebih baik daripada outage kejutan berjam-jam.

Fase 1 — Inventaris

• record DNS saat ini (A, AAAA, CNAME, MX, TXT);
• penyedia SSL dan CDN (Cloudflare proxy on/off);
• versi CMS, plugin, cron, pengirim email transactional;
• ukuran media / database besar;
• URL hard-coded di tema, Elementor, dan tabel options.

Export screenshot DNS sebelum menyentuh apa pun.

Fase 2 — Staging di host baru

• clone file + database;
• search-replace domain lama → domain staging dengan hati-hati (tool sadar data serialized PHP untuk WordPress);
• matikan konflik cache/CDN di staging;
• uji login, form, checkout (bila ada), dan template utama di mobile;
• perbaiki ketidakcocokan versi PHP lebih awal.

Fase 3 — Penguatan pra-cutover

• turunkan TTL ke 300 detik (atau lebih rendah) 24–48 jam sebelum flip bila memungkinkan;
• terbitkan SSL di host baru (atau pastikan Cloudflare Full Strict siap);
• siapkan peta 301 untuk permalink lama / HTTP→HTTPS / www↔apex;
• jadwalkan content freeze atau jendela sync final bersama klien.

Fase 4 — Cutover

1. Sync DB/media final dari production ke host baru.

2. Pasang maintenance atau read-only di situs baru hanya jika ada write aktif selama sync.

3. Update DNS A/CNAME ke origin baru (atau ganti IP origin Cloudflare).

4. Purge cache CDN.

5. Verifikasi:

   • homepage + form kontak;
   • gembok HTTPS;
   • properti Search Console / sitemap;
   • email masih terkirim (kredensial SMTP sering rusak setelah ganti host).

Fase 5 — Stabilisasi

• pantau 404 dan log server selama 48 jam;
• biarkan hosting lama tetap dibayar sampai TTL habis drain;
• naikkan TTL lagi setelah stabil;
• dokumentasikan kredensial baru untuk klien.

Catatan khusus WordPress

• update siteurl / home dengan benar;
• regenerate permalink sekali;
• simpan ulang Elementor/CSS jika aset 404;
• hubungkan ulang object cache / cron jika host baru berbeda;
• jangan biarkan DISALLOW_FILE_EDIT mati di production jika itu bagian dari hardening.