Strategi prioritas dan migrasi

Elemen kunci dari perencanaan migrasi adalah menetapkan kriteria prioritas. Inti dari latihan ini adalah untuk memahami urutan aplikasi yang akan dimigrasikan. Strateginya adalah mengambil pendekatan berulang dan progresif untuk mengembangkan model prioritas.

Memprioritaskan aplikasi

Tahap penilaian ini berfokus pada penetapan kriteria awal untuk memprioritaskan beban kerja berisiko rendah dan kompleksitas rendah. Beban kerja ini adalah kandidat yang baik untuk aplikasi percontohan. Menggunakan beban kerja berisiko rendah dan kompleksitas rendah dalam migrasi awal mengurangi risiko dan memberi tim kesempatan untuk mendapatkan pengalaman. Kriteria ini akan dikembangkan dalam tahap penilaian lebih lanjut untuk menyelaraskan prioritas dengan penggerak bisnis saat membuat rencana gelombang migrasi.

Kriteria awal harus memprioritaskan aplikasi dengan sejumlah kecil dependensi, berjalan di infrastruktur yang didukung cloud, dan dari lingkungan non-produksi. Contohnya adalah aplikasi dengan 0-3 dependensi siap direhost apa adanya di lingkungan pengembangan atau pengujian. Kriteria ini berlaku untuk mendefinisikan aplikasi percontohan dan berpotensi gelombang migrasi pertama dan kedua, tergantung pada tingkat kematangan adopsi cloud dan tingkat kepercayaan.

Memutuskan kriteria awal apa yang akan digunakan

Pilih 2—10 titik data yang akan digunakan untuk memprioritaskan beban kerja pertama Anda. Poin data ini berasal dari inventaris aplikasi dan infrastruktur awal Anda (lihat bagian pengumpulan data).

Selanjutnya, tentukan skor, atau bobot, untuk setiap nilai yang mungkin dari setiap titik data. Misalnya, jika atribut lingkungan dipilih, dan nilai yang mungkin adalah produksi, pengembangan, dan pengujian, setiap nilai diberi skor, angka yang lebih besar mewakili prioritas yang lebih tinggi. Meskipun opsional, kami merekomendasikan untuk menetapkan faktor pengganda untuk kepentingan atau relevansi dengan setiap titik data. Langkah opsional ini memberikan pembeda tingkat yang lebih tinggi untuk menekankan apa yang lebih penting, yang membantu menjaga kriteria tetap selaras saat Anda mengulangi penetapan skor ke nilai.

Berdasarkan strategi untuk memprioritaskan aplikasi sederhana dan berisiko rendah untuk beberapa gelombang migrasi pertama, tabel berikut menunjukkan contoh pemilihan atribut dan penetapan nilainya.

Atribut (titik data)	Nilai yang mungkin	Skor (0-99)	Pentingnya atau relevansi faktor pengalikan
Environment	Uji	60	Tinggi (1x)
	Pengembangan	40
	Produksi	20
Kekritisan bisnis	Rendah	60	Tinggi (1x)
	Sedang	40
	Tinggi	20
Kerangka peraturan atau kepatuhan	Tidak ada	60	Tinggi (1x)
	FedRAMP	10
Dukungan sistem operasi	Cloud siap	60	Sedang tinggi (0.8x)
	Tidak didukung di cloud	10
Jumlah instans komputasi	1-3	60	Sedang tinggi (0.8x)
	4-10	40
	11 atau lebih	20
Strategi migrasi	Rehost	70	Sedang (0.6x)
	Platform Ulang	30
	Refactor, atau arsitek ulang	10

Pastikan Anda memilih atribut yang dapat bertindak sebagai pembeda utama antar aplikasi. Jika tidak, kriteria akan menghasilkan banyak beban kerja yang berbagi prioritas yang sama. Setelah Anda menerapkan model, kami sarankan untuk melihat bagian atas dan bawah peringkat yang dihasilkan untuk melihat apakah Anda setuju. Jika Anda umumnya tidak setuju, Anda dapat meninjau kembali kriteria yang Anda gunakan untuk menilai beban kerja.

Setelah Anda mendapatkan peringkat, lihat distribusi skor di seluruh portofolio. Skor itu sendiri tidak masalah. Ini adalah perbedaan antara skor yang penting. Misalnya, Anda mungkin menemukan bahwa skor total teratas adalah 8.000 dan skor terbawah adalah 800. Pertimbangkan untuk memplot skor yang dihasilkan sebagai histogram, sehingga Anda dapat memverifikasi bahwa Anda memiliki distribusi yang baik. Distribusi yang ideal terlihat seperti kurva lonceng standar, dengan beberapa beban kerja prioritas sangat tinggi dan beberapa beban kerja dengan prioritas sangat rendah. Sebagian besar aplikasi akan berada di suatu tempat di tengah.

Aspek kunci lain dari prioritas awal adalah memasukkan tim internal atau unit bisnis yang menunjukkan minat untuk menjadi pengadopsi awal cloud. Ini bisa menjadi tuas yang cukup besar dalam memperoleh dukungan bisnis untuk memigrasikan aplikasi tertentu, terutama di masa-masa awal. Jika ini terjadi di organisasi Anda, sertakan atribut unit bisnis di tabel sebelumnya. Tetapkan skor tinggi untuk unit-unit bisnis yang bersedia untuk maju dengan aplikasi mereka. Menggunakan atribut unit bisnis akan membantu membawa aplikasi tersebut ke bagian atas daftar.

