26 Oktober 2026

Pindah hosting tanpa cek DNS bikin toko offline sehari penuh

Panduan migrasi hosting tanpa downtime untuk pemilik bisnis: backup penuh, uji server baru, atur TTL rendah, cek SSL, email, dan redirect. Hindari toko offline.

Hosting SEO Web Development
Pindah hosting tanpa cek DNS bikin toko offline sehari penuh

Kenapa Pindah Hosting Tanpa Cek DNS Bisa Bikin Toko Offline Sehari Penuh

Pindah hosting terlihat sederhana: beli server baru, upload file, import database, ganti nameserver. Selesai. Kenyataannya, satu langkah yang dilewati—cek DNS sebelum cutover—bisa membuat domain mengarah ke server kosong, SSL gagal, dan toko online mati selama propagasi. Bagi bisnis non-teknis, sehari offline berarti keranjang ditinggal, chat tak terjawab, dan omzet hilang.

Artikel ini membedah urutan aman migrasi hosting tanpa downtime: backup penuh, uji di server baru, arahkan DNS dengan TTL rendah, lalu verifikasi SSL, email bisnis, dan redirect. Semua dijelaskan dalam bahasa praktis untuk pemilik bisnis.

Ringkasan Eksekutif:

  • Backup dulu, sentuh DNS belakangan: Tanpa backup file + database yang teruji, migrasi = judi. Uji restore di server baru sebelum menyentuh domain.
  • Turunkan TTL 24–48 jam sebelum cutover: TTL rendah (mis. 300 detik) mempercepat propagasi dan memungkinkan rollback cepat jika ada masalah.
  • Cek pasca-pindah wajib: SSL valid, email bisnis tetap terkirim, dan redirect 301 lama→baru berfungsi agar SEO dan pelanggan tidak tersesat.

Urutan Aman Migrasi Hosting: Backup → Uji → Arahkan DNS

Kunci migrasi tanpa downtime adalah memisahkan pekerjaan teknis dari perubahan publik. Selama server baru belum siap dan teruji, domain lama tetap melayani pelanggan. Baru setelah semuanya hijau, DNS diarahkan.

Langkah 1 — Backup Penuh File dan Database

  1. Backup file: Unduh seluruh direktori web (public_html atau document root) via SFTP/rsync atau fitur backup panel hosting. Pastikan folder uploads, themes, plugins, dan file konfigurasi ikut.
  2. Backup database: Ekspor via phpMyAdmin atau mysqldump. Simpan file .sql di dua lokasi terpisah (lokal + cloud storage).
  3. Catat konfigurasi: Simpan versi PHP, ekstensi, cron job, email account, dan record DNS saat ini (A, CNAME, MX, TXT) sebagai baseline.
  4. Uji restore: Restore backup ke lingkungan staging. Jika situs berjalan, backup valid. Jangan lanjut sebelum langkah ini lulus.

Langkah 2 — Uji di Server Baru Sebelum DNS Diarahkan

Server baru harus diuji tanpa menyentuh domain publik. Caranya: gunakan preview URL dari hosting baru, atau edit file hosts lokal untuk memetakan domain ke IP server baru hanya di komputer Anda.

  • Cek fungsional: Homepage, halaman produk, checkout, form kontak, dan login admin berjalan normal.
  • Cek performa: Bandingkan waktu muat server lama vs baru. Pastikan caching, CDN, dan kompresi aktif.
  • Cek kompatibilitas: Versi PHP, ekstensi (mis. gd, intl), dan batas upload sesuai kebutuhan aplikasi.
  • Cek database: Pastikan jumlah baris tabel utama sama dengan sumber, dan tidak ada error koneksi.

Langkah 3 — Arahkan DNS dengan TTL Rendah

DNS adalah peta yang memberi tahu internet ke server mana domain harus diarahkan. Saat record A diubah, perubahan tidak langsung global—ini disebut propagasi DNS. Resolver di berbagai lokasi menyimpan cache sesuai TTL (Time To Live).

Fakta penting: TTL 3600 detik berarti resolver bisa menyimpan jawaban lama hingga 1 jam. TTL 300 detik memangkasnya jadi 5 menit—cukup cepat untuk rollback, cukup aman untuk cutover.

Strategi aman:

  1. H-2: Turunkan TTL record A/CNAME menjadi 300 detik. Tunggu minimal satu siklus TTL lama agar cache global ikut memperbarui.
  2. Cutover: Ubah record A ke IP server baru. Pantau error log dan trafik.
  3. Rollback siap: Jika ada masalah, kembalikan record A ke IP lama. Dengan TTL rendah, pemulihan berlangsung menit, bukan jam.
  4. Setelah stabil 24–48 jam: Naikkan kembali TTL ke nilai normal (mis. 3600) untuk mengurangi beban resolver.

