Kerangka Migrasi 6-R

Kerangka Kerja Migrasi 6-R adalah pendekatan terstruktur untuk mengategorikan cara setiap beban kerja lokal dipindahkan ke cloud. Microsoft dan industri secara luas menggunakan keenam strategi ini — yang juga disebut pola migrasi — agar keputusan portofolio menjadi efisien dan konsisten. Alih-alih menerapkan pendekatan yang sama untuk semua kasus, arsitek menilai setiap aplikasi secara individual dan menetapkan R yang paling sesuai.

Rehost (Lift and Shift) berarti memindahkan beban kerja ke Azure tanpa perubahan kode. Anda mengambil citra VM atau biner aplikasi yang ada dan menjalankannya di IaaS Azure. Ini adalah strategi tercepat dan biasanya digunakan untuk aplikasi lama yang sulit diubah atau organisasi dengan tenggat migrasi yang ketat. Mesin replikasi Azure Migrate mengotomatiskan rehosting untuk sebagian besar VM Windows dan Linux.

Replatform (juga disebut Lift, Tinker, and Shift) mencakup optimalisasi kecil selama migrasi tanpa mengubah arsitektur inti. Contohnya adalah memindahkan basis data MySQL yang dikelola sendiri dari VM ke Azure Database for MySQL, atau mengganti relai SMTP yang di-hosting sendiri dengan Azure Communication Services. Anda memperoleh manfaat layanan terkelola — penambalan, pencadangan, penskalaan — tanpa menulis ulang logika aplikasi.

Rearchitect (atau Refactor) berarti mengubah arsitektur aplikasi secara signifikan untuk memanfaatkan kemampuan cloud-native. Aplikasi .NET monolitik dapat dipecah menjadi layanan mikro yang diterapkan di Azure Container Apps, atau sistem batch berbasis pekerjaan cron dapat diimplementasikan ulang sebagai Azure Functions. Rearchitecting menghasilkan manfaat jangka panjang terbesar dalam skalabilitas dan biaya, tetapi memerlukan investasi paling besar.

Rebuild berarti membuang aplikasi yang ada sepenuhnya dan membangun solusi cloud-native baru. Strategi ini dipilih ketika aplikasi lama terlalu mahal untuk dipelihara, menggunakan tumpukan teknologi yang sudah mencapai akhir masa dukungan, atau tidak dapat memenuhi kebutuhan bisnis meskipun telah dimigrasikan. Rebuild memberikan keuntungan cloud-native maksimum, tetapi memiliki waktu hingga memperoleh nilai paling lama. PaaS Azure dan layanan tanpa server seperti Azure App Service, Azure Functions, dan Cosmos DB adalah target yang umum.

Replace berarti mengganti aplikasi lokal yang ada dengan produk SaaS komersial yang menyediakan fungsi setara atau lebih baik. Contohnya adalah mengganti CRM lokal dengan Dynamics 365, atau server file lama dengan SharePoint Online. Replace menghilangkan pengelolaan infrastruktur sepenuhnya. Konsekuensinya adalah kustomisasi yang lebih terbatas serta kemungkinan upaya migrasi data dan pengelolaan perubahan yang signifikan.

Retire adalah strategi paling sederhana — Anda mengidentifikasi aplikasi yang tidak lagi digunakan, berlebihan, atau telah digantikan, lalu menonaktifkannya alih-alih memigrasikannya. Data penemuan yang dikumpulkan oleh Azure Migrate sering menunjukkan bahwa persentase yang signifikan (terkadang 20–30%) dari server lokal memiliki utilisation yang sangat rendah atau tidak memiliki pengguna aktif. Menonaktifkan aplikasi ini mengurangi cakupan migrasi, biaya lisensi, dan kompleksitas operasional.

Memilih R yang tepat memerlukan analisis terhadap empat faktor untuk setiap aplikasi: kekritisan bisnis, kompleksitas teknis, jadwal migrasi, dan total biaya kepemilikan. Tampilan depan web sederhana tanpa dependensi integrasi merupakan kandidat Rehost yang baik. Aplikasi dengan ratusan prosedur tersimpan dan fitur basis data khusus mungkin memerlukan Rearchitect atau Rebuild. Alat internal bernilai rendah merupakan kandidat utama untuk Retire atau Replace.

Azure Migrate menyediakan fitur Business Case yang secara otomatis menyarankan strategi migrasi untuk server yang ditemukan berdasarkan data utilisation, lisensi, dan harga Azure. Fitur ini mengelompokkan beban kerja ke dalam kategori Rehost, Replatform, dan Akhir Dukungan, sehingga memberi Anda titik awal untuk klasifikasi 6-R. Anda dapat mengganti rekomendasi apa pun dan menambahkan konteks bisnis sendiri sebelum menyelesaikan rencana migrasi.

Setelah setiap aplikasi memiliki R yang ditetapkan, Anda mengelompokkannya ke dalam gelombang migrasi. Kandidat Rehost berisiko rendah biasanya membentuk gelombang pertama untuk membangun kepercayaan tim dan pemahaman terhadap alat. Proyek Rearchitect dan Rebuild berjalan secara paralel dengan jadwal yang lebih panjang. Dependensi antar-aplikasi — misalnya tingkat web yang memanggil basis data bersama — harus diperhatikan agar aplikasi terkait dimigrasikan bersama atau dalam urutan yang benar.

6-R selaras dengan fase Adopt dalam Cloud Adoption Framework milik Microsoft. CAF menyediakan templat perencanaan gelombang, matriks RACI, dan kuesioner penilaian beban kerja yang menerapkan 6-R pada skala perusahaan. Pembatas tata kelola yang ditetapkan selama fase Ready — zona pendaratan, kebijakan, identitas — harus tersedia sebelum gelombang migrasi dimulai agar beban kerja yang dimigrasikan berada di lingkungan yang mematuhi kebijakan sejak hari pertama.

Uji pemahaman Anda tentang konsep Microsoft Azure Fundamentals (AZ-900) dari pelajaran ini.

Dalam pelajaran ini Anda mempelajari: kerangka kerja 6-R (Rehost, Replatform, Rearchitect, Rebuild, Replace, Retire) menyediakan kosakata untuk keputusan migrasi, setiap R memiliki kompromi biaya versus kecepatan yang berbeda, dan Business Case Azure Migrate dapat menyarankan strategi secara otomatis berdasarkan data utilisation. Selanjutnya kita akan mempelajari cara Azure Migrate menemukan dan menilai server lokal.