Setelah Anda setuju dengan peringkat yang dihasilkan, pilih 5-10 aplikasi teratas. Ini akan menjadi kandidat migrasi aplikasi awal Anda. Perbaiki daftar sehingga Anda mengonfirmasi 3-5 aplikasi. Ini membantu Anda mengambil pendekatan yang ditargetkan saat melakukan penilaian aplikasi terperinci. Untuk informasi selengkapnya, lihat Penilaian aplikasi yang diprioritaskan.

Menentukan tipe R untuk migrasi

Memutuskan strategi migrasi untuk setiap aplikasi dan infrastruktur terkait akan berimplikasi pada kecepatan migrasi, biaya, dan tingkat manfaat. Ini adalah kunci untuk menentukan strategi berdasarkan kombinasi faktor yang seimbang, termasuk pendorong bisnis, prinsip panduan teknis, kriteria prioritas, dan strategi bisnis.

Terkadang faktor-faktor ini menciptakan pandangan yang saling bertentangan. Misalnya, pendorong utama migrasi mungkin inovasi dan kelincahan. Pada saat yang sama, Anda mungkin perlu mengurangi biaya dengan cepat. Memodernisasi semua aplikasi dalam lingkup akan mengurangi biaya dalam jangka panjang, tetapi akan membutuhkan investasi yang lebih besar di muka. Dalam hal ini, salah satu pendekatannya adalah memigrasikan aplikasi dengan menggunakan strategi yang membutuhkan lebih sedikit usaha, seperti rehost atau replatform. Itu dapat memberikan efisiensi cepat dan pengurangan biaya dalam jangka pendek. Kemudian investasikan kembali tabungan untuk memodernisasi aplikasi pada tahap selanjutnya, dan mencapai pengurangan biaya lebih lanjut.

Namun, dimulai dengan rehost lengkap dari semua aplikasi menunda manfaat modernisasi yang lebih besar. Kuncinya adalah menemukan keseimbangan antara strategi migrasi sehingga aplikasi strategis bisnis diprioritaskan untuk modernisasi sementara aplikasi lain dapat di-host ulang atau direplatform terlebih dahulu kemudian dimodernisasi.

Bagaimana cara menentukan strategi migrasi untuk aplikasi Anda?

Pada tahap penilaian ini, fokusnya adalah untuk menggabungkan model awal untuk memandu pemilihan strategi migrasi. Untuk memvalidasi strategi migrasi untuk aplikasi awal, gunakan model bersama dengan driver bisnis dan kriteria prioritas. Logika default dari pohon keputusan akan membantu Anda menentukan perlakuan awal untuk ruang lingkup. Di pohon, pendekatan yang paling kompleks, seperti refactor, atau arsitek ulang, disediakan untuk beban kerja strategis Anda.

Versi draw.io yang dapat disesuaikan dari diagram ini tersedia di bagian Lampiran.

Langkah pertama untuk model awal adalah memperbarui driver bisnis di bagian atas pohon dengan yang ditentukan oleh organisasi Anda. Selanjutnya, terapkan pohon ke komponen aplikasi daripada aplikasi secara keseluruhan. Misalnya, dalam kasus aplikasi tiga tingkat yang memiliki tiga komponen (front-end, lapisan aplikasi, dan database), setiap komponen harus transit pohon secara independen dan diberi strategi dan pola tertentu. Ini karena dalam beberapa kasus Anda mungkin ingin meng-host ulang atau memplatform ulang tingkat tertentu dan refactor (arsitek ulang) tingkatan lain.

Penugasan komponen independen akan mengarahkan Anda untuk menentukan strategi migrasi untuk infrastruktur terkait. Strategi infrastruktur mungkin strategi yang sama dengan komponen aplikasi yang didukungnya, atau mungkin berbeda. Misalnya, komponen aplikasi yang akan direplatform menjadi mesin virtual baru dengan sistem operasi yang lebih baru akan mengikuti strategi replatform sementara mesin virtual saat ini yang menghostingnya akan dihentikan. Strategi migrasi untuk infrastruktur dihitung berdasarkan strategi yang dipilih untuk komponen aplikasi.

Sebelum menggunakan pohon keputusan untuk membuat strategi migrasi, uji logika dengan beberapa aplikasi dan lihat apakah Anda umumnya setuju dengan hasilnya. Pohon keputusan 6 Rs adalah panduan yang tidak menggantikan analisis yang diperlukan untuk menentukan kebenarannya. Logika pohon mungkin tidak berlaku untuk kasus tertentu. Perlakukan kasus-kasus tersebut sebagai pengecualian dan lanjutkan untuk mengganti keputusan yang didorong oleh pohon dengan mendokumentasikan alasan untuk penggantian daripada mengubah logika pohon. Ini mencegah beberapa versi pohon keputusan, yang bisa menjadi sulit untuk dikelola. Panduan umum adalah bahwa pohon harus berlaku untuk setidaknya 70-80 persen dari beban kerja. Selebihnya, akan ada pengecualian. Setiap penyesuaian pada logika pohon, pada tahap penilaian ini, harus difokuskan pada pembentukan model awal. Iterasi dan penyempurnaan lebih lanjut akan terjadi pada tahap selanjutnya, seperti analisis portofolio dan perencanaan migrasi.

Lampiran

attachment.zip