Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Akselerasi penemuan dan perencanaan awal
Tahap pertama penilaian portofolio ini berfokus pada langkah-langkah awal memperoleh dan menganalisis data di tingkat portofolio. Tujuan utamanya adalah untuk mengidentifikasi driver bisnis dan mengumpulkan data umum dari aplikasi dan infrastruktur untuk mendapatkan pandangan awal portofolio. Data ini mencakup atribut teknis dan bisnis tingkat tinggi seperti nama aplikasi, lingkungan, versi produk, kekritisan, nilai kinerja, dan lainnya, seperti yang dijelaskan di bagian [persyaratan data](understanding-initial-assessment-data-requirements.md). Menyelesaikan tahap ini adalah kunci untuk memahami ruang lingkup proyek, mengidentifikasi kandidat migrasi awal, dan menginformasikan kasus bisnis.
## Hasil utama dari tahap ini
+ Penggerak bisnis, hasil, tujuan, dan prinsip panduan teknis yang terdokumentasi.
+ Inventarisasi awal aplikasi dan infrastruktur, dan kesenjangan data yang diidentifikasi. Ini adalah pandangan awal dari portofolio yang akan diulang dan disempurnakan dalam tahap selanjutnya.
+ Kasus bisnis terarah dan perkiraan biaya untuk bermigrasi.
+ Daftar kandidat migrasi awal (misalnya, tiga-lima aplikasi).
+ Ditentukan langkah selanjutnya.
# Memahami persyaratan data penilaian awal
Pengumpulan data dapat memakan banyak waktu dan dengan mudah menjadi pemblokir ketika tidak ada kejelasan tentang data apa yang dibutuhkan dan kapan dibutuhkan. Kuncinya adalah memahami keseimbangan antara apa yang terlalu sedikit dan apa yang terlalu banyak data untuk hasil tahap ini. Untuk fokus pada data dan tingkat kesetiaan yang diperlukan untuk tahap awal penilaian portofolio ini, mengadopsi pendekatan berulang untuk pengumpulan data.
## Sumber data dan persyaratan data
Langkah pertama adalah mengidentifikasi sumber data Anda. Mulailah dengan mengidentifikasi pemangku kepentingan utama dalam organisasi Anda yang dapat memenuhi persyaratan data. Ini biasanya anggota manajemen layanan, operasi, perencanaan kapasitas, pemantauan, dan tim dukungan, dan pemilik aplikasi. Buat sesi kerja dengan anggota kelompok-kelompok ini. Komunikasikan persyaratan data dan dapatkan daftar alat dan dokumentasi yang ada yang dapat menyediakan data.
Untuk memandu percakapan ini, gunakan serangkaian pertanyaan berikut:
+ Seberapa akurat dan mutakhir infrastruktur dan inventaris aplikasi saat ini? Misalnya, untuk database manajemen konfigurasi perusahaan (CMDB), apakah kita sudah tahu di mana celahnya?
+ Apakah kami memiliki alat dan proses aktif yang membuat CMDB (atau yang setara) diperbarui? Jika demikian, seberapa sering diperbarui? Apa tanggal penyegaran terbaru?
+ Apakah inventaris saat ini, seperti CMDB, berisi application-to-infrastructure pemetaan? Apakah setiap aset infrastruktur terkait dengan aplikasi? Apakah setiap aplikasi dipetakan ke infrastruktur?
+ Apakah inventaris berisi katalog lisensi dan perjanjian lisensi untuk setiap produk?
+ Apakah inventaris berisi data ketergantungan? Perhatikan keberadaan data komunikasi seperti server ke server, aplikasi ke aplikasi, aplikasi atau server ke database.
+ Alat apa lagi yang dapat menyediakan informasi aplikasi dan infrastruktur yang tersedia di lingkungan? Perhatikan keberadaan kinerja, pemantauan, dan alat manajemen yang dapat digunakan sebagai sumber data.
+ Apa saja lokasi yang berbeda, seperti pusat data, hosting aplikasi dan infrastruktur kita?
Setelah pertanyaan-pertanyaan ini dijawab, daftarkan sumber data yang Anda identifikasi. Kemudian tetapkan tingkat kesetiaan, atau tingkat kepercayaan, untuk masing-masing dari mereka. Data yang divalidasi baru-baru ini (dalam 30 hari) dari sumber program aktif, seperti alat, memiliki tingkat kesetiaan tertinggi. Data statis dianggap memiliki kesetiaan yang lebih rendah dan kurang dipercaya. Contoh data statis adalah dokumen, buku kerja, diperbarui secara manual CMDBs, atau kumpulan data lain yang tidak dipelihara secara terprogram, atau yang tanggal penyegaran terakhirnya lebih dari 60 hari.
Tingkat kesetiaan data dalam tabel berikut disediakan sebagai contoh. Kami menyarankan Anda menilai persyaratan organisasi Anda dalam hal toleransi maksimum terhadap asumsi dan risiko terkait untuk menentukan tingkat kesetiaan yang sesuai. Dalam tabel, pengetahuan kelembagaan mengacu pada informasi apa pun tentang aplikasi dan infrastruktur yang tidak didokumentasikan.
| **Sumber data** | **Tingkat kesetiaan** | **Cakupan portofolio** | **Komentar** |
| --- |--- |--- |--- |
| Pengetahuan kelembagaan | Rendah - Hingga 25% dari data akurat, 75% nilai atau data yang diasumsikan lebih tua dari 150 hari. | Rendah | Langka, fokus pada aplikasi kritis |
| Basis pengetahuan | Sedang rendah - 35-40% dari data akurat, 65-60% nilai atau data yang diasumsikan berusia 120-150 hari. | Sedang | Tingkat detail yang dipelihara secara manual dan tidak konsisten |
| CMDB | Sedang - \$1 50% dari data akurat, \$1 50% nilai atau data yang diasumsikan berusia 90-120 hari. | Sedang | Berisi data dari sumber campuran, beberapa kesenjangan data |
| VMware Ekspor vCenter | Menengah-tinggi - 75-80% dari data akurat, 25-20% nilai asumsi atau data berusia 60-90 hari. | Tinggi | Mencakup 90% dari perkebunan tervirtualisasi |
| Pemantauan kinerja aplikasi | Tinggi - Sebagian besar data akurat, \$1 5% nilai atau data yang diasumsikan berusia 0-60 hari. | Rendah | Terbatas untuk sistem produksi kritis (mencakup 15% dari portofolio aplikasi) |
Tabel berikut menentukan atribut data yang diperlukan dan opsional untuk setiap kelas aset (aplikasi, infrastruktur, jaringan, dan migrasi), aktivitas spesifik (inventaris atau kasus bisnis), dan kesetiaan data yang direkomendasikan untuk tahap penilaian ini. Tabel menggunakan singkatan berikut:
+ R, untuk yang dibutuhkan
+ (D), untuk kasus bisnis terarah, diperlukan untuk perbandingan biaya kepemilikan total (TCO) dan kasus bisnis terarah
+ (F), untuk kasus bisnis terarah penuh, diperlukan untuk perbandingan TCO dan kasus bisnis terarah yang mencakup biaya migrasi dan modernisasi
+ O, untuk opsional
+ N/A, karena tidak berlaku
**Aplikasi**
| **Nama atribut** | **Deskripsi** | **Inventarisasi dan prioritas** | **Kasus bisnis** | **Tingkat kesetiaan yang disarankan (minimum)** |
| --- |--- |--- |--- |--- |
| Pengidentifikasi unik | Misalnya, ID aplikasi. Biasanya tersedia pada inventaris internal dan sistem kontrol yang ada CMDBs atau lainnya. Pertimbangkan untuk membuat unik IDs setiap kali ini tidak didefinisikan dalam organisasi Anda. | R | R (D) | Tinggi |
| Nama aplikasi | Nama yang dengannya aplikasi ini diketahui organisasi Anda. Sertakan vendor komersial off-the-shelf (COTS) dan nama produk jika berlaku. | R | R (D) | Tinggi medium |
| Apakah COTS? | Ya atau Tidak. Apakah ini aplikasi komersial atau pengembangan internal | R | R (D) | Tinggi medium |
| Produk dan versi COTS | Nama dan versi produk perangkat lunak komersial | R | R (D) | Sedang |
| Deskripsi | Fungsi dan konteks aplikasi utama | R | O | Sedang |
| Kekritisan | Misalnya, aplikasi strategis atau menghasilkan pendapatan, atau mendukung fungsi kritis | R | O | Tinggi medium |
| Tipe | Misalnya, database, manajemen hubungan pelanggan (CRM), aplikasi web, multimedia, layanan bersama TI | R | O | Sedang |
| Lingkungan | Misalnya, produksi, pra-produksi, pengembangan, pengujian, kotak pasir | R | R (D) | Tinggi medium |
| Kepatuhan dan peraturan | Kerangka kerja yang berlaku untuk beban kerja (misalnya, HIPAA, SOX, PCI-DSS, ISO, SOC, FedRAMP) dan persyaratan peraturan | R | R (D) | Tinggi medium |
| Dependensi | Dependensi hulu dan hilir ke aplikasi atau layanan internal dan eksternal. Ketergantungan non-teknis seperti elemen operasional (misalnya, siklus pemeliharaan) | O | O | Rendah medium |
| Pemetaan infrastruktur | Pemetaan ke aset and/or virtual fisik yang membentuk aplikasi | O | O | Sedang |
| Lisensi | Jenis lisensi perangkat lunak komoditas (misalnya, Microsoft SQL Server Enterprise) | O | R | Tinggi medium |
| Biaya | Biaya untuk lisensi perangkat lunak, operasi perangkat lunak, dan pemeliharaan | N/A | O | Sedang |
**Infrastruktur**
| | | | | |
| --- |--- |--- |--- |--- |
| **Nama Atribut** | **Deskripsi** | **Inventarisasi dan prioritas** | **Kasus bisnis** | **Tingkat kesetiaan yang disarankan (minimum)** |
| Pengidentifikasi unik | Misalnya, ID server. Biasanya tersedia pada inventaris internal dan sistem kontrol yang ada CMDBs atau lainnya. Pertimbangkan untuk membuat unik IDs setiap kali ini tidak didefinisikan dalam organisasi Anda. | R | R | Tinggi |
| Nama jaringan | Nama aset dalam jaringan (misalnya, nama host) | R | O | Tinggi medium |
| Nama DNS (nama domain yang sepenuhnya memenuhi syarat, atau FQDN) | Nama DNS | O | O | Sedang |
| Alamat IP dan netmask | Alamat IP and/or publik internal | R | O | Tinggi medium |
| Jenis aset | Server fisik atau virtual, hypervisor, wadah, perangkat, instance database, dll. | R | R | Tinggi medium |
| Nama produk | Vendor komersial dan nama produk (misalnya VMware ESXi, IBM Power Systems, Exadata) | R | R | Sedang |
| Sistem operasi | Misalnya, REHL 8, Windows Server 2019, AIX 6.1 | R | R | Tinggi medium |
| Konfigurasi | CPU yang dialokasikan, jumlah inti, utas per inti, total memori, penyimpanan, kartu jaringan | R | R | Tinggi medium |
| Pemanfaatan | CPU, memori, dan puncak penyimpanan dan rata-rata. Database instance throughput. | R | O | Tinggi medium |
| Lisensi | Jenis lisensi komoditas (misalnya, Standar RHEL) | R | R | Sedang |
| Apakah infrastruktur bersama? | Ya atau Tidak untuk menunjukkan layanan infrastruktur yang menyediakan layanan bersama seperti penyedia otentikasi, sistem pemantauan, layanan cadangan, dan layanan serupa | R | R (D) | Sedang |
| Pemetaan aplikasi | Aplikasi atau komponen aplikasi yang berjalan di infrastruktur ini | O | O | Sedang |
| Biaya | Biaya terisi penuh untuk server bare-metal, termasuk perangkat keras, pemeliharaan, operasi, penyimpanan (SAN, NAS, Object), lisensi sistem operasi, pangsa rackspace, dan overhead pusat data | N/A | O | Tinggi medium |
**Jaringan**
| | | | | |
| --- |--- |--- |--- |--- |
| **Nama Atribut** | **Deskripsi** | **Inventarisasi dan prioritas** | **Kasus bisnis** | **Tingkat kesetiaan yang disarankan (minimum)** |
| Ukuran pipa (Mb/s), redundancy (Y/N) | Spesifikasi tautan WAN saat ini (mis., 1000 MB/s redundan) | O | R | Sedang |
| Pemanfaatan tautan | Puncak dan pemanfaatan rata-rata, transfer data keluar (GB/bulan) | O | R | Sedang |
| Latensi (ms) | Latensi saat ini antara lokasi yang terhubung. | O | O | Sedang |
| Biaya | Biaya saat ini per bulan | N/A | O | Sedang |
**Migrasi**
| | | | | |
| --- |--- |--- |--- |--- |
| **Nama Atribut** | **Deskripsi** | **Inventarisasi dan prioritas** | **Kasus bisnis** | **Tingkat kesetiaan yang disarankan (minimum)** |
| Rehost | Upaya pelanggan dan mitra untuk setiap beban kerja (orang-hari), tarif biaya pelanggan dan Mitra per hari, biaya alat, jumlah beban kerja | N/A | R (F) | Tinggi medium |
| Platform Ulang | Upaya pelanggan dan mitra untuk setiap beban kerja (orang-hari), tarif biaya pelanggan dan mitra per hari, jumlah beban kerja | N/A | R (F) | Tinggi medium |
| Refactor | Upaya pelanggan dan mitra untuk setiap beban kerja (orang-hari), tarif biaya pelanggan dan mitra per hari, jumlah beban kerja | N/A | O | Tinggi medium |
| Pensiun | Jumlah server, biaya dekomisi rata-rata | N/A | O | Tinggi medium |
| Zona pendaratan | Gunakan kembali yang ada (Y/N), daftar AWS Wilayah yang dibutuhkan, biaya | N/A | R (F) | Tinggi medium |
| Orang dan perubahan | Jumlah staf yang akan dilatih dalam operasi dan pengembangan cloud, biaya pelatihan per orang, biaya waktu pelatihan per orang | N/A | R (F) | Tinggi medium |
| Durasi | Durasi migrasi beban kerja dalam lingkup (bulan) | O | R (F) | Tinggi medium |
| Biaya paralel | Kerangka waktu dan tingkat biaya apa adanya dapat dihapus selama migrasi | N/A | O | Tinggi medium |
| Kerangka waktu dan tingkat di mana AWS produk dan layanan, dan biaya infrastruktur lainnya, diperkenalkan selama migrasi | N/A | O | Tinggi medium |
## Mengevaluasi kebutuhan alat penemuan
Apakah organisasi Anda membutuhkan alat penemuan? Penilaian portofolio membutuhkan kepercayaan tinggi, up-to-date data tentang aplikasi dan infrastruktur. Tahap awal penilaian portofolio dapat menggunakan asumsi untuk mengisi kesenjangan data.
Namun, seiring kemajuan yang dicapai, data dengan ketelitian tinggi memungkinkan pembuatan rencana migrasi yang berhasil dan estimasi infrastruktur target yang benar untuk mengurangi biaya dan memaksimalkan manfaat. Ini juga mengurangi risiko dengan mengaktifkan implementasi yang mempertimbangkan dependensi dan menghindari jebakan migrasi. Kasus penggunaan utama untuk alat penemuan dalam program migrasi cloud adalah untuk mengurangi risiko dan meningkatkan tingkat kepercayaan pada data melalui hal-hal berikut:
+ Pengumpulan data otomatis atau terprogram, menghasilkan data yang divalidasi dan sangat tepercaya
+ Akselerasi tingkat di mana data diperoleh, meningkatkan kecepatan proyek dan mengurangi biaya
+ Peningkatan tingkat kelengkapan data, termasuk data komunikasi dan dependensi yang biasanya tidak tersedia CMDBs
+ Memperoleh wawasan seperti identifikasi aplikasi otomatis, analisis TCO, laju operasional yang diproyeksikan, dan rekomendasi pengoptimalan
+ Perencanaan gelombang migrasi kepercayaan tinggi
Ketika ada ketidakpastian tentang apakah sistem ada di lokasi tertentu, sebagian besar alat penemuan dapat memindai subnet jaringan dan menemukan sistem yang merespons permintaan ping atau Simple Network Management Protocol (SNMP). Perhatikan bahwa tidak semua konfigurasi jaringan atau sistem akan memungkinkan lalu lintas ping atau SNMP. Diskusikan opsi ini dengan jaringan dan tim teknis Anda.
Tahap lebih lanjut dari penilaian portofolio aplikasi dan migrasi sangat bergantung pada informasi pemetaan ketergantungan yang akurat. Pemetaan ketergantungan memberikan pemahaman tentang infrastruktur dan konfigurasi yang akan diperlukan AWS (seperti grup keamanan, jenis instance, penempatan akun, dan perutean jaringan). Ini juga membantu pengelompokan aplikasi yang harus bergerak pada saat yang sama (seperti aplikasi yang harus berkomunikasi melalui jaringan latensi rendah). Selain itu, pemetaan ketergantungan memberikan informasi untuk mengembangkan kasus bisnis.
Saat memutuskan alat penemuan, penting untuk mempertimbangkan semua tahapan proses penilaian dan untuk mengantisipasi persyaratan data. Kesenjangan data berpotensi menjadi pemblokir, jadi penting untuk mengantisipasinya dengan menganalisis persyaratan data dan sumber data masa depan. Pengalaman di lapangan menentukan bahwa sebagian besar proyek migrasi yang macet memiliki kumpulan data terbatas di mana aplikasi dalam ruang lingkup, infrastruktur terkait, dan dependensinya tidak diidentifikasi dengan jelas. Kurangnya identifikasi ini dapat menyebabkan metrik, keputusan, dan penundaan yang salah. Memperoleh up-to-date data adalah langkah pertama menuju proyek migrasi yang sukses.
*Bagaimana cara memilih alat penemuan?*
Beberapa alat penemuan di pasar menyediakan fitur dan kemampuan yang berbeda. Pertimbangkan kebutuhan Anda. Dan tentukan opsi yang paling tepat untuk organisasi Anda. Faktor paling umum saat memutuskan alat penemuan untuk migrasi adalah sebagai berikut:
*Keamanan*
+ Apa metode otentikasi untuk mengakses repositori data alat atau mesin analitik?
+ Siapa yang dapat mengakses data, dan apa kontrol keamanan untuk mengakses alat?
+ Bagaimana alat mengumpulkan data? Apakah perlu kredensyal khusus?
+ Kredensi dan tingkat akses apa yang dibutuhkan alat untuk mengakses sistem saya dan mendapatkan data?
+ Bagaimana data ditransfer antar komponen alat?
+ Apakah alat ini mendukung enkripsi data saat istirahat dan dalam perjalanan?
+ Apakah data terpusat dalam satu komponen di dalam atau di luar lingkungan saya?
+ Apa persyaratan jaringan dan firewall?
Pastikan bahwa tim keamanan terlibat dalam percakapan awal tentang alat penemuan.
*Kedaulatan data*
+ Dimana data disimpan dan diproses?
+ Apakah alat tersebut menggunakan model perangkat lunak sebagai layanan (SaaS)?
+ Apakah itu memiliki kemungkinan untuk menyimpan semua data dalam batas-batas lingkungan saya?
+ Dapatkah data disaring sebelum meninggalkan batas-batas organisasi saya?
Pertimbangkan kebutuhan organisasi Anda dalam hal persyaratan residensi data.
*Arsitektur *
+ Infrastruktur apa yang dibutuhkan dan komponen apa yang berbeda?
+ Apakah lebih dari satu arsitektur tersedia?
+ Apakah alat ini mendukung pemasangan komponen di zona keamanan yang terkunci di udara?
*Performa*
+ Apa dampak pengumpulan data pada sistem saya?
*Kompatibilitas dan ruang lingkup*
+ Apakah alat ini mendukung semua atau sebagian besar produk dan versi saya? Tinjau dokumentasi alat untuk memverifikasi platform yang didukung terhadap informasi terkini tentang ruang lingkup Anda.
+ Apakah sebagian besar sistem operasi saya didukung untuk pengumpulan data? Jika Anda tidak tahu versi sistem operasi Anda, cobalah untuk mempersempit daftar alat penemuan untuk mereka yang memiliki jangkauan yang lebih luas dari sistem yang didukung.
*Metode pengumpulan*
+ Apakah alat ini perlu menginstal agen pada setiap sistem yang ditargetkan?
+ Apakah itu mendukung penerapan tanpa agen?
+ Apakah agen dan tanpa agen menyediakan fitur yang sama?
+ Apa proses pengumpulannya?
*Fitur*
+ Apa saja fitur yang tersedia?
+ Dapatkah menghitung total biaya kepemilikan (TCO) dan estimasi AWS Cloud run rate?
+ Apakah itu mendukung perencanaan migrasi?
+ Apakah itu mengukur kinerja?
+ Bisakah itu merekomendasikan AWS infrastruktur target?
+ Apakah itu melakukan pemetaan ketergantungan?
+ Tingkat pemetaan ketergantungan apa yang disediakannya?
+ Apakah itu menyediakan akses API? (misalnya, dapatkah diakses secara terprogram untuk mendapatkan data?)
Pertimbangkan alat dengan fungsi pemetaan ketergantungan aplikasi dan infrastruktur yang kuat dan yang dapat menyimpulkan aplikasi dari pola komunikasi.
*Biaya*
+ Apa model lisensi?
+ Berapa biaya lisensi?
+ Apakah harga untuk setiap server? Apakah itu harga berjenjang?
+ Apakah ada opsi dengan fitur terbatas yang dapat dilisensikan sesuai permintaan?
Alat penemuan biasanya digunakan di seluruh siklus hidup proyek migrasi. Jika anggaran Anda terbatas, pertimbangkan setidaknya 6 bulan. Namun, tidak adanya alat penemuan biasanya mengarah pada upaya manual dan biaya internal yang lebih tinggi.
*Model Support*
+ Tingkat dukungan apa yang disediakan secara default?
+ Apakah ada rencana dukungan yang tersedia?
+ Berapa waktu respons insiden?
*Layanan profesional*
+ Apakah vendor menawarkan layanan profesional untuk menganalisis hasil penemuan?
+ Bisakah mereka mencakup elemen-elemen panduan ini?
+ Apakah ada diskon atau bundel untuk layanan perkakas \$1?
**Tip**
Untuk menemukan dan mengevaluasi alat penemuan, gunakan situs [Discovery, Planning, dan Rekomendasi](https://aws.amazon.com/prescriptive-guidance/migration-tools/migration-discovery-tools/).
*Fitur yang direkomendasikan untuk alat penemuan*
Untuk menghindari penyediaan dan penggabungan data dari beberapa alat dari waktu ke waktu, alat penemuan harus mencakup fitur minimum berikut:
+ **Perangkat lunak** — Alat penemuan harus dapat mengidentifikasi proses yang berjalan dan perangkat lunak yang diinstal.
+ **Pemetaan ketergantungan** — Ini harus dapat mengumpulkan informasi koneksi jaringan dan membangun peta ketergantungan masuk dan keluar dari server dan aplikasi yang sedang berjalan. Selain itu, alat penemuan harus dapat menyimpulkan aplikasi dari kelompok infrastruktur berdasarkan pola komunikasi.
+ **Penemuan profil dan konfigurasi** - Ini harus dapat melaporkan profil infrastruktur seperti keluarga CPU (misalnya, x86, PowerPC), jumlah inti CPU, ukuran memori, jumlah disk dan ukuran, dan antarmuka jaringan.
+ **Penemuan penyimpanan jaringan** — Ini harus dapat mendeteksi dan memprofilkan berbagi jaringan dari penyimpanan terlampir jaringan (NAS).
+ **Kinerja** — Ini harus dapat melaporkan puncak dan rata-rata pemanfaatan CPU, memori, disk, dan jaringan.
+ **Analisis kesenjangan** — Ini harus dapat memberikan wawasan tentang kuantitas dan kesetiaan data.
+ **Pemindaian jaringan** — Ini harus dapat memindai subnet jaringan dan menemukan aset infrastruktur yang tidak diketahui.
+ **Pelaporan** — Harus dapat memberikan status pengumpulan dan analisis.
+ **Akses API** — Ini harus dapat menyediakan sarana terprogram untuk mengakses data yang dikumpulkan.
*Fitur tambahan untuk dipertimbangkan*
+ **Analisis TCO** untuk memberikan perbandingan biaya antara biaya lokal saat ini dan biaya yang diproyeksikan AWS .
+ **Analisis lisensi dan rekomendasi pengoptimalan** untuk Microsoft SQL Server dan sistem Oracle dalam skenario rehost dan replatform.
+ **Rekomendasi strategi migrasi** (Dapatkah alat penemuan membuat rekomendasi tipe R migrasi default berdasarkan teknologi saat ini?)
+ **Ekspor inventaris** (ke CSV atau format serupa)
+ **Rekomendasi ukuran kanan** (misalnya, dapatkah itu memetakan AWS infrastruktur target yang direkomendasikan?)
+ **Visualisasi ketergantungan** (misalnya, dapatkah pemetaan ketergantungan divisualisasikan dalam mode grafis?)
+ **Tampilan arsitektur** (misalnya, dapatkah diagram arsitektur diproduksi secara otomatis?)
+ **Prioritas aplikasi** (Dapatkah itu menetapkan bobot atau relevansi dengan atribut aplikasi dan infrastruktur untuk membuat kriteria prioritas untuk migrasi?)
+ **Perencanaan gelombang** (misalnya, kelompok aplikasi yang direkomendasikan dan kemampuan untuk membuat rencana gelombang migrasi)
+ **Estimasi biaya migrasi** (estimasi upaya migrasi)
*Pertimbangan penyebaran*
Setelah Anda memilih dan mendapatkan alat penemuan, pertimbangkan pertanyaan berikut untuk mendorong percakapan dengan tim yang bertanggung jawab untuk menerapkan alat di organisasi Anda:
+ Apakah server atau aplikasi dioperasikan oleh pihak ketiga? Ini bisa mendikte tim untuk melibatkan dan proses yang harus diikuti.
+ Apa proses tingkat tinggi untuk mendapatkan persetujuan untuk menyebarkan alat penemuan?
+ Apa proses otentikasi utama untuk mengakses sistem seperti server, kontainer, penyimpanan, dan database? Apakah kredensyal server lokal atau terpusat? Bagaimana proses untuk mendapatkan kredensyal? Kredensil akan diperlukan untuk mengumpulkan data dari sistem Anda (misalnya, kontainer, server virtual atau fisik, hypervisor, dan database). Memperoleh kredensi untuk alat penemuan untuk terhubung ke setiap aset dapat menjadi tantangan, terutama ketika aset ini tidak terpusat.
+ Apa garis besar zona keamanan jaringan? Apakah diagram jaringan tersedia?
+ Bagaimana proses untuk meminta aturan firewall di pusat data?
+ Apa perjanjian tingkat layanan dukungan saat ini (SLAs) dalam kaitannya dengan operasi pusat data (instalasi alat penemuan, permintaan firewall)?
# Penggerak bisnis dan prinsip panduan teknis
## Pengemudi bisnis
Apakah organisasi Anda telah memutuskan untuk pindah ke cloud atau mendekati keputusan itu, mendefinisikan dan mendokumentasikan driver bisnis untuk migrasi cloud akan mengklarifikasi alasan migrasi. Setelah alasan didokumentasikan, Anda dapat menentukan apa yang akan dimigrasikan dan bagaimana hal itu akan dimigrasikan. Kegiatan ini penting. Kami menyarankan agar dilakukan sedini mungkin dalam proses untuk menginformasikan dan memandu langkah selanjutnya.
Identifikasi pemangku kepentingan yang harus menjadi bagian dari diskusi untuk mendokumentasikan driver. Biasanya CxOs, manajer senior, dan pemimpin teknologi kunci dalam organisasi, dan pelanggan Anda sendiri. Meskipun pelanggan Anda tidak mungkin menjadi bagian dari diskusi ini, kami menyarankan agar satu atau lebih orang di organisasi Anda ditunjuk mewakili pandangan dan tujuan pelanggan Anda.
Penggerak bisnis harus dikaitkan dengan metrik yang dapat diukur sepanjang perjalanan migrasi untuk memvalidasi apakah hasil telah tercapai. Sasaran strategis dan laporan tahunan perusahaan dapat bertindak sebagai titik awal.
Fokuskan percakapan di mana perusahaan ingin berada, berdasarkan metrik yang ada dan yang diproyeksikan, sebagai hasil dari pindah ke cloud. Pertimbangkan tujuan dan hasil bisnis. Juga, pertimbangkan seperti apa kesuksesan saat adopsi cloud meningkat.
Selanjutnya, tetapkan tingkat kepentingan untuk setiap pengemudi. Apa prioritasnya? Apa manfaat yang diharapkan? Bagaimana manfaat mendukung tujuan dan hasil bisnis? Dalam konteks penilaian portofolio aplikasi, jawabannya akan membantu memprioritaskan beban kerja untuk migrasi dan menetapkan prinsip panduan teknis. Namun, driver bisnis akan menentukan dan berdampak pada program migrasi secara keseluruhan.
## Prinsip panduan teknis
Prinsip panduan teknis menginformasikan pemilihan strategi migrasi pada tahap selanjutnya dari penilaian portofolio. Pada tahap saat ini, fokusnya adalah mengidentifikasi mereka.
Prinsip-prinsip panduan dapat ditetapkan sebagai keputusan terkait teknologi umum dan terkait pendekatan yang berasal dari tujuan dan hasil bisnis.
Misalnya, perusahaan memiliki tujuan utama untuk mengurangi biaya, dan hasil yang diinginkan adalah menutup pusat data lokal pada tanggal tertentu dalam 6-12 bulan. Prinsip panduan yang dihasilkan adalah mengangkat dan memindahkan semua aplikasi ke cloud dengan menggunakan rehost atau relokasi strategi migrasi bila memungkinkan. Dalam hal ini, lift-and-shift pendekatan mempercepat hasil migrasi jangka pendek. Setelah aplikasi pindah dari pusat data lokal, perusahaan dapat fokus pada driver bisnis utama untuk mengoptimalkan atau memodernisasi beban kerja yang dimigrasi.
Untuk menetapkan prinsip-prinsip panduan teknis, mulailah dengan menganalisis driver bisnis. Identifikasi daftar teknologi dan teknik yang akan mencapai tujuan dan hasil bisnis. Selanjutnya, perbaiki daftar dan tetapkan urutan relevansi berdasarkan kesesuaian atau preferensi untuk mencapai hasil yang diinginkan.
Mendokumentasikan dan mengkomunikasikan prinsip-prinsip panduan dengan orang-orang yang terlibat dalam perencanaan dan pelaksanaan migrasi. Sorot kekhawatiran dan potensi konflik antara prinsip dan implementasi aktual.
Tabel berikut memberikan contoh driver bisnis dan prinsip-prinsip panduan teknis.
| **Pengemudi bisnis** | **Hasil** | **Metrik-metrik** | **Prinsip panduan teknis** |
| --- |--- |--- |--- |
| Mempercepat inovasi. | Peningkatan daya saing, peningkatan kelincahan bisnis | Jumlah penyebaran per hari atau bulan, fitur baru yang dirilis per kuartal, skor kepuasan pelanggan, jumlah eksperimen | Memfaktorkan ulang aplikasi yang membedakan dengan menggunakan layanan mikro dan model DevOps operasi untuk meningkatkan kelincahan dan kecepatan ke pasar fitur baru. |
| Mengurangi biaya operasional dan infrastruktur. | Penawaran dan permintaan sesuai, basis biaya elastis (bayar untuk apa yang Anda gunakan) | Variasi pengeluaran dari waktu ke waktu | 1. Rehost aplikasi dengan ukuran tepat infrastruktur. 2. Pensiun aplikasi yang memiliki pemanfaatan rendah atau tidak ada. |
| Meningkatkan ketahanan operasional. | Uptime yang ditingkatkan, mengurangi waktu rata-rata untuk pemulihan | SLAs, jumlah insiden | 1. Replatform aplikasi ke versi sistem operasi terbaru dan didukung terbaik. 2. Menerapkan arsitektur ketersediaan tinggi untuk aplikasi penting. |
| Keluar dari pusat data. | Penutupan pusat data pada tanggal dalam 6-12 bulan | Kecepatan migrasi server | Rehost aplikasi dengan menggunakan Cloud Migration Factory Solution. |
| Tetap di tempat, tetapi tingkatkan kelincahan dan ketahanan. | Peningkatan daya saing dan uptime sambil tetap berada di tempat | Jumlah penyebaran per hari atau bulan, rilis fitur baru per kuartal, SLAs, jumlah insiden | 1. Modernisasi sistem dengan memperluas fungsionalitasnya ke cloud.2. Nilai untuk rehosting atau replatforming ke. AWS Outposts |
# Memulai pengumpulan data
Pengumpulan data adalah proses pengumpulan metadata dari aplikasi dan infrastruktur. Prosesnya berulang di semua tahap penilaian. Di setiap tahap, kuantitas dan kesetiaan data akan meningkat. Pada tahap ini, fokusnya adalah mengumpulkan data umum yang dapat membantu membangun inventaris awal. Inventaris akan digunakan untuk membuat kasus bisnis terarah dan identifikasi kandidat migrasi awal.
Setelah sumber data saat ini diidentifikasi, kami sarankan untuk mengumpulkan informasi dari sebanyak mungkin sistem. Untuk informasi selengkapnya, lihat [persyaratan data](understanding-initial-assessment-data-requirements.md) untuk tahap ini.
Pendekatan ini memiliki manfaat membantu memperbarui tampilan portofolio saat ini dan pengetahuan organisasi tentang aplikasi dan layanan mereka. Ini juga membantu menentukan apa yang ditargetkan untuk dipindahkan. Pendekatan yang disarankan adalah meninjau data yang ada, seperti output database manajemen konfigurasi (CMDB) dan sistem manajemen layanan teknologi informasi (ITSM). Kemudian buat daftar aset yang ditargetkan untuk pengumpulan data. Jika organisasi Anda memiliki kejelasan lengkap tentang apa yang ada di ruang lingkup dan di luar cakupan migrasi, Anda dapat membatasi pengumpulan data ke sistem yang berada dalam cakupan.
Saat membangun portofolio Anda, pertimbangkan aplikasi dan lingkungannya atau siklus hidup rilis perangkat lunak. Misalnya, alih-alih mengidentifikasi aplikasi manajemen hubungan pelanggan (CRM) dan menentukan bahwa ia memiliki lingkungan pengujian, pengembang, dan prod, daftarkan tiga aplikasi (misalnya, CRM-test, CRM-dev, CRM-prod). Atau, gunakan nama CRM tetapi tetapkan ID unik untuk setiap lingkungan dan sajikan sebagai catatan terpisah di repositori data Anda. Ini akan membantu merencanakan dan melacak migrasi lingkungan ini secara individual. Misalnya, Anda mungkin ingin memigrasikan lingkungan non-produksi terlebih dahulu. Dengan mencantumkan contoh aplikasi Anda sesuai dengan lingkungan, Anda dapat dengan jelas mengelola dan mengatur transisi mereka.
Selama pengumpulan data, mungkin ada ketidakpastian tentang aplikasi atau server mana yang berada di pusat data atau lokasi sumber tertentu. Dalam kasus ini, mendapatkan daftar bare-metal dan hypervisor dari alat manajemen yang ada sangat membantu. Misalnya, Anda dapat terhubung ke hypervisor untuk mendapatkan daftar mesin virtual yang akan ditargetkan untuk pengumpulan data.
Perhatikan bahwa output awal, saat menggabungkan sumber data yang ada, bisa jadi tidak lengkap. Kuncinya adalah melakukan analisis kesenjangan dalam hal [persyaratan data](understanding-initial-assessment-data-requirements.md) untuk tahap ini dan apa yang dapat diperoleh dari sumber yang ada. Penting untuk membedakan persentase kelengkapan dengan tingkat kesetiaan data. Tingkat kelengkapan yang lebih tinggi dari sumber kesetiaan rendah akan berisi beberapa asumsi yang dapat mengarah pada analisis yang salah. Meskipun tahap penilaian ini tidak memerlukan kesetiaan data maksimum, kami merekomendasikan bahwa sumber data setidaknya memiliki kesetiaan sedang hingga menengah-tinggi. Bandingkan angka-angka ini dengan toleransi organisasi Anda terhadap risiko, termasuk penggunaan asumsi untuk mengisi kesenjangan data.
Analisis kesenjangan membantu Anda memahami kuantitas dan kualitas data yang Anda kerjakan. Analisis ini juga membantu Anda menetapkan tingkat asumsi yang harus dibuat untuk membuat kasus bisnis terarah dan memprioritaskan aplikasi untuk migrasi. Alat penemuan dapat membantu mengisi celah dan mengumpulkan data dengan kesetiaan tinggi. Untuk meningkatkan tingkat kepercayaan pada data dan mempercepat hasil migrasi, sebaiknya gunakan alat penemuan sedini mungkin. Tindakan awal juga penting karena proses pengadaan, keamanan, dan implementasi internal untuk alat baru dapat memerlukan beberapa minggu atau bulan untuk menyelesaikannya.
Kami merekomendasikan untuk membuat rencana komunikasi atau irama dan mekanisme kontrol perubahan ruang lingkup pada tahap ini. Ini membantu Anda untuk terus memberi tahu para pemangku kepentingan sehingga mereka dapat merencanakan ke depan dan mengurangi risiko. Elemen kunci untuk komunikasi yang jelas adalah mendefinisikan satu sumber kebenaran untuk portofolio aplikasi dan infrastruktur terkait. Hindari menyimpan beberapa sistem catatan dan daftar aplikasi dan infrastruktur. Simpan data di satu tempat (misalnya, database, alat, atau spreadsheet) yang mendukung pembuatan versi dan kolaborasi online, dan tetapkan pemiliknya.
# Prioritisasi dan Strategi 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 yang siap dihosting ulang 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](initiating-data-collection.md)).
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** |
| --- |--- |--- |--- |
| Lingkungan | 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](prioritized-applications-assessment.md).
## 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.
![\[Proses keputusan 6 R dibahas dalam panduan ini.\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/application-portfolio-assessment-guide/images/6Rs-DecisionTree-baseModel.png)
*[Versi [draw.io](https://github.com/jgraph/drawio-desktop/releases) yang dapat disesuaikan dari diagram ini tersedia di bagian Lampiran.](#attachments)*
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](portfolio-analysis-migration-planning.md).
## Lampiran
[attachment.zip](samples/attachment.zip)
# Membuat kasus bisnis terarah
Pemangku kepentingan dari seluruh bisnis harus memahami dan membeli ke dalam kasus bisnis untuk transformasi setiap langkah di sepanjang jalan.
Pada tahap awal, penting untuk dengan cepat menunjukkan nilai potensial yang cukup dari program migrasi, sehingga Anda dapat mengamankan sumber daya yang dibutuhkan untuk merencanakan dan membuat program. Kasus bisnis terarah dirancang untuk memberikan kepercayaan yang masuk akal dalam mencapai nilai bisnis yang menarik dengan data terbatas yang dapat dikumpulkan lebih awal.
Setelah program ditetapkan, kasus bisnis dikembangkan lebih lanjut. Kasus terperinci memberikan akurasi yang lebih besar, gambaran yang lebih lengkap tentang nilai program, dan wawasan tentang prioritas perencanaan. Ini mendefinisikan dan mengukur hasil bisnis yang direncanakan yang dibeli organisasi, dan menetapkan dasar di mana kantor tata kelola program Anda kemudian dapat mengarahkan program dan mengukur pencapaiannya.
## Memperbaiki ruang lingkup kasus bisnis terarah
Kasus bisnis terarah biasanya dirakit dengan cepat, dalam waktu 2-4 minggu. Ini perlu menghasilkan kepercayaan diri yang cukup sehingga Anda dapat mengamankan sumber daya untuk membentuk tim inti, melibatkan AWS Mitra jika diperlukan, dan seminimal mungkin, menyelesaikan [penilaian aplikasi yang diprioritaskan](prioritized-applications-assessment.md) dan [analisis portofolio dan tahap perencanaan migrasi](portfolio-analysis-migration-planning.md).
Biasanya, kasus bisnis terarah yang mendukung migrasi portofolio dibuat sebagai salah satu dari berikut ini:
+ ****Perbandingan *biaya kepemilikan total (TCO)* sederhana antara lanskap infrastruktur apa adanya dan arsitektur Layanan AWS pasca-migrasi. Perbandingan menunjukkan perbedaan laju lari yang diharapkan untuk volume beban kerja tertentu.
+ Kasus bisnis**** yang menunjukkan nilai sekarang bersih (NPV), laba atas investasi (ROI), periode pengembalian modal, tingkat pengembalian internal yang dimodifikasi (MIRR) dan analisis arus kas 3-5 tahun untuk bermigrasi ke inklusif biaya migrasi vs tetap apa adanya. AWS
Lingkup kasus bisnis terarah biasanya terbatas pada salah satu dari berikut ini:
+ Perbandingan biaya teknologi infrastruktur
+ Perbandingan teknologi infrastruktur dan biaya operasi
Secara umum, semakin besar portofolio, semakin kurang berkembang kasusnya. Ini karena asumsi yang lebih luas dapat dibuat tanpa mempengaruhi hasilnya secara signifikan. Untuk portofolio yang lebih kecil, setiap perubahan akan memiliki dampak yang lebih besar, sehingga diperlukan lebih banyak detail.
Mulailah dengan membangun perbandingan biaya infrastruktur dasar. Kemudian putuskan apakah perbandingannya cukup menarik sebelum Anda melanjutkan. Biasanya, portofolio lebih dari 400 server akan menunjukkan kasus bisnis yang positif pada pengurangan biaya infrastruktur saja dalam waktu 3 tahun beroperasi AWS, atau 250 server dalam waktu 5 tahun, meskipun ini dapat bervariasi. Untuk portofolio yang lebih kecil, detail lebih lanjut mungkin diperlukan.
Sebaliknya, jarang berguna untuk memeriksa komponen nilai bisnis lainnya pada tahap ini, seperti nilai yang berasal dari peningkatan ketahanan atau kelincahan bisnis, kecuali total ruang lingkup migrasi kurang dari sekitar 5 beban kerja atau 50 server.
## Driver nilai fokus
Perbandingan TCO teknologi infrastruktur membandingkan model biaya infrastruktur apa adanya dengan model dasar Layanan AWS tagihan bahan yang dibutuhkan untuk menjalankan beban kerja Anda dengan kinerja dan ketersediaan yang setara. Banyak optimasi dapat dilakukan. Pada tahap ini, bagaimanapun, fokusnya adalah pada daftar berikut karena mereka lebih mudah untuk menilai dan biasanya menghasilkan sekitar 30 persen penghematan TCO, yang cukup untuk bergerak maju:
+ **Compute elastisitas** — Server peta yang penggunaannya tidak 100 persen, seperti server pengembangan atau UAT yang menjalankan 8x5 (penggunaan 24 persen), 10x5 (30 persen), atau 10x6 (36 persen), dan server pemulihan bencana (DR) yang berjalan pada 2 persen, untuk layanan sesuai permintaan yang hanya ditagih saat digunakan.
+ **Pengadaan dengan rencana penghematan** - Rencanakan untuk mendapatkan server produksi dan server lain dengan penggunaan tinggi (lebih dari 36 persen) dengan rencana penghematan yang sesuai untuk mengurangi biaya hingga 75 persen. Opsi termasuk komitmen 1 tahun dan 3 tahun, dengan tingkat pembayaran di muka yang berbeda untuk mendapatkan diskon yang lebih besar.
+ **Hapus zombie** — Identifikasi server dengan pemanfaatan CPU kurang dari 2 persen yang dapat Anda konfirmasi tidak lagi diperlukan, dan hapus dari analisis biaya.
+ **Hitung ukuran kanan** — Gunakan data deret waktu pemanfaatan CPU dan memori untuk menilai setiap server daya komputasi dan memori yang dibutuhkan. Kemudian pilih instans Amazon Elastic Compute Cloud (Amazon EC2) agar sesuai.
+ **Sistem manajemen basis data relasional (RDBMS) lisensi ukuran kanan - Menilai kembali kebutuhan lisensi RDBMS Anda setelah menghitung ukuran** kanan pada server database Anda, bandingkan Bring Your Own License (BYOL) dan lisensi Pengadaan dari, dan jelajahi AWS potensi Amazon Relational Database Service (Amazon RDS) untuk meningkatkan penghematan.
+ **Penyimpanan** — Ukuran yang tepat total volume penyimpanan yang dibutuhkan, dan identifikasi kebutuhan input/output operasi per detik (IOPS) di seluruh portofolio. Tentukan berapa banyak yang dapat dipindahkan ke penyimpanan objek dengan biaya SLAs dan berbeda.
## Kebutuhan data
Tabel dalam [Memahami persyaratan data penilaian awal](understanding-initial-assessment-data-requirements.md) menunjukkan data yang diperlukan untuk membangun setiap bagian dari kasus bisnis terarah, dan apakah itu wajib atau opsional.
Untuk membangun kasus ini, Anda memerlukan subset infrastruktur dari data perencanaan awal ditambah data biaya. Menentukan cara mengidentifikasi infrastruktur yang akan disertakan tergantung pada tujuan bisnis Anda:
+ Jika tujuan program adalah untuk memigrasi dan memodernisasi aplikasi tertentu, bangun portofolio infrastruktur berdasarkan apa yang dibutuhkan aplikasi, dengan mempertimbangkan infrastruktur yang dibagikan.
+ Jika tujuan program adalah infrastruktur-sentris, seperti migrasi keluar dari pusat data yang sewanya akan kedaluwarsa, pemetaan aplikasi tidak diperlukan untuk perbandingan TCO infrastruktur.
Data yang ditandai sebagai opsional (seperti CPU dan pemanfaatan puncak memori untuk server) biasanya dapat diganti dengan nilai benchmark standar. Anda dapat mendiskusikan hal ini dengan AWS Mitra atau Layanan AWS Profesional. Atau Anda dapat mengekstrapolasi nilai dari titik data yang tersedia di bagian portofolio Anda (seperti data yang dikumpulkan oleh hypervisor). Semakin besar portofolio, semakin akurat ini.
## Membangun infrastruktur perbandingan TCO
Alat sangat penting untuk membangun perbandingan TCO infrastruktur. [AWS Layanan Profesional](https://aws.amazon.com/professional-services/) atau [AWS Mitra](https://aws.amazon.com/migration/partner-solutions/) dapat memberikan bantuan dengan semua jenis kasus terarah, terutama jika Anda berencana untuk melibatkan mereka untuk membantu dalam proses migrasi yang lebih luas.
Ada alat yang tersedia untuk melakukan hal berikut:
+ Kumpulkan data inventaris.
+ Kumpulkan data pemanfaatan.
+ Menyediakan data benchmarking biaya infrastruktur yang akurat.
+ Identifikasi dan hapus zombie.
+ Buat penilaian ukuran yang tepat.
+ Merekomendasikan opsi pembelian.
+ Bandingkan opsi lisensi perangkat lunak.
+ Menghasilkan analisis arus kas grafis sederhana.
[Migration Evaluator](https://aws.amazon.com/migration-evaluator/) dari AWS adalah salah satu pilihan. Ini menyediakan semua kemampuan ini sebagai **layanan terkelola gratis. Anda** [dapat meminta Penilai Migrasi melalui manajer AWS akun atau Mitra Kompetensi AWS Migrasi atau dengan mengirimkan permintaan secara online.](https://pages.awscloud.com/Migration-Evaluator-request.html) Migration Evaluator telah dirancang khusus sebagai solusi titik untuk menghasilkan perbandingan TCO teknologi infrastruktur dan cepat.
Keuntungan utama:
+ Bebas biaya
+ Penemuan tanpa agen atau konfigurasi manual data inventaris di mana penemuan berbasis alat dibatasi
+ Dukungan khusus untuk membantu penyebaran, konfigurasi, pengumpulan data, dan membangun kasus dasar, atau kasus bisnis terarah
+ Kenyamanan operasi SaaS, tetapi dapat menjalankan pengumpulan data sepenuhnya dalam jaringan pelanggan untuk mendukung scrubbing sebelum memuat ke mesin analitik
+ Dukungan kuat untuk ukuran kanan lisensi Microsoft
+ Kemampuan ekspor data lengkap
Keterbatasan utama:
+ Menilai hanya server arsitektur x86 (Windows dan Linux)
+ Opsi terbatas untuk mengonfigurasi atau mengkalibrasi data biaya apa adanya benchmark
+ Tidak ada dukungan untuk pengoptimalan biaya operasi pemodelan
+ Tidak ada dukungan untuk pemodelan biaya migrasi
+ Tidak ada dukungan langsung untuk membangun kasus bisnis di luar perbandingan TCO
Jika Anda memutuskan untuk menggunakan alat penemuan komersial untuk penemuan portofolio dan kemampuan analisis seperti tumpukan aplikasi dan penemuan interdependensi, biasanya akan memberikan perbandingan TCO infrastruktur juga. Untuk panduan tentang penggunaan alat untuk penemuan dan penilaian portofolio, lihat [Mengevaluasi kebutuhan alat penemuan](understanding-initial-assessment-data-requirements.md#discovery-tooling). Untuk meninjau dan membandingkan kemampuan utama alat terdepan di pasar, lihat Alat [migrasi Discovery, Planning, dan Rekomendasi](https://aws.amazon.com/prescriptive-guidance/migration-tools/migration-discovery-tools/).
## Membangun optimalisasi biaya operasional
Peningkatan produktivitas operasi TI seringkali merupakan kontributor nilai yang signifikan untuk migrasi. Rata-rata, setelah migrasi ke AWS, produktivitas staf operasional TI meningkat sebesar 62 persen melalui migrasi, menurut whitepaper International Data Corporation (IDC) [Fostering Business and Organizational Transformation to Generate Business Value with Amazon Web Services](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770). Namun, ada dua tantangan dengan ukuran dan termasuk manfaat ini dalam kasus terarah.
Pertama, menilai berbagai keuntungan produktivitas membutuhkan pengumpulan data yang ekstensif dan lebih tepat untuk [kasus bisnis yang terperinci](detailed-business-case.md). Tantangan ini dapat diatasi dengan berfokus pada beberapa elemen yang lebih mudah dinilai dan diukur dengan data benchmark sederhana tetapi masih menunjukkan keuntungan yang signifikan.
Kedua, berfokus pada produktivitas sebagai sumber pengurangan biaya dapat menimbulkan kekhawatiran dan negativitas di antara pemangku kepentingan pelanggan utama dan anggota program. Pastikan bahwa Anda memberikan kejelasan tentang bagaimana manfaat akan direalisasikan dan apa artinya bagi orang-orang yang terkena dampak. Masalah seperti itu dapat dihindari dengan mengklarifikasi bahwa ini hanya akan meningkatkan peran tim:
+ Program migrasi mencakup jalur untuk mengembangkan dan memindahkan staf operasi internal ke peran baru, seperti bergabung dengan DevSecOps tim yang membangun infrastruktur sebagai otomatisasi kode dan otomatisasi pengujian yang akan mendorong pertumbuhan tim.
+ Manfaat dapat direalisasikan dengan mengubah dan mengubah ukuran kontrak outsourcing operasi, sehingga staf internal dapat meningkatkan fokus mereka pada kegiatan yang bernilai lebih tinggi
Pendekatan membangun elemen kasus bisnis ini berdasarkan transformasi operasi apa yang ingin Anda pertimbangkan:
+ Jika Anda memiliki tim operasi internal yang ada, tingkatkan keterampilan anggota tim, dan tunjukkan peningkatan produktivitas yang diharapkan.
+ Atau, bermigrasi dari solusi operasi Anda saat ini ke AWS Managed Services (AMS) atau ke penawaran layanan terkelola alternatif dari AWS Mitra.
Untuk transformasi pertama, untuk mendapatkan perkiraan keuangan konservatif dari peningkatan produktivitas yang dapat dimasukkan dalam kasus ini, kami merekomendasikan yang berikut:
1. Fokus pada produktivitas operasi manajemen server secara khusus. Ini cenderung menjadi proporsi yang signifikan dari upaya operasi, dapat lebih mudah dinilai, dan lebih mudah diverifikasi nanti.
1. Hitung kepegawaian yang dibutuhkan berdasarkan tolok ukur jumlah server yang dapat dikelola oleh setiap karyawan full-time equivalent (FTE). Di tempat, jumlah itu sekitar 150 severs. Pada AWS, itu sekitar 400 server.
1. Terapkan metrik ini ke jumlah server lokal dibandingkan dengan jumlah instans EC2.
1. Lipat gandakan waktu yang dihemat dengan tingkat biaya campuran untuk seluruh tim operasi.
Anda kemudian dapat memeriksa hasil Anda dengan salah satu pendekatan dengan memverifikasi hasilnya tidak jauh melebihi perolehan produktivitas rata-rata berdasarkan peran yang disediakan dalam tabel berikut (data yang bersumber dari whitepaper IDC [Mendorong Bisnis dan Transformasi Organisasi untuk Menghasilkan Nilai Bisnis dengan Amazon Web Services](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770).
| **Peran** | **Keuntungan efisiensi** |
| --- |--- |
| Manajemen infrastruktur TI | 62% |
| Dukungan TI | 59% |
| Manajemen aplikasi | 43% |
| Manajemen basis data | 19% |
| Pengembangan aplikasi | 25% |
Untuk transformasi kedua, Anda dapat menambahkan penghematan biaya operasional dengan langsung membandingkan total operasi saat ini dan biaya dukungan untuk portofolio dalam ruang lingkup dengan biaya layanan terkelola yang dipertimbangkan.
Untuk mendapatkan biaya layanan terkelola, berikan kepada manajer AWS akun atau [AWS Managed Services Mitra](https://aws.amazon.com/managed-services/partners/) Anda dengan AWS Bill of Material yang Anda usulkan, pilihan tingkat layanan Anda (Plus atau Premium), dan paket AMS Anda (AMS Accelerate atau AMS Advanced). Ini akan memberi Anda total biaya layanan terkelola untuk:Layanan AWS komponen solusi yang ditransformasikan. Demikian pula, Anda dapat memperoleh harga dari AWS Mitra yang menawarkan paket layanan terkelola sendiri berdasarkan parameternya sendiri.
## Memperluas ke kasus bisnis terarah penuh
Secara umum, untuk merakit kasus bisnis terarah penuh, membangun perbandingan TCO, dengan atau tanpa elemen produktivitas TI, dan perkirakan semua biaya migrasi dan modernisasi. Kemudian buat arus kas yang mencakup pasangan t-migrate-and-modernize skenario migrate-and-modernize dan jangan.
Kasus yang paling mendasar adalah persiapan sepasang skenario, di mana t-migrate-and-modernize skenario jangan adalah situasi Anda saat ini dan migrate-and-modernize skenario memiliki karakteristik sebagai berikut:
+ Tidak ada pertumbuhan atau penyusutan volume transaksional, komputasi, atau kapasitas jaringan
+ Pertumbuhan volume rendah yang stabil dalam persyaratan penyimpanan
+ Quality-of-service kemampuan (seperti ketersediaan, daya tahan, throughput, dan kinerja) yang sesuai dengan kemampuan sistem yang ada
Untuk semua kecuali portofolio yang sangat kecil, ini sesuai dengan tujuan membangun kasus terarah dengan baik. Ini menunjukkan nilai yang cukup cepat untuk mendapatkan mandat untuk bergerak maju.
Untuk portofolio yang lebih kecil, akan bermanfaat untuk menambahkan pasangan t-migrate-and-modernize skenario migrate-and-modernize dan jangan yang menunjukkan aspek lain dari peningkatan nilai migrasi cloud, seperti:
+ Campuran persyaratan pertumbuhan kapasitas sedang dan tinggi di seluruh beban kerja di mana pertumbuhan itu diharapkan
+ Dimasukkannya ketahanan yang ditingkatkan, seperti ketersediaan tinggi, DR, dan toleransi kesalahan
+ Peningkatan kinerja global dengan komputasi tepi, jaringan pengiriman konten (CDN), replikasi database multi-wilayah.
+ Kualitas layanan spesifik lainnya yang telah Anda jadikan prioritas bisnis untuk program ini
Untuk skenario ini, pastikan bahwa biaya dan implikasi arus kas dari peningkatan arsitektur infrastruktur non-cloud saat ini agar sesuai dengan spesifikasi baru diperkirakan secara akurat. Cara paling langsung untuk mendapatkan perkiraan ini dapat meminta kutipan dari integrator sistem, terutama jika mereka juga merupakan Mitra AWS Konsultasi dengan Kompetensi Migrasi, yang dapat mendukung Anda dengan skenario migrate-and-modernize dan tidak. t-migrate-and-modernize
Untuk setiap pasangan skenario, kumpulkan kasus yang terdiri dari hal-hal berikut:
+ Biaya t-migrate-and-modernize skenario don'. Dalam kasus yang paling mendasar, ini termasuk:
+ Total biaya kepemilikan selama jangka waktu kasus bisnis untuk konfigurasi infrastruktur saat ini
+ Peningkatan berkala dalam komputasi, penyimpanan, dan konsumsi lalu lintas jaringan
+ Biaya skenario migrate-and-modernize;, termasuk:
+ Menyiapkan program, yang mencakup penemuan terperinci, perencanaan migrasi, pengembangan kasus bisnis terperinci, pembentukan tim inti dan peningkatan keterampilan mereka, membangun landing zone jika belum ada, dan membangun manajemen keamanan dan integrasi operasi untuk beban kerja yang bermigrasi
+ Biaya migrasi dan modernisasi beban kerja
+ Biaya infrastruktur migrasi, termasuk koneksi jaringan, layanan migrasi data seperti [AWS Snowball Edge](https://aws.amazon.com/snowball/)dan [AWS DataSync](https://aws.amazon.com/datasync/), dan biaya AWS utilitas untuk arsitektur yang diperlukan selama proses migrasi itu sendiri (misalnya, untuk pengujian)
+ Peningkatan biaya AWS utilitas selama migrasi saat gelombang ditayangkan, dan menurunnya biaya infrastruktur yang ada karena digantikan oleh layanan AWS berbasis dan dinonaktifkan
+ Biaya penonaktifan dan penghapusan untuk setiap aset yang terdampar
## Memperkirakan pengaturan program migrasi dan modernisasi
Untuk menyiapkan program untuk sukses, Anda mungkin perlu menjalankan serangkaian kegiatan dasar untuk membangun kemampuan dasar dan rencana terperinci jika ini belum dilakukan sebelumnya. Kegiatan dasar ini meliputi:
1. Melakukan penemuan portofolio terperinci, perencanaan migrasi, dan pengembangan kasus bisnis terperinci, seperti yang dijelaskan di bagian [Analisis portofolio dan perencanaan migrasi](portfolio-analysis-migration-planning.md), ditambah pendokumentasian biaya alat penemuan apa pun yang digunakan.
1. Membangun bisnis cloud dan tim inti teknis dan mengembangkan keterampilan internal melalui pelatihan dan perekrutan. Identifikasi anggota organisasi TI yang membutuhkan pelatihan, dan alokasikan anggaran pelatihan untuk setiap orang.
1. Menetapkan [landing zone](https://aws.amazon.com/solutions/implementations/aws-landing-zone/) dan mengonfigurasinya untuk mendukung kemampuan tata kelola biaya, operasional, dan keamanan yang Anda perlukan.
AWS Mitra Konsultasi dapat membantu memberikan perkiraan untuk item 1 dan 3.
*Memperkirakan biaya migrasi dan modernisasi*
Untuk memenuhi tujuan kasus bisnis terarah dan menunjukkan potensi komersial yang *cukup* untuk melanjutkan ke fase berikutnya, pertahankan estimasi biaya migrasi dan modernisasi sedasar mungkin.
Untuk tujuan ini, kami menyarankan Anda menyiapkan kasus bisnis terarah dengan berfokus pada aplikasi yang termasuk dalam strategi migrasi berikut:
+ Pensiun
+ Mempertahankan
+ Pindah
+ Rehost
+ Platform Ulang
+ Pembelian kembali
Biasanya, sekitar 70 persen beban kerja dapat direhost, dipindahkan atau direplatform, dan 5 persen lainnya dapat dihentikan. Menilai aplikasi dengan strategi migrasi biasanya membahas inti dari kasus pengurangan biaya.
**Memperkirakan biaya untuk refactoring, atau re-architecting, bisa jadi rumit.** Hal ini tidak praktis untuk mencoba ini dalam jangka waktu yang diberikan untuk mempersiapkan kasus bisnis terarah. Seperti yang dibahas sebelumnya dalam [Menentukan tipe R untuk migrasi](prioritization-and-migration-strategy.md#migration-r-type), pertimbangkan untuk menggunakan strategi rehost, relokasi, atau replatform untuk fase pertama migrasi dan modernisasi Anda. Strategi R ini kemungkinan akan mempercepat pengembalian awal, mengurangi risiko implementasi, dan meningkatkan kasus bisnis dalam jangka pendek. Hal ini juga secara material lebih mudah bagi tim aplikasi Anda untuk memodernisasi aplikasi yang berjalan dalam AWS lingkungan daripada yang tidak. Perkiraan untuk refactoring (re-architecting) aplikasi spesifik paling baik ditambahkan ketika kasus bisnis [terperinci](detailed-business-case.md) disiapkan.
*Memperkirakan upaya migrasi dengan strategi*
Setiap migrasi berbeda. Sebelum melakukan anggaran atau rencana apa pun, perkiraan beban kerja benih untuk aktivitas migrasi dari tim yang akan bertanggung jawab atas proyek, apakah itu tim aplikasi internal Anda, Layanan AWS Profesional, atau organisasi Mitra. AWS
Untuk membantu membangun kasus terarah, tabel berikut memberikan rentang upaya indikatif untuk perawatan yang berbeda. Rentang ini mengasumsikan bahwa medium-to-large portofolio sedang dimigrasikan dan tim migrasi dilatih dan berpengalaman. Untuk portofolio kecil, yang terbaik adalah meminta tim yang bertanggung jawab atas migrasi menyiapkan perkiraan bahkan untuk kasus terarah.
| Strategi migrasi | Proses estimasi | Elemen | Jam orang | Jam orang |
| --- |--- |--- |--- |--- |
| Mempertahankan | Jangan melakukan apa-apa, tanpa biaya, tanpa manfaat, dan tidak ada pengurangan hutang teknologi. | – | – | – |
| Pensiun | Perkirakan penonaktifan peralatan perangkat keras yang digunakan, jika ada. | – | – | – |
| Pindah | Perkirakan menyalin beban kerja dalam VMware menggunakan alat VMware . Ini termasuk menyalin data, pengujian asap untuk memverifikasi, dan penonaktifan perangkat keras apa pun. Upaya untuk pindah VMs biasanya kurang dari pola rehost dengan kompleksitas rendah. | – | – | – |
| Rehost | Perkirakan penyalinan beban kerja dan data dengan salinan gambar, pengujian asap, pengujian ketersediaan tinggi (HA) dan pemulihan bencana (DR) jika sesuai untuk server produksi, dan penonaktifan perangkat keras apa pun. Praktik terbaik adalah menggunakan alat-alat seperti [AWS Application Migration Service](https://aws.amazon.com/application-migration-service/). Bagilah beban kerja menjadi kompleksitas rendah, sedang, dan tinggi, berdasarkan faktor-faktor seperti apakah database atau perangkat lunak infrastruktur lainnya berjalan, kompleksitas basis data, apakah dikelompokkan, kompleksitas integrasi, dan volume data. | Upaya per aplikasi per server | Migrasi | Tes HA/DR |
| Rendah | 10—14 | 3—5 |
| Sedang | 16—24 | 4—6 |
| Tinggi | 26—38 | 8—12 |
| Platform Ulang | Untuk migrasi replatform yang mencakup peningkatan ke sistem operasi atau versi RDBMS, ambil perkiraan untuk rehost, dan tambahkan waktu untuk menjalankan uji pembangunan kembali dan asap pada platform baru. Jika replatform termasuk mengubah teknologi platform, perkirakan waktu tambahan untuk penggunaan alat konversi, seperti dan, dan pengujian aplikasi yang lebih lengkap. [AWS Schema Conversion Tool[AWS Database Migration Service](https://aws.amazon.com/dms/)](https://aws.amazon.com/dms/schema-conversion-tool/) Contoh perubahan teknologi adalah bermigrasi dari database komersial berpemilik ke pengganti open source. | Upaya per aplikasi per server | Versi naik | Perubahan teknologi |
| Rendah | Tambahkan 1-3 | Tambahkan 10—15 |
| Sedang | Tambahkan 2—5 | Tambahkan 20—30 |
| Tinggi | Tambahkan 4-8 | Tambahkan 40-60 |
| Pembelian kembali | Perkirakan ekstraksi data, transformasi, dan pengunggahan ke dalam penggantian layanan SaaS yang baru dibeli, dan penonaktifan perangkat keras apa pun. | – | – | – |
*Memperkirakan biaya infrastruktur migrasi*
Sertakan perkiraan untuk infrastruktur yang akan Anda gunakan selama migrasi. Biasanya, perkiraan ini terdiri dari:
+ Anggaran untuk konektivitas dan layanan pertukaran data untuk beban kerja dan migrasi data dari lingkungan saat ini AWS
+ Anggaran untuk Layanan AWS (terutama komputasi dan penyimpanan) yang diperlukan untuk menghosting beban kerja yang dimigrasi selama proses migrasi, pengujian, dan pemotongan
+ Peningkatan biaya AWS utilitas karena setiap gelombang migrasi selesai
+ Biaya penonaktifan infrastruktur yang ada yang tidak akan lagi menjalankan beban kerja yang dimigrasi
Untuk pertukaran data, periksa total volume data Anda dan nilai kelayakan menggunakan jaringan. Jika Anda telah menyediakan [AWS Direct Connect](https://aws.amazon.com/directconnect/)tautan atau [Site-to-Site VPN](https://aws.amazon.com/vpn/)dari AWS satu titik di WAN Anda sebelumnya untuk penggunaan operasional setelah migrasi, Anda dapat menggunakan sumber daya tersebut hingga kuota layanannya.
Jika kapasitas jaringan Anda tidak mencukupi, peningkatan bandwidth internet jangka pendek dengan jaringan pribadi virtual (VPN) seringkali merupakan solusi yang sangat hemat biaya. Jika tidak, perangkat pertukaran AWS media seperti [AWS Snowball Edge](https://aws.amazon.com/snowball/)dan [AWS Snowball Edge](https://aws.amazon.com/snowcone/)menawarkan solusi di sebagian besar Wilayah AWS. Juga, untuk migrasi data volume sangat tinggi, pertimbangkan untuk memasukkan anggaran untuk [AWS DataSync](https://aws.amazon.com/datasync/), yang meningkatkan keandalan dan dapat mempercepat transfer terlepas dari media yang digunakan.
Memodelkan peningkatan AWS layanan dan menuruni infrastruktur yang ada penting untuk elemen analisis arus kas dari kasus bisnis. Pada tahap ini, Anda tidak mungkin memiliki rencana gelombang untuk menentukan dengan tepat kapan biaya akan dikeluarkan. Sebaiknya lakukan hal berikut:
+ Meningkatkan biaya untuk AWS pada tingkat konstan selama migrasi.
+ Mengurangi biaya untuk infrastruktur yang ada yang Anda rencanakan untuk dinonaktifkan pada tingkat konstan selama durasi yang sama.
Memulai kenaikan AWS biaya 1-2 bulan sebelum infrastruktur yang ada turun. Ini menyediakan 1 bulan penggunaan AWS utilitas untuk melakukan migrasi untuk setiap gelombang. Ini termasuk waktu untuk pengujian, dan waktu tambahan untuk menyelesaikan pekerjaan penonaktifan yang diperlukan untuk menghentikan biaya pada infrastruktur yang diganti.
*Memperkirakan biaya penonaktifan*
Menonaktifkan peralatan yang tidak dapat dikerahkan kembali, dan membuangnya dengan cara yang legal dan ramah lingkungan, dapat menimbulkan biaya kecil. Namun, untuk kasus bisnis terarah, biasanya satu-satunya jumlah material yang berpotensi adalah biaya penghapusan nilai buku yang tersisa dari aset yang diganti.
Untuk kasus bisnis terarah, kami sarankan Anda melakukan hal berikut:
+ Tinjau daftar aset Anda.
+ Identifikasi mereka yang akan dinonaktifkan.
+ Untuk mengurangi penghapusan, periksa peluang untuk beralih perangkat sehingga perangkat yang lebih baru dalam daftar dapat digunakan untuk menggantikan aset yang lebih tua dan lebih terdepresiasi sepenuhnya.
+ Buat penilaian nilai buku future dari aset yang akan dinonaktifkan pada saat itu.
+ Sertakan ini sebagai biaya migrasi penonaktifan.
*Merakit dan menyesuaikan kasus bisnis terarah penuh*
Setelah Anda menyiapkan set lengkap biaya untuk setiap pasangan skenario, buatlah laporan arus kas diskon untuk masing-masing dan buat grafik. Kami merekomendasikan untuk membangun kasus bisnis terarah selama periode yang sama dengan siklus penyegaran perangkat keras. Ini biasanya 5 tahun untuk server, penyimpanan, dan perangkat jaringan. Saat Anda menggunakan periode yang sama dengan siklus penyegaran perangkat keras, biaya tepat satu penyegaran disertakan dalam biaya apa adanya untuk setiap skenario.
Kemudian hitung metrik keuangan utama yang Anda butuhkan untuk mendapatkan persetujuan untuk pindah ke fase berikutnya dari program. Kami biasanya menyertakan yang berikut:
+ Net present value (NPV) untuk mengukur nilai absolut dari pengurangan biaya dan keuntungan produktivitas yang dinilai
+ Periode pengembalian modal dalam beberapa bulan untuk memverifikasi bahwa pengembalian cukup cepat
+ Perbandingan run-rate akhir untuk memverifikasi apakah proses tersebut mengeluarkan biaya yang cukup selama jangka waktu tersebut
+ Pengembalian investasi (ROI) dan tingkat pengembalian investasi yang dimodifikasi (MIRR) untuk menilai kinerja keuangan relatif dari program di atas tuntutan modal lain yang mungkin diprioritaskan oleh organisasi Anda
Gunakan iterasi pertama dari kasus ini untuk menentukan apakah kinerja keuangan yang diharapkan berarti bahwa penyempurnaan harus dilakukan, seperti dalam contoh berikut:
+ Jika pengembalian terlalu lambat, pertimbangkan opsi untuk mempercepat dan mengurangi biaya migrasi, seperti berikut ini:
+ Gunakan AWS Mitra atau Layanan AWS Profesional untuk memperluas sumber daya yang tersedia dan selanjutnya memparalelkan beban kerja migrasi dengan pola yang lebih mendasar.
+ Untuk beban kerja yang berjalan VMware, bandingkan strategi relokasi dengan strategi rehost atau replatform, setidaknya untuk fase awal. Menggunakan strategi relokasi dapat mengurangi biaya migrasi dan meningkatkan kecepatan migrasi.
+ Jika secara teknis layak, dorong beban kerja yang membutuhkan strategi replatform atau refactor (re-architect) yang lebih kompleks ke fase future, di luar lingkup kasus bisnis awal.
+ Jika ROI dan MIRR terlalu rendah, pertimbangkan hal berikut:
+ Apakah skenario yang Anda anggap terlalu konservatif? Apakah Anda memiliki skenario yang mencerminkan pertumbuhan kapasitas dan kebutuhan elastisitas yang paling mungkin? Apakah Anda memiliki skenario yang membandingkan biaya termasuk peningkatan kualitas layanan dalam tujuan Anda?
+ Dapatkah Anda menyempurnakan cakupan portofolio aplikasi yang akan dimigrasikan pada tahap pertama untuk fokus pada beban kerja yang akan menghasilkan pengembalian yang lebih kuat, seperti yang memiliki pemanfaatan arus yang lebih rendah atau kebutuhan pemulihan bencana (DR) yang mahal?
+ Dapatkah menyempurnakan ruang lingkup portofolio aplikasi untuk awalnya mengecualikan beban kerja tertentu yang mencapai kurang komersial? Misalnya, dapatkah Anda menunda beban kerja yang lisensi perangkat lunak pihak ketiga menjadi lebih mahal karena persyaratan yang berbeda untuk penyebaran di infrastruktur cloud publik?
+ Jika perbandingan run-rate akhir tidak memenuhi target yang diharapkan, jelajahi hal berikut:
+ Pertama, konfirmasikan bahwa metrik lainnya memenuhi harapan. Kasus bisnis terarah terutama untuk menunjukkan bahwa ada peluang keuangan yang cukup untuk membenarkan memulai fase persiapan migrasi berikutnya.
+ Identifikasi daftar peluang untuk terus meningkatkan kinerja biaya AWS setelah fase awal migrasi.
Sertakan penilaian daftar peluang saat menyiapkan kasus bisnis terperinci. Selain itu, sertakan penilaian peluang dalam pemeliharaan kasus yang sedang berlangsung dan proses month-to-month pengoptimalan biaya setelah migrasi selesai.