7 Waktu Terbaik Pindah Hosting Website

Waktu terbaik pindah hosting adalah saat situs sedang sepi, bukan saat penjualan memuncak

Banyak pemilik usaha memindahkan hosting pada momen yang paling buruk. Mereka menunggu sampai situs terasa lambat parah, tagihan menumpuk, atau vendor lama menghilang dari komunikasi, lalu memindahkan situs di tengah promo besar yang sedang berjalan. Keputusan mendadak seperti itu jarang berakhir mulus.

Pindah hosting bukan sekadar menukar tempat penyimpanan berkas. Domain, DNS, email, dan sertifikat harus berpindah bersama dalam satu urutan yang benar. Kalau salah langkah, situs bisa tampil normal sementara email berhenti menerima pesan, atau pengunjung mendarat di halaman kosong.

Anda tidak bisa memilih momen pindah secara asal. Ada jam, tanggal, dan urutan kerja yang membuat proses ini jauh lebih aman. Tujuh pertimbangan berikut menunjukkan waktu terbaik pindah hosting, sekaligus alasan teknis di balik setiap pilihan.

Momen yang salah bukan hanya soal teknis. Ketika situs tidak bisa diakses, pelanggan yang gagal membayar jarang memberi kesempatan kedua. Memilih waktu pindah yang tepat sama pentingnya dengan memilih penyedia hosting yang tepat.

1. Hindari masa puncak penjualan dan kampanye iklan berjalan

Waktu terbaik pindah hosting tidak pernah jatuh pada minggu ketika penjualan Anda paling ramai. Kalau Anda menjalankan toko online, puncak itu biasanya akhir pekan panjang, awal bulan saat gajian, atau tanggal belanja kembar. Memindahkan server tepat di tengah lonjakan pesanan sama dengan sengaja memperbesar risiko kehilangan transaksi.

Kampanye iklan yang sedang berjalan menambah taruhan. Ketika Anda membayar per klik, setiap menit situs tidak stabil berarti uang iklan menguap tanpa hasil. Pengunjung dari iklan datang berbarengan dalam jumlah besar, langsung melihat halaman error, lalu tidak kembali lagi. Jejak buruk ini menempel pada merek Anda, bukan hanya pada server yang bermasalah.

Periksa kalender promosi dan jadwal iklan sebelum memutuskan tanggal. Pilih pekan yang tenang, tanpa flash sale, tanpa pengiriman newsletter besar, dan tanpa peluncuran produk. Sediakan ruang bernapas supaya Anda bisa menangani kendala tanpa dikejar target penjualan. Musim liburan dan akhir tahun juga sebaiknya dihindari. Trafik naik, stok menipis, dan tim Anda sibuk. Menambahkan pekerjaan teknis seperti pindah hosting di periode itu hanya menambah beban yang tidak perlu.

Anda bisa melihat kapan trafik paling sepi lewat laporan analitik bulanan. Cari jam dengan kunjungan dan transaksi terendah, lalu jadikan itu acuan. Untuk toko online, jam sepi biasanya larut malam hingga subuh, bukan sore saat orang baru pulang kerja.

Kalau daftar record dan cadangan belum siap, mulai dari persiapan migrasi website dulu, baru tentukan jadwalnya.

2. Pilih jam trafik rendah supaya rollback mudah

Sebagian praktisi memilih dini hari, sekitar pukul 02.00 sampai 04.00 waktu setempat. Pada jam itu transaksi paling sepi, tim Anda masih bisa bangun bila perlu, dan kesalahan masih bisa dibatalkan sebelum pengunjung pertama datang.

Alasan utamanya bukan menjaga penjualan, melainkan memberi ruang untuk rollback. Kalau cutover gagal, Anda bisa mengembalikan DNS ke server lama tanpa banyak orang menyadarinya. Pada jam sibuk, setiap menit error berubah menjadi komplain yang harus dijawab satu per satu.

Dini hari juga membuat propagasi DNS berjalan saat trafik rendah. Jaringan penyedia internet memperbarui catatan pada jam-jam sepi, sehingga sebagian besar pengunjung sudah diarahkan ke server baru begitu pagi tiba.

Bagi situs yang melayani pelanggan luar negeri, jam sepi lokal Anda bisa justru jam sibuk mereka. Periksa zona waktu pengunjung di analitik sebelum memilih jam. Kalau trafik terbesar datang dari negeri lain, sesuaikan pilihan jamnya, jangan ikut panduan umum begitu saja.

