Pindah hosting sering terlihat sederhana: salin file, ekspor database, lalu arahkan domain ke server baru. Kenyataannya, banyak masalah justru muncul setelah DNS berubah—website menampilkan error, email berhenti masuk, sertifikat SSL belum aktif, atau versi PHP di server baru tidak cocok dengan aplikasi.
Karena itu, migrasi sebaiknya diperlakukan seperti memindahkan toko, bukan sekadar memindahkan kardus. Toko lama tetap harus melayani pelanggan sampai toko baru benar-benar siap. Prinsip yang sama berlaku untuk website: siapkan server baru, lakukan pengujian, baru ubah jalur akses publik.
Kenapa migrasi hosting perlu direncanakan?
Setiap website memiliki kombinasi komponen yang berbeda. WordPress membutuhkan file, database, konfigurasi, plugin, dan kadang aturan khusus di .htaccess. Toko online mungkin memiliki transaksi yang terus masuk. Website dengan email domain juga bergantung pada konfigurasi DNS seperti MX, SPF, DKIM, dan DMARC.
Artinya, satu checklist tidak selalu cukup untuk semua website. Namun ada urutan umum yang dapat mengurangi risiko: inventarisasi, persiapan, penyalinan, pengujian, perubahan DNS, lalu pemantauan.
1. Buat inventaris sebelum menyentuh server
Sebelum membeli paket baru atau menghapus akun lama, catat apa saja yang saat ini berjalan. Informasi ini menjadi peta saat terjadi masalah.
- Nama domain utama dan subdomain.
- Lokasi file website dan ukuran penggunaannya.
- Nama database, versi database, dan ukuran database.
- Versi PHP, framework, CMS, atau aplikasi yang digunakan.
- Alamat email berbasis domain dan akun yang aktif.
- DNS record penting, termasuk A, CNAME, MX, TXT, SPF, DKIM, dan DMARC.
- Versi SSL dan cara sertifikat diperbarui.
- Cron job, scheduled task, webhook, API key, dan integrasi pihak ketiga.
Jangan hanya mengandalkan ingatan. Simpan hasilnya dalam dokumen sederhana. Jika menggunakan cPanel, Anda dapat memeriksa menu seperti Domains, Email Accounts, MySQL Databases, Cron Jobs, dan Zone Editor.
2. Turunkan TTL DNS sebelum migrasi
TTL, atau time to live, menentukan berapa lama resolver DNS menyimpan informasi sebelum mengambil data baru. TTL yang lebih pendek dapat membantu perubahan DNS menyebar lebih cepat, meskipun tidak menjamin semua pengguna langsung melihat server baru.
Beberapa hari sebelum migrasi, turunkan TTL record yang akan diubah, misalnya record A atau CNAME, dari nilai yang panjang menjadi lebih pendek. Setelah migrasi stabil, TTL dapat dinaikkan kembali agar permintaan DNS tidak perlu terlalu sering dilakukan.
Ini bukan pengganti rencana migrasi. DNS resolver dan jaringan tertentu tetap dapat memiliki perilaku berbeda. Namun, sebagai langkah persiapan, TTL yang lebih pendek memberi Anda ruang untuk melakukan koreksi lebih cepat.
3. Siapkan server baru tanpa mengubah DNS
Bangun lingkungan hosting baru terlebih dahulu. Pastikan domain sudah ditambahkan ke server, tetapi jangan terburu-buru mengganti nameserver atau record publik.
Periksa beberapa hal berikut:
- Versi PHP dan ekstensi yang dibutuhkan aplikasi.
- Batas memori, ukuran unggahan, dan waktu eksekusi.
- Versi database serta karakter set dan collation.
- Struktur folder dan hak akses file.
- Konfigurasi web server, redirect, dan aturan URL.
- Ketersediaan SSL untuk domain dan subdomain.
- Kapasitas disk, CPU, RAM, serta batas proses jika memakai shared hosting.
Perbedaan versi PHP sering menjadi sumber error yang tidak terlihat saat proses penyalinan. Aplikasi lama mungkin masih bergantung pada fungsi yang sudah tidak tersedia di versi baru. Sebaliknya, menyalin lingkungan lama tanpa pembaruan juga dapat mempertahankan konfigurasi yang sudah usang.
4. Salin file dan database dengan urutan yang aman
Buat backup terpisah untuk file dan database. Jangan menganggap backup dari panel hosting otomatis cukup sebelum Anda memeriksa bahwa file backup dapat diunduh dan dibuka.
Untuk website dinamis, database biasanya terus berubah. Jika Anda menyalin database terlalu awal lalu membutuhkan waktu lama untuk pengujian, data baru di server lama tidak ikut terbawa. Cara yang lebih aman adalah melakukan salinan awal untuk pengujian, kemudian membuat salinan akhir sesaat sebelum perpindahan.
Pada tahap akhir, hentikan sementara aktivitas yang menulis data jika memungkinkan. Misalnya, aktifkan mode pemeliharaan untuk toko online atau hentikan formulir tertentu selama beberapa menit. Tujuannya bukan membuat website offline lama, melainkan menghindari transaksi yang masuk ke dua tempat berbeda.
5. Uji website melalui alamat sementara
Jangan menguji hanya dengan membuka halaman depan. Akses beberapa bagian yang mewakili fungsi penting website:
- Halaman depan, halaman artikel, dan halaman dengan gambar.
- Login, logout, reset password, dan halaman admin.
- Formulir kontak atau proses pemesanan.
- Pencarian, pagination, filter, dan URL dengan parameter.
- Unggah file dan pengiriman email.
- Redirect dari URL lama ke URL baru.
- Halaman 404 dan aturan keamanan dasar.
Jika domain belum diarahkan ke server baru, Anda masih dapat menguji menggunakan preview URL, hostname sementara, atau file hosts di komputer lokal. Metode ini berguna untuk melihat website seolah-olah domain sudah menunjuk ke server baru tanpa mengubah akses semua pengunjung.
Perlu diingat, pengujian lokal tidak selalu mewakili kondisi pengguna sebenarnya. Cache DNS, CDN, SSL, dan konfigurasi perangkat lunak keamanan dapat menghasilkan perilaku berbeda setelah website dibuka publik.
6. Periksa email sebelum mengganti nameserver
Website dan email bisa memakai domain yang sama, tetapi jalurnya ditentukan oleh record DNS yang berbeda. Jika Anda mengganti nameserver lalu lupa menyalin record MX, email dapat berhenti masuk.
Catat dan salin semua record email. Jika memakai layanan email pihak ketiga, jangan mengganti MX secara asal. Periksa juga record TXT untuk SPF, DKIM, dan DMARC karena ketiganya membantu server penerima menilai apakah email berasal dari sumber yang sah.
Setelah perubahan DNS, kirim email uji dari dan ke beberapa alamat. Pastikan pesan masuk, balasan diterima, dan tidak langsung gagal karena masalah autentikasi.
7. Ganti DNS, tetapi jangan langsung menghapus hosting lama
Setelah pengujian selesai, lakukan perubahan DNS pada waktu yang paling mudah dipantau. Untuk website bisnis, hindari jam dengan transaksi atau kunjungan tertinggi.
Setelah itu, pantau website dari beberapa jaringan. Periksa halaman utama, login, formulir, transaksi, email, SSL, dan log error. Beberapa pengguna mungkin masih diarahkan ke server lama sementara pengguna lain sudah melihat server baru. Masa transisi ini normal selama data tetap konsisten.
Hosting lama sebaiknya dipertahankan selama beberapa hari atau lebih, tergantung pola trafik dan tingkat risiko website. Menghapusnya segera setelah DNS terlihat berubah dapat membuat Anda kehilangan sumber pembanding ketika ada masalah.
Checklist singkat setelah migrasi
- Website dapat dibuka melalui HTTPS tanpa peringatan sertifikat.
- Redirect HTTP ke HTTPS berjalan sesuai kebutuhan.
- Halaman penting tidak menghasilkan error 404 atau 500.
- Formulir dan email berfungsi.
- Database dapat membaca dan menulis data.
- Cron job dan integrasi eksternal berjalan.
- Backup otomatis sudah aktif di server baru.
- Monitoring uptime dan log error sudah disiapkan.
- DNS record penting sudah dicocokkan dengan catatan awal.
Apa artinya bagi kita?
Migrasi hosting yang aman bukan lomba memindahkan file secepat mungkin. Risiko terbesar biasanya muncul karena ada komponen yang terlupakan: email, cron job, webhook, record DNS, atau data baru yang masuk selama proses berlangsung.
Langkah paling praktis adalah membuat dokumen migrasi satu halaman. Tuliskan kondisi awal, daftar komponen, waktu perubahan DNS, hasil pengujian, dan keputusan kapan hosting lama boleh dihentikan. Dokumen ini mungkin terasa berlebihan untuk website kecil, tetapi sangat membantu ketika masalah muncul pada waktu yang tidak ideal.
Jika website menghasilkan transaksi, menyimpan data pelanggan, atau menjadi bagian penting dari operasional bisnis, pertimbangkan melakukan migrasi percobaan terlebih dahulu. Server baru harus dianggap belum siap sampai fungsi penting benar-benar diuji, bukan hanya sampai halaman depan berhasil dibuka.
– Rio Yotto @rioyotto