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 segera menunjukkan nilai potensi yang cukup dari program migrasi, sehingga Anda dapat mengamankan sumber daya yang diperlukan untuk merencanakan dan membangun program. Kasus bisnis terarah dirancang untuk memberikan kepercayaan yang wajar dalam mencapai nilai bisnis yang menarik dengan data terbatas yang dapat dikumpulkan lebih awal.

Setelah program didirikan, 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 bahwa organisasi membeli ke, dan menetapkan dasar terhadap yang kantor tata kelola program Anda kemudian dapat mengarahkan program dan mengukur prestasinya.

Memperbaiki ruang lingkup kasus bisnis terarah

Kasus bisnis terarah biasanya dirakit dengan cepat, dalam 2-4 minggu. Ini perlu menghasilkan kepercayaan yang cukup sehingga Anda dapat mengamankan sumber daya untuk membentuk tim inti, melibatkanAWS Mitra jika diperlukan, dan sebagai minimum, menyelesaikan penilaian aplikasi yang diprioritaskan dan analisis portofolio dan tahap perencanaan migrasi.

Biasanya, kasus bisnis terarah yang mendukung migrasi portofolio dibuat sebagai salah satu dari berikut ini:

• Perbandingan total biaya kepemilikan (TCO) sederhana antara lanskap infrastruktur apa adanya dan arsitekturAWS layanan pasca-migrasi. Perbandingan menunjukkan perbedaan dalam kecepatan lari yang diharapkan untuk volume beban kerja yang diberikan.

• Kasus bisnis yang menunjukkan nilai sekarang bersih (NPV), laba atas investasi (ROI), periode pengembalian, modifikasi tingkat pengembalian internal (MIRR) dan analisis arus kas 3-5 tahun untuk bermigrasi keAWS inklusif biaya migrasi vs tinggal apa adanya.

Lingkup kasus bisnis terarah biasanya terbatas pada salah satu dari berikut ini:

• Perbandingan biaya teknologi infrastruktur

• Perbandingan biaya teknologi infrastruktur dan operasi

Secara umum, semakin besar portofolionya, semakin sedikit perkembangan 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 lebih detail diperlukan.

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 positif pada pengurangan biaya infrastruktur saja dalam 3 tahun beroperasiAWS, atau 250 server dalam 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 diperoleh dari peningkatan ketahanan atau kelincahan bisnis, kecuali cakupan migrasi total kurang dari sekitar 5 beban kerja atau 50 server.

Driver nilai fokus

Perbandingan teknologi infrastruktur TCO membandingkan model biaya infrastruktur apa adanya dengan model dasar tagihanAWS layanan material yang dibutuhkan untuk menjalankan beban kerja Anda dengan kinerja dan ketersediaan yang setara. Banyak optimasi dapat dilakukan. Namun, pada tahap ini, fokusnya adalah pada daftar berikut karena mereka lebih mudah untuk menilai dan biasanya menghasilkan sekitar 30 persen penghematan TCO, yang cukup untuk bergerak maju:

• Elastisitas komputasi - 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, ke layanan sesuai permintaan yang ditagih hanya saat digunakan.

• Pengadaan dengan rencana tabungan - 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 CPU dan data deret waktu pemanfaatan memori untuk menilai setiap server daya komputasi dan memori yang dibutuhkan. Kemudian pilih instans Amazon Elastic Compute Cloud (Amazon EC2) agar sesuai.

• Sistem manajemen database relasional (RDBMS) lisensi ukuran kanan - Menilai kembali kebutuhan lisensi RDBMS Anda setelah menghitung ukuran kanan pada server database Anda, membandingkan Bring Your Own License (BYOL) dan Procuring lisensi dariAWS, dan mengeksplorasi potensi Amazon Relational Database Service (Amazon RDS) untuk meningkatkan penghematan.

• Penyimpanan — Ukuran kanan total volume penyimpanan yang dibutuhkan, dan identifikasi operasi input/output per detik (IOPS) yang dibutuhkan di seluruh portofolio. Tentukan berapa banyak yang dapat dipindahkan ke penyimpanan objek dengan SLA dan biaya yang berbeda.

Kebutuhan data

Tabel dalam Memahami persyaratan data penilaian awal 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, buat 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 sewa akan kedaluwarsa, pemetaan aplikasi tidak diperlukan untuk perbandingan infrastruktur TCO.

