Cara Memigrasi Server On-Premises ke AWS (Runbook Sederhana)

Pengantar

Migrasi dari on-prem ke AWS gagal lebih sedikit karena komputasi dan lebih banyak karena kekurangan perencanaan: tujuan cutover yang tidak jelas, ketergantungan yang terabaikan, dan pengujian yang terburu-buru. Panduan ini menjaga proses tetap mudah diikuti sambil tetap operasional. Anda akan mendefinisikan seperti apa kesuksesan, mempersiapkan zona pendaratan minimal, menjalankan peluncuran uji AWS MGN, melakukan cutover dengan percaya diri, dan kemudian mengoptimalkan beban kerja setelah itu aktif.

Apa yang Harus Anda Putuskan Sebelum Memigrasi Apa Pun?

Strategi migrasi mana yang cocok untuk server ini (AWS "7 Rs")?

Cara tercepat untuk menghabiskan waktu adalah dengan memigrasikan hal yang salah. Sebelum Anda menginstal agen apa pun, putuskan strategi migrasi mana yang layak untuk server sehingga Anda tidak mengangkat dan memindahkan sesuatu yang seharusnya dihentikan atau diganti. Dalam praktiknya, banyak tim mulai dengan rehosting untuk kecepatan, kemudian mengoptimalkan setelah beban kerja stabil di AWS.

Namun, itu hanya berfungsi ketika server adalah kandidat "apa adanya" yang baik dan tidak akan menciptakan utang teknis yang mahal segera setelah pemindahan. Jalan pintas keputusan praktis:

• Rehost: bergerak cepat dengan perubahan minimal saat waktu terbatas.
• Replatforming: tetap aplikasi tetapi lakukan penyesuaian kecil agar sesuai dengan AWS.
• Refactor: cadangkan upaya untuk pembeda yang penting bagi bisnis.
• Pembelian Kembali: ganti dengan SaaS alih-alih memigrasi server.
• Pensiun/Pertahankan: hapus sistem yang tidak terpakai atau pertahankan beban kerja terbatas di lokasi.

Sebuah titik pemeriksaan internal yang berguna adalah dengan menanyakan apakah beban kerja memiliki “masa depan cloud.” Jika server nantinya akan dipecah menjadi layanan terkelola atau tercontainer, dokumentasikan itu sekarang dan anggap rehosting sebagai langkah sementara daripada desain permanen.

Apa itu RTO/RPO, Jendela Downtime, dan Pemicu Rollback?

Cutover berhasil ketika keberhasilan dapat diukur. Tentukan waktu henti yang dapat diterima dan toleransi kehilangan data, kemudian catat kondisi yang memaksa rollback. Ini menjaga tujuan migrasi dan mencegah tim dari berimprovisasi selama jendela cutover. Ini juga membantu pemangku kepentingan bisnis untuk menyetujui karena mereka dapat melihat dengan jelas risiko apa yang diterima.

Tentukan dan dokumentasikan:

• RTO: waktu henti maksimum yang dapat diterima.
• RPO: kerugian data maksimum yang dapat diterima.
• Jendela waktu tidak aktif: ketika Anda diizinkan untuk mengalihkan lalu lintas produksi.
• Pemicu rollback: kondisi kegagalan spesifik (gangguan otentikasi, transaksi gagal, ketidaksesuaian data).
• Mekanisme pemindahan: DNS flip, saklar penyeimbang beban, perubahan routing/firewall.

Untuk menjaga rencana rollback tetap realistis, tentukan siapa yang memiliki setiap tindakan selama pemotongan. Misalnya, satu orang memiliki perubahan DNS, satu memiliki validasi aplikasi, dan satu memiliki "keputusan rollback" berdasarkan pemicu di atas.

Apa yang Anda Butuhkan Siap di AWS dan On-Prem Pertama?

Dasar konektivitas dan firewall untuk replikasi

Replikasi hanya berfungsi jika lingkungan sumber dapat mencapai AWS secara konsisten. Penghalang yang paling umum adalah kontrol keluar yang ketat, proksi, dan inspeksi TLS yang mengganggu lalu lintas HTTPS keluar. Validasi konektivitas lebih awal dan jaga agar jalur jaringan tetap stabil selama replikasi awal dan peluncuran pengujian. Di banyak lingkungan, replikasi tidak "diblokir" secara langsung; sebaliknya, penurunan yang tidak teratur atau inspeksi paket menyebabkan perilaku tidak stabil yang sulit didiagnosis kemudian.