Kalau jadwal pindah harus di siang hari karena alasan operasional, siapkan pengalihan sementara dan pastikan Anda punya akses cepat ke panel DNS. Yang penting, Anda paham cara mengembalikan keadaan bila sesuatu gagal di tengah jalan. Rollback yang cepat bergantung pada satu hal: apakah Anda masih menyimpan salinan konfigurasi lama. Pastikan akses ke panel DNS lama dan data server lama belum dicabut saat cutover. Tanpa keduanya, mengembalikan situs seperti semula bisa memakan waktu jauh lebih lama dari perkiraan.

3. Turunkan TTL ke 300 detik 24 sampai 48 jam sebelumnya

TTL adalah masa berlaku catatan DNS, seberapa lama catatan lama boleh dipakai sebelum disegarkan. Turunkan nilai pada record A dan CNAME ke 300 detik, atau lima menit, minimal 24 sampai 48 jam sebelum cutover.

Kalau Anda lupa menurunkannya, catatan lama dengan TTL panjang masih dipegang banyak jaringan. Saat Anda mengubah DNS, sebagian pengunjung tetap diarahkan ke server lama berjam-jam. Waktu tunggu itu yang sering dianggap situs belum berpindah, padahal hanya propagasi yang lambat.

Angka 300 detik dipilih karena cukup singkat untuk pembatalan cepat, tetapi tidak terlalu agresif sampai membebani server DNS. Setelah semua stabil, naikkan lagi ke nilai normal, misalnya 3600 detik atau satu jam.

Cara menurunkannya beragam tergantung penyedia DNS. Di Cloudflare, nilainya diubah di kolom TTL setiap record. Sebelum itu, salin dulu seluruh catatan lama: A, CNAME, MX, TXT, SPF, DKIM, DMARC, dan record verifikasi pihak ketiga. Catatan itu menjadi jaring pengaman Anda bila ada yang terlewat.

Perlu diingat bahwa perubahan TTL juga tidak langsung berlaku. Catatan lama masih dipakai sampai masa berlakunya habis. Itulah alasan angka 24 sampai 48 jam diberikan, bukan hitungan yang bisa dipercepat dengan menekan tombol.

4. Pastikan server baru dan sertifikat SSL siap sebelum cutover

Jangan mengubah DNS sebelum server tujuan benar-benar siap menerima trafik. Uji dulu situs di server baru lewat pengaturan hosts atau alamat IP sementara. Pastikan basis data tersambung, berkas statis termuat, dan formulir berfungsi.

Sertifikat SSL juga harus sudah terpasang dan valid di server baru. Kalau sertifikat belum diterbitkan, pengunjung akan melihat peringatan keamanan di peramban dan banyak yang langsung menutup tab. Di Cloudflare, mode SSL Full (Strict) malah mewajibkan sertifikat valid di server asal, jadi urusan ini tidak bisa ditunda.

Panduan migrasi DNS dan hosting dari Kinsta merinci urutan pengujian ini dengan rapi, dan bisa Anda pakai sebagai daftar periksa.

Uji juga pengiriman email dari server baru. Ketika nameserver diganti, catatan MX tidak ikut berpindah otomatis dan harus dibuat ulang di penyedia DNS baru. Kalau lupa, website bisa tampil normal sementara email berhenti menerima pesan, karena website memakai record A dan CNAME sedangkan email memakai MX.

Unggah juga berkas terbaru ke server baru tepat sebelum cutover supaya tidak ada konten yang ketinggalan. Cocokkan jumlah berkas dan ukuran basis data antara server lama dan server baru. Ketidakcocokan kecil di sini bisa memaksa Anda mengulang seluruh proses dari awal.

Baca Juga

5 Kesalahan Migrasi Website yang Bikin Rugi

5. Sediakan jendela waktu untuk pengawasan setelah pindah

Memindahkan DNS bukan akhir pekerjaan, melainkan awal pengawasan. Setelah cutover, sisihkan beberapa jam untuk memantau situs dengan tenang. Jangan memilih hari yang penuh rapat, sebab masalah sering muncul justru ketika Anda tidak bisa segera merespons.

Pantau beberapa hal sekaligus: halaman utama, halaman produk, formulir kontak, dan pengiriman email. Kirim email uji ke akun di luar domain Anda untuk memastikan penerimaan pesan berjalan. Periksa juga log server untuk melihat permintaan yang gagal.