Data yang ditandai sebagai opsional (seperti CPU dan pemanfaatan puncak memori untuk server) biasanya dapat diganti dengan nilai benchmark standar. Anda dapatAWS mendiskusikannya dengan Mitra atau LayananAWS Profesional. Atau Anda dapat mengekstrapolasi nilai dari titik data yang tersedia di bagian portofolio Anda (seperti data yang dikumpulkan oleh hypervisor). Semakin besar portofolionya, semakin akurat hal ini.

Membangun perbandingan infrastruktur TCO

Alat sangat penting untuk membangun perbandingan TCO infrastruktur. AWS Layanan Profesional atau AWSMitra 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:

• Mengumpulkan data inventaris.

• Kumpulkan data pemanfaatan.

• Menyediakan data benchmarking biaya infrastruktur yang akurat.

• Mengidentifikasi dan menghapus zombie.

• Buat penilaian ukuran yang benar.

• Merekomendasikan opsi pembelian.

• Bandingkan opsi lisensi perangkat lunak.

• Menghasilkan analisis arus kas grafis sederhana.

Migrasi Evaluator dariAWS adalah salah satu pilihan. Ini menyediakan semua kemampuan ini sebagai layanan terkelola gratis. Anda dapat meminta Evaluator Migrasi melalui manajerAWS akun atau Mitra KompetensiAWS Migrasi atau dengan mengirimkan permintaan secara online. Migration Evaluator telah dirancang khusus sebagai solusi titik untuk menghasilkan perbandingan teknologi infrastruktur TCO dan cepat.

Keuntungan utama:

• Gratis

• 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 pengoperasian SaaS, tetapi dapat menjalankan pengumpulan data sepenuhnya dalam jaringan pelanggan untuk mendukung penggosokan sebelum memuat ke mesin analitik

• Dukungan kuat untuk ukuran hak lisensi Microsoft

• Kemampuan ekspor data lengkap

Keterbatasan utama:

• Hanya menilai server arsitektur x86 (Windows dan Linux)

• Opsi terbatas untuk mengonfigurasi atau mengkalibrasi tolok ukur sebagaimana adanya data biaya

• Tidak ada dukungan untuk optimasi 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 saling ketergantungan, biasanya akan memberikan perbandingan TCO infrastruktur juga. Untuk panduan tentang penggunaan alat untuk penemuan dan penilaian portofolio, lihat Mengevaluasi kebutuhan akan perkakas penemuan.

Membangun optimalisasi biaya operasional

Peningkatan produktivitas operasi TI seringkali merupakan kontributor nilai signifikan untuk migrasi. Rata-rata, setelah migrasi keAWS, produktivitas staf operasional TI meningkat sebesar 62 persen melalui migrasi, menurut whitepaper International Data Corporation (IDC) Membina Bisnis dan Transformasi Organisasi untuk Menghasilkan Nilai Bisnis dengan Amazon Web Services. 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 terperinci. Tantangan ini dapat diselesaikan dengan berfokus pada beberapa elemen yang lebih mudah dinilai dan berukuran dengan data benchmark sederhana tetapi masih menunjukkan keuntungan yang signifikan.

Kedua, berfokus pada produktivitas sebagai sumber pengurangan biaya dapat menimbulkan kepedulian dan negativitas di antara para 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 bagi tim.

• Manfaat dapat direalisasikan dengan rescoping dan mengubah ukuran kontrak outsourcing operasi, sehingga staf internal dapat meningkatkan fokus mereka pada kegiatan 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 jauh dari solusi operasi Anda saat ini keAWS Managed Services (AMS) atau ke layanan terkelola alternatif yang ditawarkan dariAWS Mitra.

Untuk transformasi pertama, untuk mendapatkan perkiraan keuangan konservatif dari peningkatan produktivitas yang dapat dimasukkan dalam kasus ini, kami merekomendasikan hal berikut:

1. Fokus pada produktivitas operasi manajemen server secara khusus. Ini cenderung merupakan proporsi yang signifikan dari upaya operasi, dapat lebih mudah dinilai, dan lebih mudah diverifikasi nanti.

2. Hitung kepegawaian yang dibutuhkan berdasarkan tolok ukur untuk jumlah server yang dapat dikelola oleh setiap karyawan setara penuh waktu (FTE). Di tempat, jumlah itu sekitar 150 severs. PadaAWS, itu sekitar 400 server.

