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 penilaian ini berfokus pada penyelesaian penemuan dan analisis tingkat portofolio yang dimulai di bagian [penemuan Portofolio dan perencanaan awal](portfolio-discovery-initial-planning.md). Tujuannya adalah untuk mengulangi dan menetapkan dasar untuk portofolio awal aplikasi dan infrastruktur. Garis dasar ini mencakup identifikasi semua dependensi, mengulangi model rasionalisasi untuk migrasi, membuat kasus bisnis terperinci, dan menguraikan rencana gelombang migrasi. Akibatnya, kesetiaan data yang dibutuhkan lebih tinggi. Tahap ini akan membutuhkan investasi waktu. Untuk mempercepat hasil penilaian, sebaiknya gunakan sebanyak mungkin sumber data terprogram, seperti alat penemuan.
Hasil utama dari tahap ini meliputi:
+ Aplikasi dengan kesetiaan tinggi dan inventaris infrastruktur
+ Strategi migrasi tingkat tinggi untuk setiap aplikasi
+ Rencana gelombang migrasi dengan kepercayaan tinggi
+ Kasus bisnis yang terperinci
# Memahami persyaratan data penilaian lengkap
Tabel berikut menjelaskan informasi yang diperlukan untuk mendapatkan tampilan portofolio lengkap dari aplikasi dalam migrasi dan infrastruktur terkait.
Tabel menggunakan singkatan berikut:
+ R, untuk yang dibutuhkan
+ O, untuk opsional
+ N/A, karena tidak berlaku
**Aplikasi**
| **Nama atribut** | **Deskripsi** | **Inventarisasi dan prioritas** | **Kasus Bisnis Terperinci** | **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 | 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 | Tinggi |
| Apakah COTS? | Ya atau Tidak. Apakah ini aplikasi komersial atau pengembangan internal | R | R | Tinggi |
| Produk dan versi COTS | Nama dan versi produk perangkat lunak komersial | R | R | Tinggi |
| Deskripsi | Fungsi dan konteks aplikasi utama | R | R | Tinggi |
| Kekritisan | Misalnya, aplikasi strategis atau menghasilkan pendapatan, atau mendukung fungsi kritis | R | R | Tinggi |
| Tipe | Misalnya, database, manajemen hubungan pelanggan (CRM), aplikasi web, multimedia, layanan bersama TI | R | R | Tinggi |
| Lingkungan | Misalnya, produksi, pra-produksi, pengembangan, pengujian, kotak pasir | R | R | Tinggi |
| Kepatuhan dan peraturan | Kerangka kerja yang berlaku untuk beban kerja (misalnya, HIPAA, SOX, PCI-DSS, ISO, SOC, FedRAMP) dan persyaratan peraturan | R | R | Tinggi |
| Dependensi | Dependensi hulu dan hilir ke aplikasi atau layanan internal dan eksternal. Dependensi non-teknis seperti elemen operasional (misalnya, siklus pemeliharaan). | R | O | Tinggi |
| Pemetaan infrastruktur | Pemetaan ke aset and/or virtual fisik yang membentuk aplikasi | R | R | Tinggi |
| Lisensi | Jenis lisensi perangkat lunak komoditas (misalnya, Microsoft SQL Server Enterprise) | R | R | Tinggi medium |
| Biaya | Biaya untuk lisensi perangkat lunak, operasi perangkat lunak, dan pemeliharaan | N/A | R | Tinggi medium |
| Unit bisnis | Misalnya, pemasaran, keuangan, penjualan | R | R | Tinggi |
| Detail pemilik | Informasi kontak untuk pemilik aplikasi | R | R | Tinggi |
| Informasi DR | Komponen pemulihan bencana | R | R | Tinggi |
| Strategi migrasi | Misalnya, salah satu dari 6 Rs untuk migrasi ke AWS | R | R | Tinggi |
| Tiket Support | Data 12-24 bulan untuk membantu menilai produktivitas dan dampak keuangan dari pemadaman, perlambatan, pembatasan transaksi, dan pembengkakan jendela batch | O | R | 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 | R | Tinggi |
| Nama DNS (nama domain yang sepenuhnya memenuhi syarat, atau FQDN) | Nama DNS | R | O | Tinggi |
| Alamat IP dan netmask | Alamat IP and/or publik internal | R | R | Tinggi |
| Jenis aset | Misalnya, server fisik atau virtual, hypervisor, wadah, perangkat, contoh database | R | R | Tinggi |
| Nama produk | Vendor komersial dan nama produk (misalnya VMware ESXi, IBM Power Systems, Exadata) | R | R | Tinggi |
| Sistem operasi | Misalnya, REHL 8, Windows Server 2019, AIX 6.1 | R | R | Tinggi |
| Konfigurasi | CPU yang dialokasikan, jumlah inti, utas per inti, total memori, penyimpanan, kartu jaringan | R | R | Tinggi |
| Pemanfaatan | CPU, memori, dan puncak penyimpanan dan rata-rata. Throughput instance database. | R | R | Tinggi |
| Lisensi | Jenis lisensi komoditas (misalnya, Standar RHEL) | R | R | Tinggi |
| 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 | Tinggi |
| Pemetaan aplikasi | Aplikasi atau komponen aplikasi yang berjalan di infrastruktur ini | R | R | Tinggi |
| Biaya | Biaya terisi penuh untuk server bare-metal, termasuk perangkat keras, pemeliharaan, operasi, penyimpanan (SAN, NAS, Object), lisensi sistem operasi, pembagian ruang rak, dan overhead pusat data | N/A | R | Tinggi medium |
| Perkiraan volume transfer data (masuk/keluar) | Misalnya, per aset infrastruktur lebih dari per hari selama periode 30 hari | O | R | Sedang |
**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 (misalnya, 1000 MB/s redundan) | R | R | Tinggi medium |
| Pemanfaatan tautan | Puncak dan pemanfaatan rata-rata, transfer data keluar (GB/bulan) | R | R | Tinggi medium |
| Latensi (ms) | Latensi saat ini antara lokasi yang terhubung. | R | O | Tinggi |
| Biaya | Biaya saat ini per bulan | N/A | R | Tinggi medium |
**Migrasi**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/application-portfolio-assessment-guide/understanding-complete-assessment-data-requirements.html)
# Menetapkan baseline untuk portofolio aplikasi
Untuk membuat rencana gelombang migrasi dengan kepercayaan tinggi, Anda harus menetapkan dasar untuk portofolio aplikasi dan infrastruktur terkaitnya. Garis dasar portofolio memberikan pandangan komprehensif tentang ruang lingkup migrasi, termasuk dependensi teknis dan strategi migrasi. Garis dasar portofolio memberikan kejelasan tentang aplikasi mana yang berada dalam lingkup migrasi dan bahwa titik data yang diuraikan dalam bagian [Memahami persyaratan data penilaian lengkap](understanding-complete-assessment-data-requirements.md) dikumpulkan. Demikian juga, semua infrastruktur terkait (komputasi, jaringan penyimpanan) dipahami dan dipetakan ke aplikasi.
Ketergantungan teknis dapat dijelaskan dalam empat kategori:
+ **pplication-to-infrastructureDependensi** membangun hubungan antara perangkat lunak dan perangkat keras fisik atau virtual. Misalnya, ada ketergantungan antara aplikasi CRM dan mesin virtual tempat ia diinstal.
+ Dependensi **komponen aplikasi** menggambarkan bagaimana komponen yang berjalan di aset infrastruktur yang berbeda berinteraksi. Contoh ketergantungan komponen aplikasi adalah front end web yang berjalan pada mesin virtual, dengan lapisan aplikasi yang berjalan pada mesin virtual yang berbeda, dan database yang berjalan pada cluster database.
+ **pplication-to-applicationDependensi** berhubungan dengan interaksi antara aplikasi atau komponen aplikasi dengan aplikasi lain atau komponennya. Contoh application-to-application ketergantungan adalah aplikasi pemrosesan pembayaran dan aplikasi manajemen saham. Aplikasi ini independen, tetapi mereka terus-menerus berinteraksi menggunakan operasi API yang ditentukan.
+ Application-to-infrastructure dependensi **layanan** secara teknis adalah application-to-application dependensi, mengingat bahwa layanan infrastruktur itu sendiri merupakan aplikasi. Namun, kami sarankan untuk mengkategorikan ini secara terpisah. Alasan utamanya adalah bahwa layanan infrastruktur biasanya dibagi oleh banyak aplikasi, sehingga mereka memiliki jejak ketergantungan yang panjang. Mereka juga biasanya mengikuti strategi dan pola migrasi yang berbeda.Misalnya, penyeimbang beban dapat berisi kumpulan penyeimbang untuk beberapa aplikasi. Yang penting adalah ketergantungan ke kumpulan, yang kemungkinan akan dimigrasikan secara individual, di samping aplikasi dependen, sedangkan penyeimbang beban itu sendiri dipertahankan atau dihentikan. Selain itu, individualisasi dependensi application-to-infrastructure layanan membantu menghindari grup ketergantungan palsu. Kelompok ketergantungan palsu adalah ketika beberapa aplikasi bisnis dikelompokkan bersama, menyiratkan bahwa memiliki ketergantungan umum ke layanan infrastruktur harus dimigrasikan pada saat yang sama. Misalnya, layanan otentikasi, seperti Active Directory, cenderung dikaitkan dengan kelompok besar aplikasi. Kuncinya adalah mendekati aplikasi ini secara individual dan untuk mengatasi ketergantungan dengan mengaktifkan layanan, seperti AWS Directory Service for Microsoft Active Directory, di lingkungan cloud.
Saat Anda menetapkan baseline untuk portofolio, sebaiknya Anda mengonfirmasi strategi migrasi untuk setiap komponen aplikasi. Strategi migrasi akan menjadi salah satu dari 6 Rs untuk migrasi (lihat bagian [Mengulangi strategi migrasi 6 Rs](iterating-6-rs-migration-strategy-selection.md)). Dalam baseline portofolio, salah satu dari 6 Rs harus dikaitkan dengan setiap aplikasi. Strategi 6 R juga harus dikaitkan dengan masing-masing komponen infrastruktur aplikasi.
Untuk menetapkan versi dasar portofolio, termasuk dependensi dan strategi migrasi, gunakan alat penemuan otomatis (lihat [Mengevaluasi](understanding-initial-assessment-data-requirements.md#discovery-tooling) kebutuhan alat penemuan). Lengkapi data dengan informasi yang dikumpulkan dari pemangku kepentingan utama seperti pemilik aplikasi dan tim infrastruktur. Terus kumpulkan data sampai Anda mendapatkan inventaris portofolio lengkap yang sesuai dengan atribut dan tingkat kesetiaan yang diuraikan di [bagian persyaratan data](understanding-complete-assessment-data-requirements.md) untuk tahap ini. Dataset yang dihasilkan akan berperan penting dalam mendorong migrasi.
Pertimbangkan bahwa, tergantung pada luas cakupan migrasi Anda dan alat yang tersedia, aktivitas ini dapat memakan waktu beberapa minggu untuk diselesaikan.
# Mengulangi kriteria prioritas
Sebelum Anda membuat rencana gelombang migrasi, kami sarankan Anda mengulangi kriteria prioritas aplikasi untuk beralih dari pemilihan aplikasi pilot ke perencanaan gelombang jangka panjang.
[Di bagian sebelumnya, kami memperkenalkan kriteria prioritas default yang akan memprioritaskan aplikasi sederhana yang siap cloud (lihat Memprioritaskan aplikasi).](prioritization-and-migration-strategy.md#prioritizing-applications) Ini karena pada tahap awal kami merekomendasikan memulai dengan aplikasi nonkritis untuk menyempurnakan proses migrasi dan menggabungkan pelajaran yang dipetik. Namun, pada tahap ini, dan untuk membuat rencana jangka panjang, urutan migrasi aplikasi harus diselaraskan dengan driver bisnis. Menerapkan kriteria baru akan menghasilkan peringkat aplikasi baru yang akan menjadi masukan utama untuk perencanaan gelombang.
Tinjau poin data yang tersedia dari portofolio aplikasi, dan pilih atribut yang akan menentukan prioritas aplikasi berdasarkan driver bisnis.
Pertama, validasi driver bisnis Anda (lihat [Penggerak bisnis dan prinsip panduan teknis](business-drivers-technical-guiding-principles.md)). Selanjutnya, berdasarkan driver bisnis Anda, pilih atribut yang akan membantu memprioritaskan aplikasi untuk migrasi.
Tabel berikut menunjukkan contoh kriteria prioritas yang selaras dengan pendorong bisnis untuk inovasi.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/application-portfolio-assessment-guide/iterating-prioritization-criteria.html)
Tabel berikut menunjukkan contoh kriteria prioritas yang selaras dengan pendorong bisnis untuk pengurangan biaya cepat.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/application-portfolio-assessment-guide/iterating-prioritization-criteria.html)
Uji kriteria prioritas dan ulangi sampai Anda umumnya setuju dengan output. Dibutuhkan setidaknya tiga atau empat iterasi untuk mendapatkan versi dasar.
# Mengulangi pemilihan strategi migrasi 6 Rs
Pada tahap ini, kami menyarankan Anda mengulangi dan mengembangkan pohon keputusan 6 Rs. Bagian [Menentukan tipe R untuk migrasi](prioritization-and-migration-strategy.md#migration-r-type) memperkenalkan pohon keputusan default. Kami merekomendasikan untuk merevisi pohon, mempertimbangkan pembelajaran selama migrasi aplikasi percontohan awal, dan memastikan bahwa itu masih selaras dengan driver bisnis, kriteria prioritas, dan keadaan unik Anda. Validasi pohon keputusan dengan aplikasi sampel, dan verifikasi bahwa itu masih menghasilkan strategi yang diharapkan. Jika tidak, perbarui logika yang sesuai. Pohon yang dihasilkan akan menjadi kunci dalam menetapkan garis dasar untuk portofolio aplikasi dan dalam mengalokasikan strategi migrasi untuk setiap komponen aplikasi.
Seperti yang dijelaskan di [bagian 6 Rs](prioritization-and-migration-strategy.md#migration-r-type) sebelumnya, 6 Rs juga berlaku untuk infrastruktur, dan sama pentingnya untuk menetapkannya sesuai. Sementara komponen aplikasi tertentu akan memiliki strategi migrasi, pada tingkat infrastruktur, setiap aset infrastruktur akan mengikuti strategi migrasi tertentu yang mungkin berbeda dari strategi yang ditetapkan untuk komponen aplikasi yang didukungnya.
Ingat bahwa pohon keputusan 6 Rs hanya berlaku untuk komponen aplikasi. Strategi migrasi untuk infrastruktur berasal dari strategi yang dipilih untuk aplikasi. Misalnya, untuk komponen aplikasi yang akan di-replatform, infrastruktur saat ini yang menjadi host dapat dihentikan.
Pastikan bahwa strategi migrasi dialokasikan untuk setiap komponen aplikasi dan infrastruktur yang terkait. Informasi ini akan menjadi faktor kunci ketika memperkirakan upaya, kapasitas, dan keterampilan yang dibutuhkan, dan saat membuat rencana gelombang migrasi.
Untuk informasi lebih lanjut tentang menentukan 6 Rs Anda, lihat [rekomendasi AWS Migration Hub strategi](https://aws.amazon.com/blogs/aws/new-strategy-recommendations-service-helps-streamline-aws-cloud-migration-and-modernization/).
# Perencanaan gelombang
Dalam perencanaan gelombang, kelompok ketergantungan adalah kumpulan aplikasi dan infrastruktur yang memiliki dependensi teknis dan nonteknis yang tidak dapat diselesaikan. Karena dependensi ini, aplikasi dan infrastruktur dalam grup dependensi harus dimigrasikan pada waktu yang sama atau pada tanggal tertentu. Misalnya, aplikasi yang berjalan pada mesin virtual dan database yang berjalan di mesin virtual terpisah, di mana ada persyaratan latensi rendah atau volume lalu lintas tinggi dan kueri kompleks, cenderung bermigrasi bersama daripada mengoperasikan satu komponen di cloud dan yang lainnya di tempat. Demikian juga, aplikasi independen yang berinteraksi melalui API dengan persyaratan latensi rendah serupa juga akan dimigrasikan pada saat yang bersamaan.
Gelombang migrasi biasanya berlangsung 4-8 minggu, dan dapat berisi satu atau lebih peristiwa migrasi. Kelompok ketergantungan digabungkan menjadi gelombang sehingga gelombang dapat berisi satu atau lebih kelompok ketergantungan. Gelombang juga berisi aktivitas lain yang diperlukan untuk migrasi. Ini termasuk penyiapan AWS infrastruktur (seperti landing zone, keamanan, dan operasi), alat migrasi, dan aktivitas migrasi seperti replikasi data, perencanaan cut-over, pengujian, dan dukungan pasca-migrasi.
Untuk mengukur keberhasilan dan melacak kemajuan, gelombang harus diselaraskan dengan hasil dan pendorong bisnis. Ini juga akan mempengaruhi durasi gelombang dan kelompok ketergantungan yang terkandung dalam gelombang. Penyelesaian gelombang harus mencerminkan pencapaian yang terukur. Perencanaan gelombang juga dapat menggabungkan faktor-faktor lain, seperti prinsip panduan teknis. Misalnya, gelombang dapat didefinisikan oleh lingkungan (misalnya, pengembangan, pengujian, produksi) atau dengan strategi migrasi (misalnya, gelombang rehost, gelombang replatform).
Untuk membuat rencana gelombang migrasi yang efektif dan percaya diri tinggi, Anda harus mendapatkan tampilan lengkap dari portofolio aplikasi, infrastruktur terkait (komputasi, penyimpanan, jaringan), pemetaan ketergantungan, dan strategi migrasi.
Bagian tentang [menetapkan garis dasar untuk portofolio aplikasi](baseline-application-portfolio.md) menjelaskan empat kategori dependensi teknis. Dependensi ini berkontribusi pada penciptaan gelombang migrasi dan definisi kelompok ketergantungan. Kelompok ketergantungan akan ditentukan oleh kekritisan ketergantungan. Selain itu, dependensi nonteknis harus dipertimbangkan. Misalnya, jadwal rilis aplikasi, jendela pemeliharaan, dan tanggal bisnis utama seperti pemrosesan akhir bulan akhir kuartal akan memengaruhi rencana gelombang.
Tentukan apakah ketergantungannya *lunak* atau *keras*. Ketergantungan lunak adalah hubungan antara dua atau lebih aset, atau dari aset ke kendala, yang tidak tergantung pada lokasi komponen. Misalnya, dua sistem yang beroperasi di jaringan lokal yang sama (atau infrastruktur yang sama) dapat dipisahkan dengan memindahkan salah satu sistem tersebut ke cloud sementara yang lain tetap di tempat. Contoh lain adalah sistem yang dapat dimigrasikan selama jendela pemeliharaan tanpa memengaruhi aktivitas pemeliharaan.
Ketergantungan keras adalah hubungan antara dua atau lebih aset, atau dari aset ke kendala, yang bergantung pada lokasi. Misalnya, dua sistem yang beroperasi di jaringan lokal yang sama, dan yang sangat bergantung pada latensi rendah untuk komunikasi antara server aplikasi dan server database, memiliki ketergantungan keras. Memindahkan hanya satu dari sistem ini ke cloud akan menyebabkan masalah fungsionalitas atau kinerja yang tidak dapat diselesaikan. Demikian juga, alasan nonteknis, seperti ketersediaan sumber daya (misalnya, tim yang melakukan migrasi) atau kendala operasional, seperti jendela pemeliharaan di mana dua sistem hanya dapat dimigrasikan dalam jendela waktu tertentu, dapat membuat ketergantungan keras untuk aset ini.
Untuk membuat rencana gelombang migrasi, tentukan grup dependensi Anda dengan menganalisis dependensi, idealnya dari sumber data yang sangat tepercaya seperti alat penemuan khusus, dan gabungkan informasi ini dengan kriteria prioritas aplikasi dan keadaan operasional Anda. Aplikasi di bagian atas peringkat prioritas harus ditargetkan untuk gelombang migrasi awal Anda. Tentukan kapasitas gelombang (jumlah aplikasi yang dapat ditampung gelombang) berdasarkan ketersediaan sumber daya, toleransi risiko, kendala bisnis dan teknis, pengalaman, dan keterampilan. Pertimbangkan untuk bekerja dengan Layanan AWS Profesional atau Mitra Kompetensi AWS Migrasi, yang dapat menyediakan spesialis untuk membantu Anda selama proses berlangsung.
Kriteria prioritas adalah indikasi awal dari urutan di mana Anda akan memindahkan aplikasi Anda ke cloud. Namun, kelompok ketergantungan akan menjadi penentu aktual untuk aplikasi yang akan dipindahkan pada waktu tertentu. Ini karena aplikasi yang digolongkan sebagai prioritas tinggi dapat memiliki ketergantungan keras pada aplikasi yang berada di tengah atau di bawah peringkat.
Strategi migrasi juga akan mempengaruhi komposisi gelombang. Misalnya, aplikasi prioritas tinggi yang memerlukan strategi refactor yang mungkin memerlukan beberapa minggu atau bulan analisis, desain, pengujian, dan persiapan kemungkinan akan ditempatkan dalam gelombang berikutnya.
## Membuat rencana gelombang
Prasyarat untuk memigrasikan gelombang aplikasi adalah data portofolio aplikasi dan penilaian aplikasi terperinci dari kelompok aplikasi yang akan dimigrasikan dalam gelombang. Penilaian terperinci harus mencakup daftar aplikasi dalam gelombang, detail infrastruktur terkait, desain target, dan strategi migrasi untuk setiap aplikasi.
Menetapkan kepemilikan dan tata kelola gelombang adalah kunci untuk mengelola dan melacak pekerjaan gelombang, ketergantungan program, manajemen perubahan, masalah, dan risiko. Pastikan bahwa kerangka kerja tata kelola ada untuk mengelola rencana.
Untuk menguraikan rencana gelombang, mulailah dengan konstruksi gelombang default. Apa yang terjadi dalam gelombang? Setelah input awal ditentukan, gelombang dapat dimulai. Biasanya, kegiatannya adalah:
1. Perbaiki rencana cutover. Kegiatan ini harus menguraikan runbook dan langkah-langkah yang harus diambil pada saat migrasi, termasuk koordinasi dengan tim internal dan eksternal lainnya.
1. Perbaiki rencana rollback. Apa yang harus dilakukan untuk memutar kembali aplikasi jika ada yang salah?
1. Siapkan infrastruktur target. Misalnya, Anda dapat membuat atau memperluas AWS landing zone (Akun AWS, keamanan, jaringan, layanan infrastruktur, infrastruktur pendukung lainnya).
1. Uji infrastruktur target.
1. Mengoperasikan perkakas migrasi. Misalnya, instal agen replikasi dan mulai transfer data.
1. Lakukan rencana cutover dan runbook dry run. Kelompokkan semua anggota tim yang berpartisipasi, dan tinjau semua langkah sebelumnya.
1. Memantau replikasi data dan penyebaran infrastruktur.
1. Konfirmasikan kesiapan untuk pengoperasian infrastruktur dan aplikasi di AWS.
1. Konfirmasikan kesiapan keamanan.
1. Konfirmasikan kepatuhan dan persyaratan peraturan (misalnya, validasi beban kerja sebelum migrasi dan pasca-migrasi) jika berlaku.
1. Migrasikan aplikasi ke AWS dan lakukan pengujian pra go-live.
1. Berikan dukungan pasca-migrasi untuk jangka waktu tertentu, seperti 3 hari, saat tim operasi dan tim migrasi sepenuhnya tersedia untuk menyelesaikan masalah, dan menerapkan pengoptimalan.
1. Lakukan tinjauan pasca-migrasi. Dokumentasikan pelajaran yang dipetik, dan gabungkan ke dalam gelombang masa depan.
1. Lakukan penutupan gelombang dengan mengonfirmasi serah terima operasional dan perolehan metrik untuk pelaporan.
Berapa lama masing-masing kegiatan ini akan ditentukan oleh kompleksitas ruang lingkup, kapasitas gelombang, orang-orang yang terlibat, dan keadaan unik Anda. Jika memungkinkan, gelombang yang lebih kecil lebih disukai karena itu akan mengurangi dampak penundaan atau penghambat migrasi. Tentukan, dengan tim Anda, berapa durasi default gelombang nantinya.
Selanjutnya, lanjutkan untuk menganalisis tanggal untuk membuat struktur gelombang kosong tingkat tinggi awal (tanpa aplikasi yang ditetapkan). Pertimbangkan pertanyaan-pertanyaan berikut:
+ Berapa total panjang program migrasi?
+ Apa tenggat waktu?
+ Apakah ada tanggal keluar pusat data tetap?
+ Apakah ada tanggal akhir kontrak kolokasi?
+ Apa siklus penyegaran aplikasi dan infrastruktur?
+ Apa siklus pemeliharaan dan rilis aplikasi?
+ Apakah ada tanggal ketika migrasi harus dihindari (misalnya, siklus rilis dan pemeliharaan, akhir tahun, hari libur, pemrosesan akhir bulan)?
Dengan pertimbangan ini, plot gelombang ke dalam rencana. Untuk mempercepat proses migrasi, kami merekomendasikan gelombang yang tumpang tindih jika memungkinkan. Kunci untuk gelombang yang tumpang tindih adalah mendefinisikan dan mempertimbangkan apa yang terjadi dalam gelombang. Biasanya, aktivitas penyebaran, validasi infrastruktur target, dan sinkronisasi data akan terjadi selama paruh pertama gelombang. Babak kedua akan fokus pada migrasi aktual, pengujian, dan serah terima operasional. Ini berarti bahwa tim yang berbeda terlibat dalam setiap setengah proses, dan Anda dapat memperoleh beberapa efisiensi. Misalnya, segera setelah tim yang terlibat dalam persiapan infrastruktur target menyelesaikan pekerjaan mereka, mereka dapat mulai mengerjakan persyaratan gelombang berikutnya. Secara umum, lebih disukai bahwa sebagian besar gelombang memiliki panjang dan struktur yang sama untuk memfasilitasi pendekatan migrasi seperti pabrik. Namun, selama proses perencanaan gelombang, ukuran gelombang tertentu dapat diperpanjang untuk memenuhi dependensi atau persyaratan operasional.
Selanjutnya, berdasarkan kelompok ketergantungan yang telah diidentifikasi, tentukan ukuran maksimum gelombang dalam hal jumlah kelompok ketergantungan yang dapat dikandungnya. Ukuran gelombang biasanya ditentukan oleh selera risiko (misalnya, berapa banyak perubahan paralel yang dapat ditoleransi), dan ketersediaan sumber daya (misalnya, berapa banyak perubahan paralel yang dapat dilakukan dengan sumber daya, keterampilan, dan anggaran yang tersedia). Namun, selama perencanaan awal, jangan dibatasi oleh persyaratan dan ketersediaan sumber daya. Gelombang yang mengandung lebih dari satu kelompok ketergantungan dapat didekomposisi menjadi gelombang yang lebih kecil dalam iterasi future.
Setelah kelompok dependensi untuk gelombang tertentu telah dikonfirmasi, tinjau persyaratan sumber daya untuk memigrasikan gelombang. Pertimbangkan untuk menyesuaikan ukuran gelombang (jumlah kelompok ketergantungan yang dikandungnya) berdasarkan kebutuhan sumber daya. Hal ini dapat menyebabkan gelombang yang lebih kecil atau lebih besar. Ulangi rencana gelombang sesuai kebutuhan sampai semua gelombang telah ditentukan.
## Mengelola perubahan
Portofolio aplikasi dan infrastruktur terkait akan berubah selama siklus hidup program migrasi. Program migrasi yang berjalan lama hidup berdampingan dengan evolusi dan perubahan bisnis normal. Aplikasi terus berkembang saat menunggu untuk dimigrasi. Server ditambahkan atau dihapus, infrastruktur baru digunakan di tempat. Diharapkan bahwa ruang lingkup gelombang atau kelompok ketergantungan akan membutuhkan perubahan. Perubahan diperlukan terutama ketika, lebih dekat ke tanggal migrasi, ketergantungan yang sebelumnya tidak diketahui diidentifikasi, atau server baru disertakan dalam inventaris. Terkadang ini bisa terjadi selama migrasi itu sendiri.
Perubahan lingkup mempengaruhi kelompok ketergantungan dan gelombang. Untuk menangani perubahan dan meminimalkan dampak, penting untuk menetapkan mekanisme kontrol ruang lingkup. Mekanisme kontrol perubahan ruang lingkup membutuhkan definisi satu sumber kebenaran untuk ruang lingkup. Ini bisa menjadi alat untuk mengelola ruang lingkup, atau file.csv, spreadsheet, atau database, seperti yang didefinisikan oleh tata kelola program migrasi. Anda harus mengidentifikasi perubahan, menganalisis dampak, dan mengkomunikasikan perubahan kepada pemangku kepentingan yang relevan sehingga mereka dapat mengambil tindakan. Rencana gelombang akan diulang sebagai hasilnya.
# Kasus bisnis terperinci
Pada tahap ini, kami merekomendasikan untuk memvalidasi dan memperluas ruang lingkup kasus bisnis untuk memberikan tingkat detail yang lebih besar untuk mendukung program transformasi. Kasus bisnis terarah awal yang dirakit dengan cepat dirancang untuk memberikan kepercayaan yang cukup untuk berinvestasi dalam langkah-langkah dasar dan tingkat perencanaan terperinci berikutnya.
Mengembangkan kasus bisnis terperinci mendukung proses perencanaan ini dengan cara berikut:
+ Memberikan analisis keuangan yang menginformasikan keputusan tentang apa yang harus dimigrasikan dan dimodernisasi, opsi mana yang harus dipilih dan bagaimana melakukan fase dan memprioritaskan pekerjaan
+ Memvalidasi, menyempurnakan, dan mengembangkan kasus keuangan terarah asli dengan memeriksa ulang secara rinci:
+ Potensi pengurangan biaya infrastruktur
+ Produktivitas TI internal dan efisiensi operasi outsourcing
+ Perkiraan untuk investasi yang diperlukan untuk pengaturan program, migrasi, dan modernisasi
+ Mengidentifikasi, memperkirakan skala, dan menyiapkan proses untuk melacak driver nilai lebih lanjut yang dibawa migrasi
Dalam kasus bisnis terperinci, Anda menetapkan yang berikut:
+ Dasar obyektif untuk mengamankan mandat dan investasi untuk melaksanakan setidaknya tahap pertama migrasi
+ Harapan kinerja keuangan minimum dasar untuk program
+ Kejelasan atas dasar keuangan di mana berbagai desain migrasi dan keputusan prioritas dibuat, sehingga ketika keadaan dan orang-orang berubah selama program, kepemimpinan baru dapat membuat pilihan berdasarkan informasi.
+ Wawasan tentang area tambahan pengoptimalan biaya yang akan dieksplorasi setelah data penggunaan awal tersedia saat beban kerja dimigrasikan dan mulai beroperasi
+ Perkiraan nilai yang dibawa transformasi cloud ke bisnis dari peningkatan ketahanan dan kelincahan
+ Terkait KPIs, metrik, dan asumsi yang digunakan untuk memperkirakan pengembalian finansial dari peningkatan ketahanan dan kelincahan, yang kemudian membentuk dasar untuk mendorong realisasi manfaat utama keluar dari program
## Tentukan skenario yang diperlukan untuk kasus ini
Ketika membangun kasus bisnis terperinci, biasanya perlu untuk mengembangkan beberapa skenario untuk mendukung berbagai tujuan yang digunakan untuk kasus bisnis.
**Skenario perubahan minimum** — Untuk menilai ekspektasi kinerja keuangan minimum, siapkan skenario yang mengasumsikan perubahan minimum yang diharapkan pada status quo. Skenario ini, sebagai skenario terburuk, adalah dukungan yang berguna saat mendapatkan mandat untuk berinvestasi dalam migrasi. Skenario ini memodelkan tingkat pertumbuhan kapasitas minimum yang diharapkan dan perubahan minimum untuk quality-of-service kebutuhan lain, seperti ketersediaan dan ketahanan. Perubahan terkecil menciptakan biaya terendah dan inefisiensi sumber daya paling sedikit untuk model operasi saat ini.
**Skenario yang paling mungkin** — Untuk menginformasikan strategi program dan keputusan prioritas, siapkan skenario yang mencerminkan apa yang diharapkan bisnis terjadi. Skenario ini harus mencakup kemungkinan pertumbuhan atau pengurangan pemanfaatan puncak dan biaya peningkatan untuk memenuhi permintaan akan kualitas layanan tingkat tinggi (terutama ketersediaan dan ketahanan) dari bisnis.
**Skenario spesifik lainnya** — Di mana masih perlu untuk membuat asumsi yang dapat berdampak besar pada kasus bisnis, kembangkan skenario baik di mana asumsi itu benar dan di mana tidak. Namun, kami sarankan untuk menjaga jumlah skenario alternatif ini seminimal mungkin. Membuat lebih dari tiga hingga empat skenario secara total memperlambat kemajuan, dan menjadi mahal, membingungkan, dan sulit dipertahankan. Jika memungkinkan, lakukan eksperimen dan bekerja untuk menghilangkan asumsi yang lebih besar.
## Memvalidasi dan menyempurnakan infrastruktur dan model biaya migrasi
Setelah Anda menyelesaikan analisis portofolio dan menyiapkan desain dan ukuran target Layanan AWS, perbaiki perkiraan biaya operasional untuk model operasi saat ini (COM) dan model operasi future (FOM) AWS untuk setiap skenario. Biasanya perlu untuk menyempurnakan perkiraan untuk hal-hal berikut:
+ **Biaya infrastruktur COM** dari server host hypervisor, server bare-metal, penyimpanan, perangkat jaringan, penyegaran perangkat keras alat keamanan, instalasi, dan pemeliharaan. Hitung ini dengan harga aktual dan tingkat diskon untuk kapasitas yang dibutuhkan untuk skenario tersebut.
+ **Biaya pusat data COM dan fasilitas kolokasi**, termasuk ruang, pendinginan, daya, rak, catu daya tak terputus (UPS), pemasangan kabel, sistem keamanan fisik, ukuran untuk pertumbuhan dan ditentukan untuk memenuhi kapasitas, dan tingkat ketersediaan dan pemulihan bencana (DR) yang tinggi untuk skenario tersebut.
+ **Biaya layanan jaringan COM**, termasuk biaya untuk tautan WAN, jaringan pengiriman konten, dan jaringan pribadi virtual (VPNs), dihitung menggunakan harga kontrak untuk konektivitas, bandwidth, throughput, dan kebutuhan latensi untuk skenario tersebut.
+ **Biaya aplikasi dan perangkat lunak infrastruktur COM** berdasarkan kontrak yang ada untuk memberikan pertumbuhan atau pengurangan penggunaan untuk skenario tersebut.
+ **Biaya AWS utilitas FOM**, termasuk dukungan teknis dan layanan terkelola sesuai kebutuhan, berdasarkan arsitektur layanan yang disempurnakan, ukuran instans, model harga pilihan, penggunaan yang diharapkan, dan volatilitas penggunaan.
+ **Lisensi aplikasi FOM** berdasarkan desain aplikasi akhir, konfigurasi infrastruktur yang menjalankan aplikasi, pertumbuhan dari waktu ke waktu, dan aturan transferabilitas lisensi.
+ **Perkiraan biaya migrasi dan modernisasi FOM**, disempurnakan untuk mencerminkan rencana gelombang migrasi dasar untuk skenario tersebut, dan dirinci untuk menyediakan biaya untuk setiap beban kerja, terutama bagi mereka yang akan direplatform, dibeli kembali, atau difaktorkan ulang.
+ **Biaya penonaktifan FOM**, termasuk perkiraan penghapusan aset dan biaya penghentian awal kontrak, direvisi untuk mencerminkan waktu penonaktifan dalam rencana gelombang migrasi dasar, verifikasi aset apa yang dapat digunakan kembali dan aset apa yang dapat dialihkan untuk meminimalkan penghapusan, dan biaya pembuangan aset fisik dan media.
+ **Biaya proses paralel migrasi** disempurnakan untuk mencerminkan waktu setiap pemotongan migrasi dan setiap penonaktifan layanan yang ada.
## Menyempurnakan produktivitas TI dan operasi TI serta mendukung model nilai efisiensi
Seperti halnya kasus bisnis terarah, ada dua pendekatan utama untuk menyempurnakan dan mengembangkan model nilai seputar operasi dan dukungan TI. Pendekatan yang Anda pilih tergantung pada apakah COM dikelola secara internal atau dengan kontraktor atau layanan outsourcing:
*Peningkatan produktivitas tim internal*
Di mana operasi dan dukungan TI dikelola di rumah, fokus kasus bisnis adalah sebagai berikut:
+ Mengidentifikasi dan mengukur keuntungan produktivitas dari migrasi dan otomatisasi operasional apa pun yang termasuk dalam ruang lingkup
+ Memvalidasi bahwa waktu yang dibebaskan untuk tim internal dapat dengan mudah dan produktif diterapkan pada kegiatan lain yang biasanya bernilai lebih tinggi, memberikan peluang untuk kemajuan dan penghargaan yang lebih besar kepada tim dan nilai lebih bagi organisasi
Menilai berapa banyak waktu yang dihabiskan setiap anggota dalam setiap peran dalam tim untuk berbagai kegiatan rutin mereka, dan bimbingan tentang pengurangan beban kerja yang diharapkan untuk kegiatan yang berbeda.
Tabel berikut memberikan panduan awal untuk tingkat tipikal pengurangan beban kerja berdasarkan aktivitas untuk tugas-tugas yang menghabiskan sebagian besar operasi TI dan upaya dukungan di berbagai peran dalam tim. Tabel ini mencakup deskripsi tentang bagaimana produktivitas dicapai.
**catatan**
Kegiatan yang tercantum biasanya dilakukan oleh anggota tim dalam beberapa peran yang berbeda, sehingga penghematan produktivitas untuk setiap tugas harus dinilai di seluruh set lengkap peran dalam tim. Misalnya, dalam tim operasi TI yang diselenggarakan oleh menara infrastruktur (seperti komputasi, penyimpanan, dan jaringan), perencanaan belanja modal dan penganggaran mungkin umum untuk menara lead untuk setiap menara.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/application-portfolio-assessment-guide/detailed-business-case.html)
Tabel berikut menunjukkan penghematan yang diharapkan untuk setiap tingkat pengurangan beban kerja.
| **Level** | **Diharapkan** |
| --- | --- |
| Sangat tinggi | 85% - 100% |
| Tinggi | 60% - 90% |
| Sedang | 30% - 70% |
| Rendah | 10% - 35% |
| Minimal | 0% - 10% |
Metrik ini memberikan titik awal untuk menilai peningkatan produktivitas dan memasukkannya ke dalam kasus bisnis terperinci. Keuntungan produktivitas aktual bervariasi berdasarkan situasi tertentu. Ini dapat berguna untuk menghitung penghematan produktivitas di titik tengah dan ujung bawah rentang untuk memperkirakan skenario tipikal dan konservatif.
Seiring kemajuan program, penting untuk menangkap data aktual untuk waktu yang dihabiskan pada setiap aktivitas berdasarkan peran. Data tersebut membangun basis yang lebih baik untuk memperkirakan operasi dan mendukung biaya untuk proyek baru dan perluasan layanan.
*Mengalihdayakan operasi TI dan mendukung pengurangan biaya*
[Di mana operasi dan dukungan TI terutama dialihdayakan atau dikelola dengan kontraktor, alokasi biaya untuk model operasi future (FOM) dapat disiapkan dengan meminta penawaran dari AWS Mitra yang menawarkan solusi layanan terkelola, termasuk Partner-led (AMS). AWSAWS Managed Services](https://aws.amazon.com/managed-services/partners/) Anda juga dapat menghubungi manajer AWS akun Anda dan meminta harga untuk AMS secara langsung, seperti yang dijelaskan dalam ayat tentang [Membangun optimalisasi biaya operasional dalam](directional-business-case.md#building-operational-cost-optimization) bagian [Membuat kasus bisnis terarah](directional-business-case.md).
Untuk kasus bisnis terperinci, ganti angka tolok ukur apa pun dengan kutipan berdasarkan tagihan bahan layanan yang direvisi dan konsumsi AWS layanan yang diharapkan, paket AMS dan opsi apa pun yang diperlukan, dan tingkat layanan yang diperlukan. Biaya akan memiliki komponen implementasi satu kali dan run rate berbasis konsumsi.
Sertakan operasi TI yang tersisa, dukungan yang harus dipertahankan untuk layanan apa pun yang tidak akan dimigrasikan AWS, dan biaya satu kali jika ada penalti kontrak (misalnya, untuk penghentian dini).
## Mengembangkan model nilai ketahanan
Pada AWS, Anda dapat membangun berbagai ketersediaan tinggi, pemulihan bencana, dan arsitektur toleran kesalahan. Penetapan harga berbasis konsumsi berarti bahwa layanan dibebankan hanya jika digunakan. Bersama-sama, kedua faktor ini memberikan kinerja biaya yang luar biasa untuk ketahanan.
Selain itu, AWS ccustomer telah menggunakan ini untuk meningkatkan ketahanan beban kerja mereka. [Survei IDC 2018](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770) memberikan contoh pelanggan yang berpartisipasi mencapai 73 persen lebih sedikit pemadaman per tahun, pengurangan 58 persen dalam mean time to recover (MTTR) dan penurunan 94 persen dalam produktivitas yang hilang. Survei yang sama menunjukkan bahwa manfaat finansial yang diperoleh melalui peningkatan ketahanan adalah 50 persen lebih besar daripada manfaat pengurangan biaya infrastruktur TI.
Selain itu, ketahanan lebih lanjut dicapai melalui modernisasi siklus hidup pengembangan perangkat lunak untuk aplikasi. Di mana CI/CD jaringan pipa dengan otomatisasi pengujian diperkenalkan untuk mendukung kelincahan bisnis yang lebih besar, cacat perangkat lunak ditangkap lebih awal dalam siklus pengembangan, sangat mengurangi biaya pemeliharaan perangkat lunak.
**Untuk menilai dan memasukkan nilai ini dalam kasus bisnis, pertama-tama bekerja dengan pemilik bisnis aplikasi untuk membangun gambaran *peluang manfaat total* untuk setiap beban kerja yang akan dimigrasikan.**Ini mungkin termasuk sebagai item berikut:
+ Jumlah, durasi rata-rata, dan sifat interupsi dalam layanan:
+ Contoh gangguan layanan termasuk pemadaman, perlambatan kinerja, batch terencana dan pemeliharaan jendela overrunning, bug dalam fungsi utama, dan pembatasan akses selama periode puncak.
+ Dampak pada pendapatan oleh gangguan layanan yang menghasilkan pendapatan, seperti sistem e-commerce:
+ Kemungkinan jumlah transaksi yang tidak dapat diselesaikan melalui gangguan layanan, berdasarkan waktu interupsi dan tingkat transaksi
+ Nilai rata-rata untuk setiap transaksi yang terkena dampak
+ Biaya tambahan waktu insinyur pendukung untuk menyelesaikan cacat dalam sistem produksi dibandingkan dengan biaya untuk menemukannya lebih awal dalam proses pengembangan
+ Dampak pada produktivitas pengguna internal dan biaya waktu yang hilang
Kemudian buat penilaian pengurangan waktu yang diharapkan dan lebih konservatif yang hilang karena gangguan layanan**** yang harus dihasilkan oleh peningkatan ketahanan. Misalnya, pertimbangkan untuk memasukkan item-item berikut:
+ Mengurangi jumlah pemadaman dan MTTR menggunakan arsitektur ketersediaan tinggi dan peningkatan tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO)
+ Pengurangan perlambatan, penghapusan pelambatan kapasitas dan penghindaran dalam kelebihan pemrosesan batch, menggunakan kemampuan seperti penskalaan otomatis
+ Mengurangi jumlah bug aplikasi yang hanya ditemukan dalam produksi, melalui implementasi CI/CD pipeline dan pengujian regresi otomatis pada infrastruktur yang diputar dan diputar ke bawah untuk meminimalkan biaya
Satukan ini untuk portofolio aplikasi yang akan dimigrasikan dan dimodernisasi, dan hitung angka nilai bisnis yang diharapkan dan lebih konservatif untuk setiap tahun kasus. Manfaat harus meningkat sejalan dengan jadwal migrasi dan kemudian meningkatkan volume sesuai dengan ekspektasi pertumbuhan penggunaan dari aplikasi yang berkontribusi.
## Mengembangkan model nilai kelincahan bisnis
Kelincahan bisnis adalah alasan utama AWS pelanggan bermigrasi. AWS[Survei AWS pelanggan IDC 2018](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770) menunjukkan bahwa bagi mereka, manfaat kelincahan bisnis menyumbang 47 persen dari total manfaat yang diukur dan lebih dari lima kali manfaat yang diperoleh dari pengurangan biaya infrastruktur.
Memprediksi secara akurat semua manfaat kelincahan bisnis yang akan diperoleh dari transformasi apa pun adalah tantangan. Namun, dengan berfokus pada aplikasi yang mendukung sejumlah besar pengguna atau merupakan sumber diferensiasi bisnis, Anda dapat memodelkan dan memasukkan bagian material dari manfaat ini ke dalam kasus bisnis rinci dasar.
Ketika migrasi berlangsung, secara bertahap menyempurnakan dan memperluas model nilai kelincahan bisnis karena lebih banyak manfaat menjadi terukur. Ini membuat kasus bisnis tetap relevan, sehingga dapat digunakan sebagai alat pendukung keputusan utama untuk mengarahkan program.
Untuk membangun model nilai kelincahan bisnis, gunakan panduan berikut:
+ Pilih beban kerja yang memiliki kesempatan untuk mendorong peningkatan kinerja bisnis terbesar, seperti:
+ Beban kerja yang menghasilkan pendapatan
+ Beban kerja operasi bisnis dengan ruang lingkup untuk mendorong peningkatan efisiensi dan menghilangkan biaya dari bisnis
+ Alat produktivitas bisnis yang mendukung basis pengguna yang besar
+ Untuk beban kerja yang menghasilkan pendapatan dan efisiensi, lakukan hal berikut:
+ Buat penilaian yang realistis dan lebih konservatif terhadap pertumbuhan pendapatan atau efisiensi operasional yang diharapkan dapat didorong oleh peningkatan aplikasi besar dan kecil.
+ Perkirakan peningkatan jumlah rilis mayor dan minor per tahun yang AWS meningkatkan kecepatan pengembangan aplikasi dan mengurangi waktu penyebaran infrastruktur memungkinkan. Beberapa metrik dasar untuk ini disediakan dalam laporan IDC.
+ Hitung ekspektasi manfaat yang realistis dan lebih konservatif. Petakan mereka selama periode kasus bisnis, membuat tunjangan untuk meningkatkan efisiensi penuh beberapa saat setelah beban kerja masing-masing dimigrasikan.
+ Untuk alat produktivitas bisnis, lakukan hal berikut:
+ Buat penilaian yang realistis dan lebih konservatif tentang penghematan waktu yang diharapkan dapat didorong oleh peningkatan aplikasi besar dan kecil.
+ Perkirakan biaya rata-rata waktu dan upaya orang di seluruh basis pengguna yang terkena dampak.
+ Gunakan angka untuk meningkatkan frekuensi rilis mayor dan minor, dan hitung manfaatnya selama jangka waktu kasus bisnis.
Karena peningkatan produktivitas pengembang dan pengurangan waktu untuk peluncuran tidak memerlukan sumber daya tambahan, tambahkan garis manfaat bersih untuk setiap beban kerja ke dalam model arus kas kasus bisnis untuk dimasukkan dalam arus kas diskon, NPV, ROI, MIRR, dan perhitungan pengembalian.