Pola konektivitas umum:

• Egress internet publik (paling sederhana ketika diizinkan)
• VPN site-ke-site (umum untuk konektivitas pribadi)
• Koneksi Langsung (lebih dapat diprediksi untuk lingkungan yang lebih besar)

Pemeriksaan pra-penerbangan:

• Outbound HTTPS berfungsi dengan andal dari jaringan sumber
• Perilaku proxy dipahami dan diuji dengan alur migrasi
• Tim keamanan menyetujui egress yang diperlukan untuk jendela migrasi

Jika lingkungan Anda sangat terkunci, tambahkan langkah "pembuktian jaringan" singkat ke rencana gelombang Anda: validasi titik akhir dari satu server pilot, lalu replikasi set aturan yang sama persis untuk sisa gelombang.

Minimal checklist zona pendaratan AWS

Anda tidak perlu zona pendaratan yang sempurna untuk memulai, tetapi Anda perlu target yang konsisten yang tidak akan berubah di tengah gelombang. Jaga agar pembangunan tetap minimal, tetapi disengaja, sehingga pengujian mencerminkan seperti apa pemindahan itu nantinya. Banyak masalah migrasi berasal dari pintasan jaringan "sementara" yang menjadi permanen karena tidak ada yang punya waktu untuk membangunnya kembali setelah peluncuran.

Elemen minimum zona pendaratan:

• A VPC dan subnet di mana instansi akan diluncurkan (sering terpisah antara pengujian dan produksi)
• Grup keamanan selaras dengan alur aplikasi yang sebenarnya (hindari "buka sekarang, perbaiki nanti")
• IAM siap untuk operasi migrasi dan akses serta alat hari kedua
• Dasar penandaan sehingga kepemilikan dan pelacakan biaya menjadi jelas setelah pemindahan

Ini juga membantu untuk memutuskan lebih awal bagaimana admin akan mengakses instance (bastion, VPN SSM) dan bagaimana akses internet keluar akan disediakan (gerbang NAT, proxy). Pilihan ini mempengaruhi pemeliharaan, agen pemantauan, dan pemecahan masalah pada hari pertama.

Daftar periksa kesiapan server sumber

Migrasi yang bersih bergantung pada sumber yang bersih. Konfirmasikan bahwa beban kerja kompatibel dengan metode yang Anda pilih, kemudian identifikasi apa pun yang bergantung pada asumsi lokal yang akan berubah di AWS. Ini juga di mana Anda menandai server "kasus khusus" yang mungkin memerlukan urutan yang berbeda. Misalnya, server file dengan aktivitas tulis yang berat mungkin memerlukan jendela pemotongan yang lebih ketat dan validasi yang lebih ketat untuk file dan berbagi yang terbuka.

Pemeriksaan kesiapan yang mencegah kejutan:

• Kompatibilitas OS/ben workload dengan pendekatan migrasi
• Disk yang cukup dan I/O yang stabil untuk overhead replikasi
• Ketergantungan yang dipetakan: DNS , AD/LDAP , internal PKI/sertifikat , basis data, berbagi
• Kerapuhan tersembunyi: IP yang dikodekan secara keras, TLS warisan, tugas terjadwal yang tidak umum
• Kasus khusus yang ditandai lebih awal: pengendali domain, kluster, perangkat, lisensi dongle

Sebelum meninggalkan langkah ini, tangkap item "harus tetap sama" seperti hostname, persyaratan alamat IP, atau pengikatan sertifikat, karena ini secara langsung mempengaruhi pengaturan peluncuran AWS Anda dan urutan pemindahan Anda.

Bagaimana Anda Memigrasikan Server ke AWS dengan AWS MGN?

Inisialisasi MGN dan atur default replikasi

Inisialisasi AWS MGN di Wilayah tempat server akan berjalan, kemudian tentukan default replikasi agar eksekusi gelombang tetap konsisten. Template yang stabil mengurangi variasi per-server dan membuat pemecahan masalah dapat diulang. Anggap ini sebagai prosedur operasi standar Anda untuk replikasi, mirip dengan gambar emas di lingkungan virtualisasi.