3. Terapkan metrik ini ke jumlah server lokal dibandingkan dengan jumlah instans EC2.

4. Kalikan 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 keuntungan produktivitas rata-rata berdasarkan peran yang disediakan dalam tabel berikut (data yang bersumber dari whitepaper IDC Membina Bisnis dan Transformasi Organisasi untuk Menghasilkan Nilai Bisnis dengan Amazon Web Services.

Peran	Keuntungan Efisiensi
Manajemen infrastruktur TI	62%
Dukungan TI	59%
Manajemen aplikasi	43%
Pengelolaan database	19%
Pengembangan aplikasi	25%

Untuk transformasi kedua, Anda dapat menambahkan penghematan biaya operasional dengan membandingkan langsung total operasi saat ini dan biaya dukungan untuk portofolio dalam lingkup dengan biaya layanan terkelola yang dipertimbangkan.

Untuk mendapatkan biaya layanan terkelola, berikan manajerAWS akun Anda atau AWS Managed ServicesMitra mana punAWS Bill of Materials yang Anda usulkan, pilihan tingkat layanan Anda (Plus atau Premium), dan paket AMS Anda (AMS Accelerate atau AMS Advanced). Ini akan memberi Anda biaya total layanan terkelola untuk komponenAWS layanan dari solusi yang ditransformasikan. Demikian pula, Anda bisa mendapatkan harga dariAWS Mitra yang menawarkan paket layanan terkelolanya 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 memperkirakan semua biaya migrasi dan modernisasi. Kemudian membuat arus kas yang mencakup pasangan migrate-and-modernize dan don't-migrate-and-modernize skenario.

Kasus yang paling mendasar adalah persiapan sepasang skenario, di manat-migrate-and-modernize skenario don 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

• uality-of-service Kemampuan Q (seperti ketersediaan, daya tahan, throughput, dan kinerja) yang sesuai dengan kemampuan sistem yang ada

Untuk semua tetapi 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 sangat berharga untuk menambahkan pasangan migrate-and-modernize dant-migrate-and-modernize skenario yang menunjukkan aspek lain dari peningkatan nilai migrasi cloud, seperti:

• Campuran persyaratan pertumbuhan moderat dan berkapasitas tinggi di seluruh beban kerja di mana pertumbuhan itu diharapkan

• Dimasukkannya peningkatan ketahanan, seperti ketersediaan tinggi, DR, dan toleransi kesalahan

• Peningkatan kinerja global dengan komputasi tepi, jaringan pengiriman konten (CDN), replikasi database multi-wilayah.

• Setiap peningkatan kualitas layanan spesifik lainnya yang telah Anda jadikan prioritas bisnis untuk program ini

Untuk skenario ini, pastikan bahwa implikasi biaya dan 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 MitraAWS Konsultasi dengan Kompetensi Migrasi, yang dapat mendukung Anda dengant-migrate-and-modernize skenario migrate-and-modernize dan tidak.

Untuk setiap pasangan skenario, kumpulkan kasus yang terdiri dari yang berikut:

• Biayat-migrate-and-modernize skenario don '. Dalam kasus yang paling dasar, ini termasuk:

  • Total biaya kepemilikan atas jangka waktu kasus bisnis untuk konfigurasi infrastruktur saat ini

  • Peningkatan periodik dalam komputasi, penyimpanan, dan konsumsi lalu lintas jaringan

• Biaya migrate-and-modernize; skenario, termasuk:

  • Menyiapkan program, yang mencakup penemuan terperinci, perencanaan migrasi, pengembangan kasus bisnis terperinci, membangun tim inti dan meningkatkan keterampilan mereka, membangun landing zone jika belum ada, dan membangun manajemen keamanan dan integrasi operasi untuk beban kerja yang dimigrasi

  • Migrasi beban kerja dan biaya modernisasi

  • Biaya infrastruktur migrasi, termasuk koneksi jaringan, layanan migrasi data seperti AWSSnowball dan AWS DataSync, dan biayaAWS utilitas untuk arsitektur yang diperlukan selama proses migrasi itu sendiri (misalnya, untuk pengujian)

  • Peningkatan biayaAWS utilitas selama migrasi saat gelombang ditayangkan, dan jalan turun dari biaya infrastruktur yang ada karena digantikan oleh layananAWS 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 mencakup hal-hal berikut:

1. Melakukan penemuan portofolio terperinci, perencanaan migrasi, dan pengembangan kasus bisnis terperinci, seperti yang dijelaskan di bagian Analisis portofolio dan perencanaan migrasi, ditambah dengan mendokumentasikan biaya alat penemuan apa pun yang digunakan.

2. Membangun tim inti bisnis dan teknis cloud dan mengembangkan keterampilan internal melalui pelatihan dan perekrutan. Identifikasi anggota organisasi TI yang memerlukan pelatihan, dan alokasikan anggaran pelatihan untuk setiap orang.

3. Membangun landing zone dan mengonfigurasinya untuk mendukung kemampuan tata kelola biaya, operasional, dan keamanan yang Anda perlukan.

AWSMitra 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 tahap berikutnya, pertahankan estimasi biaya migrasi dan modernisasi sedasar mungkin.

Untuk tujuan ini, kami menyarankan Anda mempersiapkan kasus bisnis terarah dengan berfokus pada aplikasi yang termasuk dalam strategi migrasi berikut:

• Mundur

• Mempertahankan

• Merelokasi

• Rehost

• Replatform

• Pembelian kembali

Biasanya, sekitar 70 persen beban kerja dapat dihosting ulang, direlokasi atau direplatformed, 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 kerangka waktu yang diberikan untuk mempersiapkan kasus bisnis terarah. Seperti yang dibahas sebelumnya dalam Menentukan tipe R untuk migrasi, pertimbangkan untuk menggunakan strategi rehost, relokasi, atau replatform untuk tahap 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 dalamAWS lingkungan daripada yang tidak. Perkiraan untuk refactoring (re-architecting) aplikasi tertentu yang terbaik ditambahkan ketika kasus bisnis rinci disiapkan.

Memperkirakan upaya migrasi berdasarkan 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, baik itu tim aplikasi internal Anda, LayananAWS Profesional, atau organisasiAWS Mitra.

Untuk membantu membangun kasus directional, tabel berikut menyediakan rentang indikatif upaya untuk perawatan yang berbeda. Rentang ini mengasumsikan bahwa medium-to-large portofolio sedang dimigrasi dan bahwa 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
Retain	Do nothing, with no cost, no benefits, and no reduction in technology debt.	–	–	–
Retire	Estimate decommissioning the hardware equipment used, if any.	–	–	–
Relocate	Estimate copying the workload within VMware using VMware tools. This includes copying the data, smoke testing to verify, and any hardware decommissioning. The effort to relocate VMs is typically less than for low-complexity rehost patterns.	–	–	–
Rehost	Estimate copying the workload and data with an image copy, smoke testing, high availability (HA) and disaster recovery (DR) testing where appropriate for production servers, and any hardware decommissioning. The best practice is to use tools such as AWSLayanan Migrasi Aplikasi. Divide workloads into low, medium, and high complexity, based on factors such as whether a database or other infrastructure software is running, database complexity, whether clustered, integration complexity, and data volumes.	Effort per app per server	Migration	HA/DR test
		Low	10–14	3–5
		Medium	16–24	4–6
		High	26–38	8–12
Replatform	For replatform migrations that include upgrades to operating system or RDBMS version, take the estimate for a rehost, and add time to run a rebuild and smoke test on the new platform.If the replatform includes changing the technology of the platform, estimate additional time for the use of the conversion tools, such as AWS Schema Conversion Tool and AWS Database Migration Service, and a more complete application test. An example of changing the technology is migrating away from a proprietary commercial database to an open source replacement.	Effort per app per server	Version up	Technology change
		Low	Add 1–3	Add 10–15
		Medium	Add 2–5	Add 20–30
		High	Add 4–8	Add 40–60
Repurchase	Estimate data extraction, transformation, and uploading into the newly purchased SaaS service replacement, and any hardware decommissioning.	–	–	–

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 keAWS

• Anggaran untukAWS layanan (terutama komputasi dan penyimpanan) yang diperlukan untuk menampung beban kerja yang dimigrasi selama proses migrasi, pengujian, dan langsung

• Peningkatan biayaAWS 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 penggunaan jaringan. Jika Anda telah menyediakan AWS Direct Connecttautan atau AWS VPNdariAWS titik di WAN 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 pertukaranAWS media seperti AWSSnowball dan AWSSnowcone menawarkan solusi di sebagian besarAWS Wilayah. Juga, untuk migrasi data volume yang sangat tinggi, pertimbangkan termasuk anggaran untuk AWS DataSync, yang meningkatkan keandalan dan dapat mempercepat transfer terlepas dari media yang digunakan.

Pemodelan jalan naikAWS layanan dan jalan turun 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. Kami menyarankan sebagai berikut:

• Meningkatkan biaya untukAWS pada tingkat konstan atas migrasi.

• Kurangi biaya untuk infrastruktur yang ada yang Anda rencanakan untuk dinonaktifkan pada tingkat konstan selama durasi yang sama.

MulaiAWS biaya ramp naik 1-2 bulan sebelum infrastruktur yang ada jalan turun. Ini menyediakan 1 bulan penggunaanAWS utilitas untuk melakukan migrasi untuk setiap gelombang. Ini mencakup 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 digunakan kembali, dan membuangnya dengan cara yang legal dan ramah lingkungan, dapat menimbulkan beberapa biaya kecil. Namun, untuk kasus bisnis terarah, biasanya satu-satunya jumlah material yang berpotensi adalah biaya menulis dari nilai buku yang tersisa dari aset yang diganti.

Untuk kasus bisnis terarah, kami menyarankan Anda untuk melakukan hal berikut:

• Tinjau daftar aset Anda.

• Identifikasi yang akan dinonaktifkan.

• Untuk mengurangi penghapusan, periksa peluang untuk beralih perangkat di sekitar sehingga perangkat yang lebih baru dalam daftar dapat digunakan untuk mengganti aset yang lebih tua dan lebih disusutkan 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 mempersiapkan set lengkap biaya untuk setiap pasangan skenario, membangun laporan arus kas diskon untuk masing-masing dan grafik mereka. Kami merekomendasikan membangun kasus bisnis terarah selama periode yang sama dengan siklus penyegaran perangkat keras. Ini biasanya 5 tahun untuk server, penyimpanan, dan perangkat jaringan. Bila Anda menggunakan periode yang sama dengan siklus penyegaran perangkat keras, biaya persis satu penyegaran disertakan dalam biaya apa adanya untuk setiap skenario.

Kemudian hitung metrik keuangan utama yang Anda butuhkan untuk mendapatkan persetujuan untuk pindah ke tahap berikutnya dari program. Kami biasanya mencakup hal berikut:

• Nilai sekarang bersih (NPV) untuk mengukur nilai absolut dari pengurangan biaya dan keuntungan produktivitas dinilai

• Periode pengembalian dalam beberapa bulan untuk memverifikasi bahwa pengembalian cukup cepat

• Perbandingan run-rate akhir untuk memverifikasi apakah proses mengambil biaya yang cukup selama jangka waktu

• Pengembalian investasi (ROI) dan tingkat pengembalian investasi yang dimodifikasi (MIRR) untuk menilai kinerja keuangan relatif program atas tuntutan modal lain yang dapat diprioritaskan oleh organisasi Anda

Gunakan iterasi pertama dari kasus ini untuk menentukan apakah kinerja keuangan yang diharapkan berarti penyempurnaan harus dilakukan, seperti pada contoh berikut:

• Jika payback terlalu lambat, pertimbangkan opsi untuk mempercepat dan mengurangi biaya migrasi, seperti berikut ini:

  • GunakanAWS Mitra atau LayananAWS Profesional untuk memperluas sumber daya yang tersedia dan selanjutnya memparalelkan beban kerja migrasi dengan pola yang lebih mendasar.

  • Untuk beban kerja yang berjalan di VMware, bandingkan strategi relokasi ke 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 ruang lingkup kasus bisnis awal.

• Jika ROI dan MIRR terlalu rendah, pertimbangkan hal berikut:

  • Apakah skenario yang Anda pertimbangkan 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 untuk dimigrasi pada tahap pertama untuk fokus pada beban kerja yang akan menghasilkan pengembalian yang lebih kuat, seperti yang memiliki pemanfaatan arus lebih rendah atau kebutuhan pemulihan bencana (DR) yang mahal?

  • Dapatkah menyempurnakan cakupan 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 yang berikut:

  • Pertama, konfirmasikan bahwa metrik lain memenuhi harapan. Kasus bisnis terarah terutama untuk menunjukkan bahwa ada peluang keuangan yang cukup untuk membenarkan memulai fase berikutnya dari persiapan migrasi.

  • Identifikasi daftar peluang untuk terus meningkatkan kinerja biayaAWS 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.