Perbandingan: Migrasi Asal-asalan vs Migrasi Terkontrol

AspekMigrasi Asal-asalanMigrasi Terkontrol (Tanpa Downtime)
BackupFile saja, database terlewatFile + database + konfigurasi, diuji restore
Uji server baruTidak ada, langsung ganti DNSUji fungsional, performa, dan database di staging
TTL DNSDibiarkan 3600+ detikDiturunkan ke 300 detik sebelum cutover
Risiko downtimeTinggi, bisa berjam-jamMinimal, rollback dalam menit
Dampak bisnisTransaksi hilang, pelanggan kaburOperasional tetap jalan

Pengecekan Wajib Setelah Pindah Hosting

DNS mengarah ke server baru bukan akhir. Ada tiga area yang sering terlupakan dan justru memicu masalah setelah cutover.

1. SSL/TLS Harus Valid

  • Cek sertifikat: Pastikan sertifikat SSL diterbitkan untuk domain yang benar dan belum kedaluwarsa. Buka situs via https:// dan periksa ikon gembok.
  • Paksa HTTPS: Aktifkan redirect HTTP→HTTPS di server baru agar tidak ada halaman campuran (mixed content).
  • Uji rantai: Gunakan SSL checker online untuk memastikan chain certificate lengkap dan tidak ada error di browser.

2. Email Bisnis Tetap Berfungsi

  • Record MX: Jika email hosted di penyedia lain, pastikan record MX tidak ikut berubah saat pindah nameserver.
  • SPF, DKIM, DMARC: Catat dan salin record TXT terkait email. Hilangnya record ini membuat email masuk spam atau ditolak.
  • Uji kirim-terima: Kirim email dari dan ke alamat bisnis setelah cutover. Cek juga folder spam.

3. Redirect 301 untuk URL Lama

  • Pertahankan struktur URL: Jika struktur berubah, buat redirect 301 dari URL lama ke URL baru agar backlink dan peringkat SEO tidak hilang.
  • Cek halaman populer: Uji halaman produk dan artikel yang paling banyak dikunjungi. Pastikan tidak ada 404.
  • Update sitemap: Kirim ulang sitemap ke Google Search Console setelah migrasi stabil.

Risiko Transaksi Hilang Selama Downtime

Setiap menit toko offline adalah kerugian nyata: pelanggan beralih ke kompetitor, iklan berbayar tetap jalan tanpa konversi, dan kepercayaan merek menurun. Downtime juga merusak sinyal SEO—crawler yang menemukan error 5xx berulang dapat menurunkan peringkat. Karena itu, migrasi tidak boleh diperlakukan sebagai eksperimen. Harus ada rencana, uji, dan jalur rollback.

FAQ Seputar Migrasi Hosting Tanpa Downtime

Berapa lama propagasi DNS biasanya berlangsung?

Propagasi DNS bergantung pada TTL dan resolver. Dengan TTL 300 detik, sebagian besar pengguna melihat server baru dalam 5–30 menit. Namun beberapa ISP atau resolver publik bisa menyimpan cache lebih lama. Karena itu, turunkan TTL minimal 24–48 jam sebelum cutover agar perubahan cepat terdistribusi.

Apakah saya perlu mematikan situs lama saat pindah hosting?

Tidak. Justru sebaliknya: biarkan situs lama tetap melayani pelanggan selama server baru diuji. Setelah server baru siap dan DNS diarahkan, situs lama otomatis tidak lagi menerima trafik. Matikan hanya setelah migrasi stabil 24–48 jam dan backup final sudah dibuat.

Kesimpulan: Migrasi Tanpa Downtime, Bisnis Tetap Jalan

Migrasi hosting tanpa downtime bukan sulit, tapi butuh urutan disiplin: backup penuh dan teruji, uji server baru, turunkan TTL, arahkan DNS, lalu verifikasi SSL, email, dan redirect. Lewati satu langkah, dan toko berisiko offline sehari penuh.

Jika tim Anda tidak punya waktu atau kapasitas teknis untuk mengawal proses ini, Avoca Code menyediakan layanan migrasi hosting tanpa downtime—dari audit DNS, backup, uji staging, hingga cutover dan verifikasi pasca-pindah. Konsultasikan kebutuhan migrasi Anda di avocacode.id dan pastikan toko online tetap melayani pelanggan tanpa jeda.

Komentar Diskusi (0)

Tulis Komentar Diskusi

Belum ada komentar. Jadilah yang pertama berkomentar!

Chat WhatsApp