Atur default replikasi di awal:

• Strategi subnet target dan penempatan jaringan
• Dasar grup keamanan untuk instans yang diluncurkan
• Perilaku penyimpanan (pemetaan volume, enkripsi harapan)
• Pengaturan pembatasan replikasi untuk melindungi lalu lintas produksi

Jika Anda sudah tahu bahwa produksi akan memerlukan pengaturan yang berbeda dari pengujian, tentukan perbedaan tersebut secara eksplisit. Dengan cara itu, peluncuran pengujian tetap representatif tanpa mengekspos jaringan produksi terlalu dini.

Instal agen dan selesaikan sinkronisasi awal

Instal agen replikasi di server sumber dan pastikan ia terdaftar dengan sukses. Sinkronisasi awal adalah di mana ketidakstabilan paling merugikan Anda, jadi hindari perubahan yang tidak perlu dan pantau kesehatan replikasi dengan cermat. Ini juga di mana tim mendapatkan manfaat dari mendokumentasikan alur instalasi "yang diketahui baik" sehingga mereka tidak memecahkan masalah yang sama di setiap gelombang.

Panduan operasional:

• Jaga server tetap stabil selama replikasi awal (hindari reboot jika memungkinkan)
• Pantau status replikasi dan tangani kesalahan segera.
• Dokumentasikan metode instalasi agar gelombang mendatang konsisten

Selama sinkronisasi awal, pantau tidak hanya konsol migrasi tetapi juga kinerja server. Beban replikasi dapat mengungkapkan kemacetan penyimpanan atau kesalahan disk yang sebelumnya tersembunyi di lingkungan lokal.

Luncurkan instance uji dan validasi

Peluncuran uji coba mengubah asumsi menjadi bukti. Luncurkan instance uji, lalu validasi kesehatan aplikasi dari awal hingga akhir, bukan hanya keberhasilan boot. Gunakan daftar periksa agar pengujian dapat diulang di seluruh server dan gelombang. Jika pengguna akhir akan terhubung melalui TSplus Remote Access , sertakan pemeriksaan jalur akses dalam validasi. Konsistensi penting karena memungkinkan Anda membandingkan hasil antara beban kerja dan menemukan pola, seperti masalah resolusi DNS yang mempengaruhi beberapa server.

Daftar periksa validasi minimum:

• Boot selesai dan layanan dimulai dengan bersih
• Uji asap aplikasi berhasil untuk alur kerja kunci
• Autentikasi berfungsi (AD/LDAP/lokal)
• Jalur data berfungsi (koneksi DB, berbagi file, integrasi)
• Pekerjaan terjadwal dan layanan latar belakang berjalan seperti yang diharapkan
• Logs dan pemantauan sinyal muncul di tempat yang diharapkan oleh tim ops Anda

Tambahkan satu langkah lagi yang sering dilewati tim: validasi bagaimana pengguna sebenarnya akan mengakses aplikasi, termasuk pengaturan routing internal, aturan firewall, dan sistem hulu lainnya. Sebuah server dapat "sehat" tetapi tidak dapat dijangkau dalam praktik.

Luncurkan pemindahan dan finalisasi

Cutover adalah perpindahan yang terkontrol, bukan lompatan iman. Bekukan perubahan, jika memungkinkan, lakukan pemindahan lalu lintas menggunakan mekanisme yang direncanakan, kemudian validasi menggunakan daftar periksa yang sama seperti pengujian. Jaga kepemilikan rollback tetap eksplisit agar keputusan cepat. Anggap ini sebagai buku panduan yang dapat diulang: semakin sedikit Anda berimprovisasi, semakin rendah risikonya.

Dasar-dasar pelaksanaan cutover:

• Konfirmasi rencana pembekuan perubahan dan komunikasi
• Luncurkan instance cutover dan alihkan lalu lintas (DNS/LB/routing)
• Jalankan kembali daftar periksa validasi dengan fokus tambahan pada integritas data
• Terapkan pemicu rollback jika diperlukan dan kembalikan lalu lintas dengan bersih.
• Selesaikan pemindahan dan hapus atau hentikan sumber daya uji.

