Cara Migrasi Server ke Cloud: Checklist 13 Langkah yang Kami Pakai

Tahap persiapan: langkah 1 sampai 5

Sebagian besar keberhasilan migrasi ditentukan sebelum satu byte pun dipindahkan. Jangan tergoda mempercepat tahap ini:

• 1. Data seluruh aset: server, aplikasi, basis data, domain, sertifikat, tugas terjadwal, dan lisensi.
• 2. Petakan ketergantungan — apa memanggil apa, termasuk yang tidak terdokumentasi. Pantau lalu lintas jaringan selama beberapa hari untuk menemukan yang tersembunyi.
• 3. Catat kebutuhan sumber daya nyata: CPU, memori, disk, dan bandwidth pada kondisi puncak, bukan rata-rata.
• 4. Identifikasi hal yang tidak bisa dipindahkan: perangkat keras khusus, lisensi terikat perangkat, atau integrasi berbasis alamat IP tetap.
• 5. Tetapkan target waktu pemulihan dan toleransi kehilangan data, karena keduanya menentukan strategi dan biaya migrasi.

Tahap penyiapan: langkah 6 sampai 9

Setelah gambaran lengkap terbentuk, lingkungan tujuan bisa dibangun dengan tepat:

• 6. Rancang lingkungan tujuan: jaringan, keamanan, ukuran instance, dan estimasi biaya bulanan.
• 7. Bangun lingkungan tersebut sebagai kode bila memungkinkan, agar bisa dibuat ulang secara identik.
• 8. Replikasi data awal — berkas dan basis data — sambil server lama tetap melayani pengguna.
• 9. Uji coba menyeluruh memakai berkas host, sebelum DNS diubah. Uji seluruh alur penting, bukan hanya halaman depan.

Tahap perpindahan: langkah 10 sampai 13

Bagian yang paling menegangkan justru menjadi paling singkat bila persiapannya matang:

• 10. Turunkan nilai TTL catatan DNS menjadi 300 detik, minimal 48 jam sebelum cutover.
• 11. Jalankan sinkronisasi selisih data terakhir, bila perlu dengan mode baca-saja sementara agar tidak ada transaksi tertinggal.
• 12. Ubah catatan DNS ke lingkungan baru pada jam dengan trafik terendah, lalu pantau log secara aktif.
• 13. Amati selama beberapa hari dengan server lama tetap menyala, baru matikan setelah semuanya terbukti stabil.

Kesalahan yang paling sering terjadi

Beberapa kesalahan berikut muncul berulang kali pada migrasi yang bermasalah, dan semuanya bisa dicegah:

• Mematikan server lama terlalu cepat sehingga tidak ada jalur kembali.
• Lupa memindahkan tugas terjadwal, sehingga laporan atau sinkronisasi berhenti diam-diam.
• Melupakan email — catatan MX tidak ikut dipindahkan atau justru dipindahkan terlalu dini.
• Tidak menurunkan TTL DNS, sehingga sebagian pengunjung masih diarahkan ke server lama berhari-hari.
• Tidak menguji pemulihan cadangan sebelum migrasi dimulai.
• Menganggap tagihan bulan pertama sebagai biaya tetap, padahal itu justru waktu terbaik untuk optimasi.

Setelah migrasi: pekerjaan yang belum selesai

Migrasi tidak berakhir saat DNS berpindah. Dua sampai empat minggu berikutnya adalah masa ketika pola pemakaian sesungguhnya mulai terlihat, dan di situlah penyesuaian ukuran sumber daya bisa dilakukan dengan percaya diri.

Selain itu, perbarui dokumentasi, hapus aset sisa migrasi yang masih menagih biaya, pastikan pemantauan dan cadangan sudah menunjuk ke lingkungan baru, lalu jadwalkan uji pemulihan pertama di lingkungan yang baru tersebut.

Tahapan migrasi cloud secara garis besar

Seluruh tahapan migrasi cloud bisa diringkas menjadi tiga fase: memahami apa yang ada, menyiapkan tempat baru, lalu memindahkan. Kegagalan hampir selalu terjadi karena fase pertama dipersingkat — dan biayanya baru terasa di fase ketiga.

