Memindahkan Domain dan Hosting Tanpa Melupakan Email Pesantren

Website baru sudah terbuka, tetapi sekretariat tidak menerima email. Perpindahan hosting bisa tampak selesai kalau yang diperiksa hanya beranda.

Masalahnya, satu domain dapat dipakai untuk beberapa pekerjaan sekaligus: website, kotak surat, pengirim email aplikasi, dan alamat subdomain. Saat nameserver diganti tanpa membawa seluruh catatan DNS, layanan lain bisa ikut terganggu.

Karena itu, pindah layanan perlu dimulai dari daftar yang harus tetap berjalan. Bukan dari tombol mengganti nameserver.

Tentukan dulu apa yang sebenarnya dipindahkan #Tautan ke bagian Tentukan dulu apa yang sebenarnya dipindahkan

Ada tiga pekerjaan yang sering disebut dengan nama yang sama:

• Pindah hosting: berkas, database, dan pengaturan aplikasi pindah ke server lain.
• Pindah pengelola DNS: tempat menyimpan record domain berubah.
• Transfer domain: pendaftaran domain berpindah ke registrar lain.

Ketiganya tidak harus dilakukan bersamaan. Website dapat pindah server sementara domain dan DNS tetap di penyedia lama. Email juga dapat tetap berada di penyedia yang sekarang.

Untuk domain yang mengikuti kebijakan transfer ICANN, penguncian pada kondisi tertentu dapat menunda transfer registrar. Baca FAQ transfer ICANN dan ketentuan ekstensi yang dipakai. Jangan menganggap aturan itu berlaku sama untuk semua domain atau menjadi alasan bahwa hosting tidak bisa dipindahkan.

Buat peta layanan sebelum menyentuh pengaturan #Tautan ke bagian Buat peta layanan sebelum menyentuh pengaturan

Catat penyedia domain, nameserver aktif, hosting website, layanan email, dan orang yang memegang akses masing-masing. Tambahkan subdomain yang masih digunakan, termasuk aplikasi administrasi dan pendaftaran bila terpisah.

Simpan salinan zona DNS atau daftar record lengkap. A, AAAA, dan CNAME biasa dipakai untuk arah website; MX mengarahkan email masuk; TXT dapat berisi verifikasi layanan serta autentikasi email. Catat juga record lain yang sudah ada, bukan hanya yang namanya terasa dikenal.

Dokumentasi DNS Cloudflare menjelaskan cara mengelola record dan TTL. TTL berhubungan dengan lama cache record, sehingga perubahan tidak selalu terbaca serentak. Menurunkannya perlu direncanakan sebelumnya; itu tidak menghapus cache yang sudah disimpan dengan nilai lama.

Siapkan server baru tanpa menutup yang lama #Tautan ke bagian Siapkan server baru tanpa menutup yang lama

Periksa kecocokan hosting, pasang aplikasi, dan pulihkan salinan data untuk pengujian di lingkungan yang aman. Jangan membiarkan salinan uji mengirim pengingat atau pesan otomatis ke wali sungguhan. Batasi aksesnya dan matikan pekerjaan keluar yang tidak diperlukan selama uji.

Untuk Pondok CMS, gunakan kebutuhan server, panduan instalasi, serta backup dan pemulihan sebagai rujukan. Pindah server tidak berarti memasang data contoh atau mengosongkan database operasional.

Cadangkan database, unggahan, dan konfigurasi yang dibutuhkan untuk memulihkan layanan. Simpan APP_KEY dengan aman: dokumentasi konfigurasi menyebut kunci ini tidak boleh diubah setelah ada data. Jangan mengirim seluruh .env ke grup percakapan sebagai cara serah terima.

Sepakati kapan pencatatan dihentikan sementara #Tautan ke bagian Sepakati kapan pencatatan dihentikan sementara

Salinan untuk uji dapat tertinggal dari data terbaru. Karena itu, tentukan waktu berhenti menulis data, buat backup akhir, lalu pindahkan salinan terakhir. Beri tahu operator kapan mereka harus berhenti mengisi dan kapan boleh bekerja lagi.

Langkah ini penting untuk pembayaran dan pendaftaran. Jika dua server menerima data secara bersamaan, sebagian catatan dapat tinggal di server lama. Sekadar mengubah DNS kembali tidak akan menyatukan kedua database.

Minta pengelola teknis memastikan cron dan antrean aktif hanya pada lingkungan yang seharusnya bekerja. Dua scheduler yang sama-sama berjalan pada salinan aplikasi dapat menimbulkan pekerjaan atau pemberitahuan yang tidak diinginkan.

Ubah arah layanan sesedikit yang diperlukan #Tautan ke bagian Ubah arah layanan sesedikit yang diperlukan

Kalau yang pindah hanya server website, ubah record website yang relevan sesuai petunjuk hosting baru. Jangan otomatis mengganti MX atau menghapus TXT email. Jika pengelola DNS ikut pindah, pastikan semua record yang masih diperlukan tersedia di tempat baru sebelum nameserver dialihkan.

Jika DNSSEC aktif, koordinasikan perubahan dengan administrator dan penyedia domain. Panduan DNSSEC Cloudflare menjelaskan risiko koneksi ketika nameserver diganti tanpa menyesuaikan DNSSEC. Jangan mematikan atau menyalakan pengaturan keamanan hanya dengan meniru langkah domain lain.

Sesudah alamat menuju server baru, periksa sertifikat HTTPS dan alamat aplikasi. Pada Pondok CMS, APP_URL harus sesuai alamat yang dipakai pengunjung. Lanjutkan dengan pemeriksaan instalasi, lalu uji pekerjaan nyata menggunakan akun yang berhak.

Beranda terbuka bukan tanda akhir #Tautan ke bagian Beranda terbuka bukan tanda akhir

Periksa login, dokumen, unggahan, gambar, pendaftaran, serta pengiriman dan penerimaan email. Bandingkan data akhir dengan catatan sebelum pindah. Pastikan tautan dari surat atau halaman lama tetap menuju tempat yang benar.

Siapkan batas keputusan jika layanan gagal: siapa yang menyatakan harus kembali, data baru mana yang perlu diselamatkan, dan konfigurasi apa yang dipulihkan. Jangan menutup akun hosting lama sebelum hasilnya diterima pengurus dan salinan pemulihan sudah aman.

Catat tanggal perpindahan serta penyedia baru di inventaris layanan. Tujuannya sederhana: saat ada gangguan berikutnya, petugas tidak perlu menebak website berada di mana atau mengapa email masih memakai penyedia yang berbeda.