Segera setelah pemindahan, tangkap apa yang berubah di produksi (IP baru, rute baru, aturan grup keamanan baru) dan dokumentasikan. Ini adalah informasi yang dibutuhkan tim operasional ketika sesuatu rusak beberapa minggu kemudian.

Apa yang Biasanya Rusak, dan Apa yang Harus Anda Lakukan Segera Setelah Peralihan?

Egress jaringan, ketergantungan DNS/AD, dan "lift-and-shift tidak dilakukan"

Kebanyakan kegagalan adalah kegagalan ketergantungan. Replikasi cenderung terputus pada batasan keluar dan proksi, sementara perilaku aplikasi cenderung terputus pada identitas, resolusi nama, dan sertifikat. Bahkan ketika pemindahan berhasil, rehosting hanya merupakan tonggak pertama, bukan keadaan akhir. Tanpa fase kedua, Anda sering kali berakhir dengan "warisan yang dihosting di cloud" yang biayanya lebih tinggi dan lebih sulit untuk dioperasikan.

Titik putus yang paling umum:

• Outbound HTTPS diblokir atau diubah oleh proxy inspeksi TLS
• Perubahan resolusi DNS (masalah split-horizon, aturan resolver yang hilang)
• Kekurangan jangkauan AD/LDAP dari VPC
• Rantai PKI internal hilang atau tidak dipercaya di lingkungan baru
• Endpoint yang dikodekan secara keras dan asumsi warisan tentang jalur jaringan lokal

Mitigasi yang sederhana adalah menguji identitas dan DNS lebih awal dengan peluncuran pilot. Jika dasar-dasar tersebut berfungsi, sisa validasi aplikasi menjadi jauh lebih dapat diprediksi.

Stabilisasi pasca-peralihan: keamanan, cadangan, pemantauan, biaya

48 jam pertama setelah pemindahan harus memprioritaskan stabilitas dan kontrol. Pastikan beban kerja dapat diamati, dipulihkan, dan dikelola dengan aman sebelum Anda menghabiskan waktu untuk optimasi yang lebih dalam. Ini juga merupakan tempat di mana migrasi Anda berhasil dalam jangka panjang, karena operasi hari kedua yang baik mencegah hasil "kami telah memindahkannya, tetapi tidak ada yang ingin mengelolanya".

Tindakan segera setelah pemotongan:

• Konfirmasi pemantauan/pemberitahuan aktif dan dimiliki
• Pastikan cadangan diaktifkan dan lakukan validasi pemulihan.
• Perketat grup keamanan dan terapkan prinsip hak akses minimal IAM
• Standarisasi pendekatan pemeliharaan dan akses administratif (jalur yang dapat diaudit)
• Mulailah penyesuaian setelah Anda mengumpulkan data pemanfaatan yang sebenarnya.
• Terapkan penandaan untuk mencegah penyimpangan biaya "pemilik tidak dikenal"

Setelah stabilitas terbukti, jadwalkan tinjauan optimasi singkat untuk setiap server yang dimigrasi. Bahkan pemeriksaan ringan pada jenis penyimpanan, pilihan keluarga instance, dan strategi kapasitas yang dipesan dapat secara signifikan mengurangi biaya.

Di Mana TSplus Cocok Setelah Anda Memindahkan Server ke AWS?

Setelah beban kerja Windows berjalan di AWS, banyak tim masih memerlukan cara sederhana untuk menerbitkan aplikasi dan desktop Windows kepada pengguna tanpa membangun tumpukan VDI yang berat. TSplus Remote Access menyediakan penerbitan aplikasi dan akses desktop jarak jauh untuk server Windows di AWS, on-prem, atau lingkungan hibrida, dengan administrasi yang sederhana dan lisensi yang dapat diprediksi yang sesuai untuk operasi SMB dan pasar menengah.

Kesimpulan

Migrasi server lokal ke AWS paling berhasil ketika mengikuti buku panduan yang dapat diulang: pilih strategi migrasi yang tepat, validasi ketergantungan, replikasi dengan aman, uji secara realistis, dan lakukan pemindahan dengan pemicu rollback yang jelas. Setelah produksi stabil, alihkan fokus ke operasi hari kedua: penguatan keamanan, validasi cadangan, pemantauan, dan penyesuaian ukuran. Ini mengubah "pindah" menjadi platform yang dapat diandalkan dan terkontrol biayanya.