Fase pertama menghasilkan satu daftar aset yang lengkap beserta ketergantungannya. Fase kedua menghasilkan lingkungan tujuan yang sudah teruji memakai data nyata. Fase ketiga hanya memindahkan lalu lintas — dan kalau dua fase sebelumnya benar, fase ini justru bagian yang paling membosankan.

Proporsi waktunya biasanya mengejutkan orang yang baru pertama kali: sekitar separuh untuk pendataan dan perancangan, sepertiga untuk penyiapan dan pengujian, dan hanya sebagian kecil untuk perpindahan itu sendiri.

Persiapan migrasi server yang sering dianggap sepele

Bagian persiapan migrasi server yang paling sering terlewat bukan hal teknis besar, tapi detail kecil yang tidak ada di dokumentasi mana pun. Tugas terjadwal yang mengirim laporan bulanan. Integrasi dengan mitra yang memakai daftar alamat IP tetap. Sertifikat yang dipasang manual dua tahun lalu.

Cara menemukannya bukan dengan bertanya ke tim IT saja, karena yang tahu bahwa laporan tertentu masih dipakai biasanya orang di bagian keuangan atau operasional. Kami memantau lalu lintas jaringan selama beberapa hari, lalu mengonfirmasi setiap komunikasi yang tidak dikenali ke pemilik prosesnya.

Satu langkah lagi yang wajib sebelum apa pun dimulai: uji pemulihan cadangan yang ada sekarang. Kalau ternyata cadangannya tidak bisa dipulihkan, itu masalah yang jauh lebih mendesak daripada migrasinya.

Uji coba sebelum migrasi memakai data nyata

Tahap uji coba sebelum migrasi tidak cukup memastikan halaman depan bisa dibuka. Yang perlu diuji adalah alur yang benar-benar dipakai: masuk sebagai pengguna, membuat transaksi, mencetak dokumen, menerima notifikasi email, dan menjalankan laporan yang paling berat.

Pengujian dilakukan lewat berkas host di komputer penguji, sehingga server baru bisa diakses penuh dengan nama domain asli tanpa mengubah DNS sama sekali. Ini titik yang paling sering dilewati orang, padahal ia memungkinkan pengujian selengkap apa pun tanpa risiko.

Untuk aplikasi yang trafiknya besar, ada satu pengujian tambahan yang layak: uji beban dengan jumlah pengguna mendekati jam sibuk. Server baru yang spesifikasinya di atas kertas setara belum tentu berperilaku sama, terutama bila jenis penyimpanannya berbeda.

Cutover DNS migrasi dan menekan downtime

Proses cutover DNS migrasi adalah satu-satunya bagian yang benar-benar menimbulkan jeda, dan panjangnya ditentukan oleh persiapan — bukan oleh keberuntungan. Nilai TTL diturunkan menjadi 300 detik minimal 48 jam sebelumnya, supaya perubahan menyebar cepat.

Pada hari perpindahan, sinkronisasi selisih data terakhir dijalankan lebih dulu. Untuk sistem yang menerima transaksi terus-menerus, mode baca-saja sementara dipasang beberapa menit agar tidak ada data yang masuk ke server lama setelah sinkronisasi terakhir — data yang masuk setelah itu akan tertinggal dan sulit direkonsiliasi.

Setelah DNS berpindah, log kedua server dipantau bersamaan. Trafik yang masih mendarat di server lama menunjukkan resolver yang belum memperbarui cache, dan itu normal selama beberapa jam pertama.

Risiko migrasi cloud dan cara menurunkannya

Risiko migrasi cloud yang paling nyata bukan kehilangan data — itu jarang terjadi bila cadangan disiapkan — melainkan gangguan berkepanjangan karena ada komponen yang ternyata tidak berfungsi di lingkungan baru dan tidak ada jalan kembali.

Karena itu aturan yang tidak bisa ditawar: lingkungan lama tidak dimatikan sampai masa observasi selesai, dan datanya dibiarkan utuh. Selama itu berlaku, pengembalian keadaan cukup dengan mengarahkan DNS kembali.

Risiko kedua yang lebih pelan tapi mahal adalah biaya. Tagihan bulan pertama selalu lebih tinggi karena lingkungan sengaja dibuat berlebih. Kalau tidak ada yang meninjaunya setelah pola pemakaian terlihat, angka itu menjadi biaya tetap yang tidak pernah dipertanyakan lagi.