Kesalahan kecil seperti tag canonical yang masih menunjuk domain lama mudah dilewatkan saat Anda terburu-buru. Periksa strategi SEO setelah migrasi supaya sinyal ke mesin pencari tetap benar sejak jam pertama.

Untuk memastikan arah DNS sudah benar, periksa dari beberapa jaringan berbeda. Buka situs dari ponsel dengan data seluler, bukan hanya dari komputer kantor. Perbedaan hasil antara dua jaringan itu tanda propagasi masih berjalan.

Catat juga angka dasar sebelum pindah: jumlah kunjungan harian, pesanan, dan email masuk. Tanpa angka dasar, Anda tidak bisa menilai apakah penurunan sementara masih wajar atau sudah menandakan ada URL penting yang salah dialihkan.

6. Jangan gabungkan pindah hosting dengan redesain atau ganti CMS

Godaan terbesar saat pindah hosting adalah sekalian merombak segalanya. Anda mengganti tema, mengubah tata letak, atau malah bermigrasi ke sistem pengelolaan konten yang baru. Google menyarankan perubahan situs dilakukan satu per satu, dan saran itu masuk akal.

Kalau semuanya berubah sekaligus lalu lalu lintas anjlok, Anda tidak punya cara memastikan penyebabnya. Apakah karena server baru, templat baru, atau struktur URL yang ikut berubah? Dengan satu perubahan saja, sumber masalah langsung terlihat.

Dokumentasi Google tentang memindahkan situs dengan perubahan URL menegaskan hal ini. Pisahkan pindah hosting dari redesain, kerjakan berurutan dengan jeda yang jelas.

Kalau redesain memang mendesak, jadwalkan setelah pindah hosting terbukti stabil, misalnya menunggu seminggu. Beri setiap perubahan waktu untuk menunjukkan dampaknya. Urutan yang sabar ini menghemat banyak waktu pemulihan di kemudian hari.

Pisahkan pula urusan domain dari urusan hosting. Kalau sekaligus ingin mengganti nama domain, ubah hosting dulu, biarkan stabil, baru pindahkan domain di lain waktu. Dua pekerjaan besar dalam satu malam adalah resep untuk kebingungan.

7. Jadwalkan pematangan sebelum mematikan server lama dan menaikkan TTL

Setelah DNS diubah, jangan langsung mematikan server lama. Biarkan ia tetap hidup 24 sampai 72 jam, bahkan sampai sekitar satu minggu. Sebagian pengunjung dan bot masih memakai catatan DNS lama, jadi server lama masih melayani permintaan yang datang.

Baru setelah semua stabil, naikkan kembali TTL ke nilai normal. Lakukan perlahan dan pantau lagi, karena perubahan TTL juga butuh waktu menyebar di jaringan. Mematikan server lama terlalu cepat sama dengan menutup pintu bagi pengunjung yang masih dalam perjalanan.

Momen pematangan ini juga waktu yang tepat untuk memeriksa hal-hal sepele yang berdampak besar, seperti record MX email yang dibuat ulang di penyedia DNS baru. Pemeriksaan singkat lewat terminal, misalnya menjalankan dig namadomain.com MX +short, cepat memastikan email Anda benar-benar sampai ke alamat barunya.

Selama masa pematangan, pantau juga cache. Jika Anda memakai Cloudflare, salinan aset di jaringan tepi bisa masih menyajikan versi lama sampai di-purge. Purge saat halaman menunjukkan hasil yang tidak sesuai, bukan setiap kali ada perubahan kecil.

Periksa juga Search Console beberapa hari setelah pindah. Kalau muncul lonjakan error 404 pada URL penting, itu tanda pemetaan pengalihan Anda kurang lengkap dan perlu segera dibenahi.

Kesimpulan: Memilih momen pindah hosting adalah soal disiplin, bukan keberanian. Tunggu sampai penjualan tenang, kerjakan dini hari saat trafik rendah, dan siapkan setiap bagian sebelum menyentuh DNS.

Turunkan TTL jauh hari, pastikan server dan SSL siap, awasi situs setelah cutover, dan jangan mencampurnya dengan redesain. Sisakan waktu pematangan sebelum mematikan server lama, lalu naikkan TTL kembali ke nilai normal.

Mulai sekarang, buatlah satu halaman catatan: tanggal cutover yang tenang, jam 02.00 dini hari, TTL 300 detik, dan daftar uji koneksi serta email. Rencana sependek itu jauh lebih berguna daripada keberanian memindahkan situs pada jam paling sibuk.