Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Analisis portofolio dan perencanaan migrasi
Tahap ini berfokus pada iterasi tampilan tingkat portofolio, menutup kesenjangan data, dan memperoleh lebih banyak data untuk menghasilkan rencana gelombang migrasi kepercayaan tinggi untuk seluruh portofolio.
Para pemangku kepentingan tahap ini biasanya merupakan campuran dari dua tahap sebelumnya. Mereka termasuk CxOs dan pemimpin senior, tim migrasi dan platform, dan arsitek TI dan Enterprise. Kuncinya adalah untuk menambah kesetiaan data tingkat portofolio melalui iterasi dan penyempurnaan.
Tip
Untuk detail dan panduan, lihat bagian yang relevan dalam panduan penilaian portofolio aplikasi untuk AWS Cloud migrasi.
High-level tujuan dan tindakan
-
Menetapkan dasar untuk portofolio aplikasi dan infrastruktur terkait - Mengulangi data tingkat portofolio, membangun dari percepatan penemuan dan tahap perencanaan awal, untuk menutup kesenjangan dan menghasilkan pandangan tingkat tinggi dari seluruh portofolio aplikasi. Pada tahap ini, penting untuk menyempurnakan pemetaan aplikasi-ke-infrastruktur, data penggunaan, dan atribut metadata aplikasi. Atribut ini termasuk kepemilikan, kekritisan, dan fungsi utama dari setiap aplikasi.
-
Dapatkan dan analisis data ketergantungan (biasanya dengan menggunakan alat penemuan khusus) - Untuk memvalidasi aplikasi dan membantu pembuatan rencana gelombang migrasi, data ketergantungan aplikasi dengan kepercayaan tinggi adalah kunci pada tahap ini. Data ketergantungan mencakup data komunikasi, seperti volume dan frekuensi komunikasi antar sistem, dan dependensi nonteknis, seperti pertimbangan operasional. Dependensi ini menentukan aplikasi mana yang harus bergerak pada saat yang sama dan aplikasi mana yang dapat beroperasi dari lokasi yang berbeda.
-
Mengidentifikasi dan memvalidasi persyaratan kepatuhan dan peraturan — Mengidentifikasi dan memvalidasi kerangka kerja, aturan, bukti, dan persyaratan dokumentasi.
-
Ubah asumsi menjadi fakta — Berapa banyak yang telah diasumsikan pada tahap sebelumnya? Ini adalah kunci dalam tahap ini untuk mengurangi jumlah asumsi seminimal mungkin.
-
Tetapkan garis dasar untuk model rasionalisasi portofolio migrasi — Iterasi model dari tahap sebelumnya (misalnya, kriteria prioritas aplikasi dan pohon keputusan 6 Rs). Validasi model dengan menerapkannya ke seluruh portofolio aplikasi.
-
Mendokumentasikan hasil bisnis yang terukur — Untuk menyelaraskan gelombang migrasi dengan tujuan bisnis, mengidentifikasi hasil bisnis dan indikator utama kunci terkait (KPI) untuk setiap gelombang migrasi.
-
Kembangkan kasus bisnis terarah — Ganti tolok ukur dengan data pemanfaatan dan biaya aktual, dan perbaiki biaya migrasi sesuai dengan rencana gelombang yang diperbarui. Memperluas cakupan untuk memasukkan nilai yang diharapkan penuh dari setiap hasil bisnis yang diharapkan, seperti pengurangan biaya, peningkatan produktivitas TI, peningkatan ketahanan, dan kelincahan yang lebih besar.
-
Mendokumentasikan dan mengkomunikasikan tanggal-tanggal penting — Mendokumentasikan dan mengkomunikasikan peristiwa yang menarik (seperti tanggal keluar pusat data, kontrak dan perpanjangan perjanjian lisensi), siklus rilis aplikasi, tanggal migrasi yang harus dihindari, siklus penyegaran teknologi, dan ketersediaan orang.
-
Analisis biaya dan risiko untuk perencanaan gelombang — Berapa banyak perubahan paralel yang dapat didukung atau ditoleransi? Menganalisis persyaratan orang, identifikasi dan mitigasi risiko, kekritisan, dan dampak.
-
Identifikasi persyaratan keterampilan — Berapa tingkat kesiapan yang diproyeksikan untuk mendukung berbagai jenis beban kerja di cloud? Apakah rencana gelombang migrasi sejajar dengan kesiapan yang diproyeksikan? Dapatkah tim pendukung memenuhi persyaratan rencana gelombang?
-
Dokumentasikan proses internal — Dokumentasikan informasi tentang proses saat ini yang memengaruhi migrasi cloud, seperti manajemen perubahan, manajemen layanan, papan peninjau arsitektur, penilaian risiko, dan alur kerja persetujuan.
-
Buat rencana gelombang migrasi — Untuk membuat rencana gelombang, gabungkan semua elemen yang sebelumnya dibahas dalam daftar ini. Terapkan kriteria prioritas ke portofolio, dan analisis dependensi untuk menciptakan gelombang aplikasi. Menggabungkan kesiapan platform dan migrasi ke dalam rencana gelombang migrasi. Berapa lama waktu yang dibutuhkan untuk mengimplementasikan AWS infrastruktur dan layanan? Apa yang diperlukan untuk keamanan dan kesiapan operasional? Apa dampaknya terhadap durasi gelombang? Berapa lama waktu yang dibutuhkan untuk mengimplementasikan alat migrasi? Berapa lama waktu yang dibutuhkan untuk mereplikasi data, mengingat penggunaan jaringan dan sistem? Apa itu jendela cutover? Berapa lama waktu yang dibutuhkan untuk memutar kembali?
-
Perbarui alur kerja - Buat proses untuk memasukkan portofolio dan data penilaian aplikasi terperinci ke dalam alur kerja Migrasi dan Zona Pendaratan. Pastikan alur kerja ini dengan jelas menguraikan persyaratan data mereka.
Hasil
-
High-fidelity inventaris aplikasi dan infrastruktur
-
High-level strategi migrasi untuk setiap aplikasi
-
Kasus bisnis terperinci
-
High-confidence rencana gelombang migrasi
Praktik terbaik
-
Pastikan bahwa aplikasi didistribusikan secara merata dalam rencana gelombang migrasi. Pertimbangkan kekritisan dan kompleksitas untuk menghindari kantong kompleksitas yang dapat membuat pemblokir atau menunda migrasi.
-
Prioritaskan aplikasi sederhana yang tidak kritis dalam dua gelombang pertama.
-
Fokus pada menggabungkan prioritas, dependensi, dan penggerak bisnis untuk mengulangi rencana gelombang.
-
Pertimbangkan infrastruktur cloud, keamanan, dan kesiapan operasional (termasuk keterampilan) saat membuat rencana gelombang.
-
Bangun rencana gelombang sehingga panjang gelombang migrasi, biasanya berkisar 4-8 minggu, menguraikan perjalanan aplikasi. Setiap gelombang harus mencakup hal-hal berikut:
-
Penilaian terperinci
-
Kesiapan migrasi
-
Membangun dan menguji infrastruktur
-
Transfer data
-
Pemotongan aplikasi dalam gelombang
-
Penutupan gelombang (misalnya, pelajaran yang dipetik, penyelesaian masalah pasca-migrasi)
-
Tentukan dan gunakan struktur gelombang default untuk menerapkan model pabrik migrasi yang mencakup penilaian terperinci, desain, implementasi, pengujian, pemotongan, dan validasi.