Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Praktik terbaik untuk migrasi besar Migrasi besar dapat menjadi tantangan, tergantung pada faktor-faktor yang mengatur bagaimana suatu organisasi berfungsi. Bagian ini mencakup beberapa faktor kunci yang dapat menyederhanakan migrasi besar jika ditangani selama fase awal upaya dan dilacak di seluruh proyek. Praktik terbaik berikut untuk migrasi besar didasarkan pada data yang diambil dari pelanggan lain. Praktik terbaik dibagi menjadi tiga kategori: + Orang + Teknologi + Proses # Perspektif orang Bagian ini berfokus pada bidang-bidang utama berikut dari perspektif orang: + Dukungan eksekutif — Mengidentifikasi pemimpin berulir tunggal yang diberdayakan untuk membuat keputusan + Kolaborasi dan kepemilikan tim — Berkolaborasi di antara berbagai tim + Pelatihan — Tim pelatihan proaktif pada berbagai perkakas ## Dukungan eksekutif **Contents** + [Identifikasi pemimpin berulir tunggal](#leader) + [Sejajarkan tim kepemimpinan senior](#align-leadership) ### Identifikasi pemimpin berulir tunggal Saat memulai migrasi besar, penting untuk mengidentifikasi pemimpin teknis berulir tunggal yang 100 persen berdedikasi pada proyek dan bertanggung jawab. Pemimpin itu diberdayakan untuk membuat keputusan, membantu menghindari silo, dan merampingkan aliran kerja dengan mempertahankan prioritas yang konsisten. Pelanggan global migrasi besar dapat menskalakan dari satu server setiap minggu pada awal program ke lebih dari 80 server setiap minggu pada awal bulan kedua. Dukungan penuh CIO sebagai pemimpin single-threaded sangat penting untuk peningkatan pesat server yang dimigrasikan. CIO menghadiri panggilan cutover migrasi mingguan dengan tim migrasi untuk memastikan eskalasi real-time dan penyelesaian masalah, yang mempercepat kecepatan migrasi. ### Sejajarkan tim kepemimpinan senior Sangat penting untuk menciptakan keselarasan antara berbagai tim mengenai kriteria keberhasilan migrasi. Sementara perencanaan dan implementasi migrasi dapat dicapai oleh tim kecil yang berdedikasi, tantangan muncul ketika mendefinisikan strategi dan melakukan kegiatan periferal. Hambatan potensial ini mungkin memerlukan tindakan atau eskalasi dari berbagai bidang organisasi TI, termasuk yang berikut: + Bisnis + Aplikasi + Jaringan + Keamanan + Infrastruktur + Vendor pihak ketiga Tindakan langsung dari pemilik aplikasi, kepemimpinan, penyelarasan, dan eskalasi yang jelas ke pemimpin berulir tunggal menjadi penting. ## Kolaborasi dan kepemilikan tim **Contents** + [Membuat tim pemberdayaan cloud lintas fungsi](#cross-function) + [Tentukan persyaratan untuk tim dan individu di luar tim migrasi inti terlebih dahulu](#define-reqs) + [Validasi bahwa tidak ada masalah lisensi saat memigrasi beban kerja](#licensing) ### Membuat tim pemberdayaan cloud lintas fungsi **Contents** Langkah pertama yang penting dalam proyek migrasi besar adalah memungkinkan organisasi bekerja di cloud. Untuk mencapai hal ini, kami sarankan untuk membangun [Cloud Enablement Engine](https://d1.awsstatic.com/whitepapers/cloud-enablement-engine-practical-guide.pdf) (CEE). CEE adalah tim yang diberdayakan dan bertanggung jawab yang berfokus pada kesiapan operasional organisasi untuk migrasi ke. AWS CEE harus menjadi tim lintas fungsi yang mencakup representasi dari infrastruktur, aplikasi, operasi, dan keamanan. Tim ditugasi dengan tanggung jawab berikut: + Mengembangkan kebijakan + Mendefinisikan dan mengimplementasikan alat, proses, dan arsitektur yang akan membentuk model operasi cloud organisasi + Terus memfasilitasi penyelarasan pemangku kepentingan di semua area yang mereka wakili Satu pelanggan layanan kesehatan tidak memulai dengan CEE. Namun, melalui migrasi pilot awal, celah itu diidentifikasi. *Menjelang tanggal pemotongan migrasi terakhir, dengan tenggat waktu yang ketat, tim menerapkan ruang perang migrasi.* Di ruang perang migrasi, pemangku kepentingan dari infrastruktur, keamanan, aplikasi, dan bisnis dapat membantu menyelesaikan masalah. ### Tentukan persyaratan untuk tim dan individu di luar tim migrasi inti terlebih dahulu Identifikasi tim dan individu yang berada di luar program inti, dan tentukan keterlibatan mereka selama fase perencanaan migrasi. Untuk memfasilitasi momentum migrasi selama tahap selanjutnya, berikan perhatian khusus pada keterlibatan tim aplikasi. Pengetahuan mereka tentang aplikasi, kemampuan untuk mendiagnosis masalah, dan persyaratan untuk menandatangani cutover akan diperlukan. Meskipun migrasi akan dipimpin oleh tim inti, tim aplikasi kemungkinan akan terlibat dalam memvalidasi rencana migrasi dan pengujian selama pemotongan. Pelanggan sering mendekati migrasi cloud sebagai proyek infrastruktur, bukan sebagai migrasi aplikasi. Hal ini dapat menyebabkan masalah selama migrasi. Sebaiknya pertimbangkan keterlibatan tim aplikasi yang diperlukan saat memilih strategi migrasi. Misalnya, strategi rehost membutuhkan lebih sedikit keterlibatan tim aplikasi dibandingkan dengan strategi replatform atau refactor di mana lebih banyak lanskap aplikasi sedang diubah. Jika ketersediaan pemilik aplikasi terbatas, pertimbangkan untuk menggunakan rehost atau replatform sebagai lawan dari strategi refactor, relokasi, atau pembelian kembali. ### Validasi bahwa tidak ada masalah lisensi saat memigrasi beban kerja Perizinan dapat berubah saat Anda memigrasikan perusahaan secara off—produk yang tersedia ke cloud. Perjanjian lisensi Anda mungkin difokuskan pada properti lokal Anda. Misalnya, lisensi mungkin dengan CPU atau ditautkan ke alamat MAC tertentu. Atau, perjanjian lisensi mungkin tidak mencakup hak untuk menjadi tuan rumah di lingkungan cloud publik. Namun, negosiasi ulang lisensi dengan vendor dapat mencakup waktu tunggu yang lama dan menghadirkan hard blocker untuk migrasi. Sebaiknya berkolaborasi dengan tim manajemen sumber atau vendor Anda segera setelah ruang lingkup migrasi ditentukan. Perizinan juga dapat memengaruhi arsitektur target dan pola migrasi Anda. ## Pelatihan **Contents** + [Latih tim tentang perkakas dan proses baru](#tools-training) ### Latih tim tentang perkakas dan proses baru Setelah strategi migrasi ditentukan, investasikan waktu untuk memahami pelatihan apa yang mungkin diperlukan untuk migrasi dan untuk model operasi target Anda. Selama migrasi, Anda mungkin akan menggunakan tooling, seperti AWS Database Migration Service, yang baru untuk organisasi Anda. Tim pelatihan secara proaktif mengurangi penundaan yang dialami selama fase migrasi. Kami merekomendasikan mencari metode transfer pengetahuan aktif yang memberikan kesempatan untuk bereksperimen dengan perkakas secara langsung. Sebagai contoh, Layanan AWS Profesional menyediakan beberapa sesi pelatihan Cloud Migration Factory untuk tiga AWS Mitra integrator sistem (SI) yang bertanggung jawab atas migrasi besar. Ini memastikan bahwa tim memiliki keakraban dasar saat pindah ke fase migrasi. Ini juga membantu mengidentifikasi ahli materi pelajaran (SMEs) yang dapat berfungsi sebagai eskalasi lini pertama dalam setiap tim AWS Mitra SI. # Perspektif teknologi Teknologi memberikan fondasi yang bagus untuk mempercepat migrasi besar. Misalnya, solusi Cloud Migration Factory difokuskan pada cara menyediakan end-to-end otomatisasi untuk migrasi. Bagian ini mengeksplorasi beberapa praktik terbaik untuk menggunakan teknologi untuk mencapai skala dan kecepatan yang diperlukan, selaras dengan ruang lingkup, strategi, dan garis waktu. Prinsip menyeluruh adalah melihat area otomatisasi sedapat mungkin. Jika Anda memiliki ribuan server dalam ruang lingkup, melakukan tugas secara manual dapat menjadi upaya yang mahal dan memakan waktu. Untuk melakukan migrasi, beberapa alat biasanya digunakan, seperti berikut ini: + Penemuan + Implementasi migrasi + Database manajemen konfigurasi (CMDB) + Spreadsheet inventaris + Manajemen proyek Alat-alat ini digunakan pada berbagai tahap migrasi, mulai dari penilaian hingga mobilisasi hingga implementasi. Pemilihan alat-alat ini didorong oleh tujuan bisnis dan jadwal. Setelah fase migrasi direncanakan, langkah selanjutnya adalah memastikan bahwa tim migrasi memiliki keterampilan untuk menggunakan alat yang mereka butuhkan. Jika tim tidak memiliki keterampilan atau pengalaman, rencanakan pelatihan yang ditargetkan untuk meningkatkan keahlian. Jika memungkinkan, buat acara di mana tim bisa mendapatkan pengalaman dengan alat migrasi di lingkungan yang aman. Misalnya, apakah ada server sandpit atau lab yang dapat dimigrasikan oleh tim untuk mengalami perkakas? Atau, apakah beban kerja pengembangan awal dapat diterima untuk digunakan untuk tujuan pembelajaran? ## Integrasi otomatisasi, pelacakan, dan perkakas **Contents** + [Otomatiskan penemuan migrasi untuk mengurangi waktu yang dibutuhkan](#discovery) + [Otomatiskan tugas berulang](#repeating) + [Otomatiskan pelacakan dan pelaporan untuk mempercepat pengambilan keputusan](#decision) + [Jelajahi perkakas yang dapat memfasilitasi migrasi Anda](#tooling) ### Otomatiskan penemuan migrasi untuk mengurangi waktu yang dibutuhkan Sebagian besar program migrasi besar dimulai dengan memahami ruang lingkup migrasi (apa yang harus dimigrasikan) dan mengembangkan strategi (bagaimana hal itu akan dimigrasikan). Penemuan adalah aspek penting dari ini. Titik metadata yang diperlukan ditangkap untuk membentuk pohon keputusan strategi migrasi. Untuk memigrasikan beban kerja dengan cepat, Anda harus mengidentifikasi dan mengimpor metadata migrasi yang diperlukan ke dalam proses implementasi, seperti pabrik migrasi. Mekanisme yang sepenuhnya otomatis untuk mengekstrak, mengubah, memuat (ETL) metadata migrasi sangat mengurangi waktu dan tingkat upaya yang terlibat dalam proses penemuan. Satu pelanggan mengembangkan proses pengambilan data yang sepenuhnya otomatis untuk pabrik migrasi mereka. Rencana gelombang migrasi dengan semua metadata migrasi dihosting dan dipelihara dalam spreadsheet di Microsoft. SharePoint Ketika perubahan dilakukan pada sumber, AWS Lambda fungsi dimulai untuk memuat data ke pabrik migrasi tanpa intervensi manual. Proses pengambilan data otomatis ini membantu pelanggan mengurangi pekerjaan manual, meminimalkan kesalahan manusia, dan mempercepat kecepatan mereka. Mereka dapat memigrasikan lebih dari 1.000 server ke AWS. ### Otomatiskan tugas berulang Dalam fase implementasi migrasi, banyak proses kecil harus sering diulang. Saat menggunakan AWS Application Migration Service (MGN), misalnya, Anda harus menginstal agen di setiap server yang berada dalam lingkup migrasi. Membangun pabrik migrasi yang sesuai dengan kebutuhan bisnis dan teknis spesifik Anda adalah cara paling efektif untuk mencapai efisiensi dan kecepatan yang diperlukan untuk menghasilkan migrasi besar yang sukses. Pabrik migrasi menyediakan kerangka kerja integrasi dan orkestrasi yang menggunakan kumpulan data standar untuk mempercepat migrasi. Setelah semua tugas diidentifikasi, habiskan waktu untuk mengotomatiskan semua tugas manual yang dapat diotomatisasi bersama runbook preskriptif. Solusi [Cloud Migration Factory](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-factory-cloudendure/welcome.html) adalah contohnya. Cloud Migration Factory dirancang untuk menyediakan fondasi otomatisasi migrasi tempat Anda dapat mengotomatiskan aspek yang spesifik untuk organisasi Anda. Misalnya, Anda mungkin ingin memperbarui tanda di CMDB untuk menyoroti bahwa server lokal sekarang dapat dinonaktifkan. Dalam skenario ini, Anda dapat membuat otomatisasi yang melakukan tugas ini di akhir gelombang migrasi. Cloud Migration Factory memiliki penyimpanan metadata terpusat dengan semua gelombang, aplikasi, dan metadata server. Skrip otomatisasi dapat terhubung ke Cloud Migration Factory untuk mendapatkan daftar server dalam gelombang itu dan melakukan tindakan apa pun yang sesuai. Cloud Migration Factory mendukung [AWS Application Migration Service](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html). ### Otomatiskan pelacakan dan pelaporan untuk mempercepat pengambilan keputusan Sebaiknya buat dasbor pelaporan migrasi otomatis untuk melacak dan melaporkan data langsung, termasuk indikator kinerja utama (KPIs) untuk program. Proyek migrasi melibatkan pemangku kepentingan dari seluruh organisasi, termasuk yang berikut: + Tim aplikasi + Penguji + Tim penonaktifan + Arsitek + Tim infrastruktur + Kepemimpinan Untuk menjalankan peran mereka, para pemangku kepentingan ini membutuhkan data langsung. Misalnya, tim jaringan harus mengetahui gelombang migrasi yang akan datang untuk memahami dampak pada koneksi bersama antara sumber daya lokal dan AWS. Tim kepemimpinan ingin memahami seberapa banyak migrasi selesai. Memiliki umpan data langsung yang dapat diandalkan dan otomatis mencegah miskomunikasi dan memberikan dasar di mana keputusan dapat dibuat. Seorang pelanggan layanan kesehatan besar sedang bekerja menuju pintu keluar pusat data dengan tenggat waktu yang akan datang. Mengingat skala dan kompleksitasnya, sejumlah besar waktu awalnya dihabiskan untuk melacak dan mengkomunikasikan status migrasi antar pemangku kepentingan. Tim migrasi kemudian menggunakan [Amazon Quick Sight](https://docs.aws.amazon.com/quicksuite/latest/userguide/quick-bi.html) untuk membangun dasbor otomatis yang memvisualisasikan data, secara signifikan menyederhanakan pelacakan dan komunikasi sambil meningkatkan kecepatan migrasi. ### Jelajahi perkakas yang dapat memfasilitasi migrasi Anda Memilih alat yang tepat untuk migrasi Anda tidaklah mudah, terutama jika tidak ada seorang pun di organisasi Anda yang pernah mengelola migrasi besar sebelumnya. Sebaiknya luangkan waktu untuk memilih alat yang sesuai untuk mendukung migrasi. Eksplorasi ini mungkin melibatkan biaya lisensi, tetapi dapat memberikan manfaat biaya ketika Anda mempertimbangkan inisiatif yang lebih luas. Atau, Anda mungkin menemukan bahwa perkakas yang disematkan di organisasi Anda dapat memberikan hasil yang serupa. Misalnya, Anda mungkin sudah memiliki alat pemantauan kinerja aplikasi yang digunakan di seluruh perkebunan Anda, yang dapat memberikan informasi penemuan yang kaya. Seorang pelanggan teknologi awalnya enggan untuk menjalankan alat penemuan otomatis selama migrasi mereka karena kurangnya keakraban. Akibatnya, AWS Mitra SI harus menjalankan 510 jam rapat per aplikasi untuk menemukan estate secara manual, termasuk nama server, versi sistem operasi, dan dependensi. Diperkirakan bahwa jika alat penemuan telah digunakan, upaya penemuan bisa dikurangi lebih dari 1.000 jam. ## Prasyarat dan validasi pasca migrasi **Contents** + [Bangun landing zone selama fase pra-migrasi](#landing-zone) + [Garis besar kegiatan prasyarat](#outline) + [Menerapkan pemeriksaan pasca-migrasi untuk perbaikan berkelanjutan](#post-checks) ### Bangun landing zone selama fase pra-migrasi Kami merekomendasikan untuk membangun lingkungan AWS target, atau landing zone, sebelumnya, daripada membangun target virtual private cloud (VPCs) dan subnet selama gelombang migrasi. Membangun landing zone yang dirancang dengan baik merupakan prasyarat untuk migrasi. Landing zone harus mencakup pemantauan, tata kelola, operasional, dan kontrol keamanan. Membangun dan memvalidasi landing zone sebelum migrasi meminimalkan ketidakpastian yang datang dengan menjalankan beban kerja Anda di lingkungan baru. Dengan adanya landing zone, para pemangku kepentingan dapat fokus pada migrasi beban kerja tanpa mengkhawatirkan aspek yang dikelola di tingkat akun atau VPC. ### Garis besar kegiatan prasyarat Di samping landing zone, penting untuk menyelaraskan prasyarat teknis lainnya sebelum migrasi, terutama proses dengan lead time yang panjang. Misalnya, buat perubahan firewall yang diperlukan untuk memungkinkan data direplikasi dari tempat ke AWS lokasi. Mengkomunikasikan prasyarat teknis sejak dini membantu mempersiapkan dan mengalokasikan sumber daya yang dibutuhkan. Migrasi sering terhenti karena prasyarat belum terpenuhi. Hal ini tidak hanya berdampak pada gelombang migrasi yang sedang berlangsung, ini mungkin mendorong kembali tanggal semua migrasi masa depan saat masalah sedang diperbaiki. Sebuah perusahaan jasa keuangan dimaksudkan untuk melakukan migrasi massal ke AWS, dengan tujuan mengosongkan beberapa pusat data. Namun, bandwidth mereka tersedia antara lokal dan tidak AWS cukup untuk kecepatan yang mereka inginkan. Sayangnya, meningkatkan bandwidth membutuhkan koneksi baru dan memiliki lead time tiga bulan. Ini berarti bahwa kecepatan migrasi dibatasi selama tiga bulan pertama. ### Menerapkan pemeriksaan pasca-migrasi untuk perbaikan berkelanjutan Terakhir, ingatlah untuk menerapkan validasi pasca-migrasi seperti integrasi operasi, optimalisasi biaya, dan pemeriksaan tata kelola dan kepatuhan. Validasi pasca-migrasi mencakup penilaian beban kerja yang dimigrasi sebelumnya untuk mengungkap pelajaran teknis yang harus diterapkan pada gelombang masa depan. Selanjutnya, ini adalah peluang besar untuk menerapkan operasi pengendalian biaya. Misalnya, selama migrasi, Anda mungkin memutuskan untuk mencocokkan ukuran AWS instans dengan estat lokal untuk mengurangi kebutuhan pengujian kinerja. Sekarang pengujian tidak lagi berada di jalur kritis penutupan pusat data, Anda dapat menggunakan Amazon CloudWatch untuk menilai pemanfaatan instance dan menentukan apakah instance berukuran lebih kecil akan cocok. Untuk menggambarkan pentingnya fase ini, pelanggan teknologi besar melakukan migrasi besar tetapi awalnya tidak menyertakan validasi pasca-migrasi. Setelah memigrasikan lebih dari 100 server, mereka mengidentifikasi bahwa AWS Systems Manager Agen (Agen SSM) tidak dikonfigurasi dengan benar. Semua server yang sebelumnya dimigrasi harus diperbaiki, dan migrasi terhenti. Pelanggan juga mengidentifikasi bahwa instans sebesar lima kali perkiraan awal, sehingga mereka menerapkan pos pemeriksaan biaya pada akhir setiap gelombang migrasi. # Perspektif proses Proses membawa konsistensi tetapi mereka juga berkembang dan rentan terhadap perubahan karena setiap proyek unik. Saat Anda menjalankan proses berulang kali, Anda akan mengidentifikasi celah dan ruang untuk perbaikan yang dapat menambah manfaat besar saat Anda gagal, belajar, mengadopsi, dan mengulangi. Perubahan ini dapat mengarah pada ide atau inovasi baru yang dapat dimanfaatkan oleh proyek dan bisnis di masa depan, yang memberikan katalis untuk pertumbuhan yang membawa kualitas dan kepercayaan tim. Proses dalam migrasi dapat menjadi kompleks karena melintasi teknologi dan batas yang mungkin tidak terkait sebelumnya. Perspektif ini memberikan proses dan panduan tentang persyaratan khusus untuk migrasi besar. ## Mempersiapkan migrasi besar Anda Bagian berikut menguraikan prinsip-prinsip inti yang diperlukan untuk memastikan bahwa Anda memulai perjalanan migrasi Anda dengan arah yang jelas dan dukungan dari para pemangku kepentingan yang akan sangat penting untuk keberhasilannya. **Contents** + [Tentukan driver bisnis dan komunikasikan garis waktu, ruang lingkup, dan strategi](#bus-drivers) + [Tentukan jalur eskalasi yang jelas untuk membantu menghapus pemblokir](#escalation) + [Minimalkan perubahan yang tidak perlu](#change) + [Dokumentasikan end-to-end proses lebih awal](#end-to-end) + [Dokumen pola migrasi standar dan artefak](#artifacts) + [Menetapkan satu sumber kebenaran untuk metadata migrasi dan status](#metadata) ### Tentukan driver bisnis dan komunikasikan garis waktu, ruang lingkup, dan strategi Saat mendekati migrasi besar ke AWS, Anda akan segera menemukan bahwa ada banyak cara untuk memigrasikan server Anda. Sebagai contoh, Anda dapat melakukan hal berikut: + Rehost beban kerja menggunakan. [AWS Application Migration Service](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html) + Kontainerisasi aplikasi Anda dan host di Amazon [Elastic Container Service (Amazon ECS) atau platform container](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) terkelola [Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) (Amazon EKS). + Desain ulang beban kerja Anda menjadi aplikasi tanpa server sepenuhnya. Untuk menentukan jalur migrasi yang benar, penting untuk bekerja mundur dari driver bisnis Anda. Jika tujuan akhir Anda adalah untuk meningkatkan kelincahan bisnis, Anda mungkin menyukai dua pola kedua, yang melibatkan lebih banyak tingkat transformasi. Jika tujuan Anda adalah mengosongkan pusat data pada akhir tahun, Anda dapat memilih untuk menghosting ulang beban kerja karena kecepatan yang disediakan rehosting. Migrasi besar biasanya melibatkan berbagai pemangku kepentingan, termasuk yang berikut: + Pemilik aplikasi + Tim jaringan + Administrator basis data + Sponsor eksekutif Ini adalah kunci untuk mengidentifikasi driver bisnis migrasi dan memasukkan daftar itu dalam dokumen, seperti piagam proyek yang dapat diakses oleh anggota program migrasi. Selanjutnya, buat indikator kinerja utama (KPIs) yang selaras dengan hasil bisnis target Anda. Misalnya, satu pelanggan ingin memigrasikan 2.000 server dalam waktu 12 bulan untuk mencapai hasil bisnis target mereka dari mengosongkan pusat data mereka. Namun, tim keamanan mereka tidak selaras dengan tujuan ini. Hasilnya adalah beberapa bulan perdebatan teknis tentang apakah akan melewatkan tanggal penutupan pusat data tetapi memodernisasi aplikasi lebih lanjut atau untuk meng-host ulang pada awalnya untuk memungkinkan penutupan pusat data yang tepat waktu dan kemudian memodernisasi aplikasi. AWS ### Tentukan jalur eskalasi yang jelas untuk membantu menghapus pemblokir Program migrasi cloud besar biasanya melibatkan berbagai pemangku kepentingan. Lagi pula, Anda berpotensi mengubah aplikasi yang telah di-host di tempat selama beberapa dekade. Adalah umum bagi setiap pemangku kepentingan untuk memiliki prioritas yang saling bertentangan. Sementara semua prioritas mungkin mendorong nilai, program kemungkinan akan memiliki jumlah anggaran terbatas dan hasil target yang ditentukan. Mengelola berbagai pemangku kepentingan dan berfokus pada target hasil bisnis dapat menjadi tantangan. Tantangan ini diperparah ketika Anda mengalikannya dengan ratusan atau ribuan aplikasi yang berada dalam lingkup migrasi. Selanjutnya, para pemangku kepentingan kemungkinan melaporkan ke dalam tim kepemimpinan yang berbeda, yang memiliki prioritas lain. Dengan pemikiran ini, di samping mendokumentasikan dengan jelas hasil bisnis target, penting untuk menentukan matriks eskalasi yang jelas untuk membantu menghilangkan pemblokir. Ini dapat menghemat banyak waktu dan membantu menyelaraskan berbagai tim menuju tujuan bersama. Salah satu contoh yang menunjukkan hal ini adalah perusahaan jasa keuangan yang tujuannya adalah untuk mengosongkan pusat data utama mereka dalam waktu 12 bulan. Tidak ada mandat atau jalur eskalasi yang jelas, yang mengakibatkan para pemangku kepentingan menyusun jalur migrasi yang mereka inginkan, terlepas dari kendala waktu dan anggaran. Setelah eskalasi ke CIO, mandat yang jelas ditetapkan dan mekanisme disediakan untuk meminta keputusan yang diperlukan. ### Minimalkan perubahan yang tidak perlu Perubahan itu baik tetapi lebih banyak perubahan berarti lebih banyak risiko. Ketika kasus bisnis untuk migrasi besar disetujui, kemungkinan besar ada hasil bisnis target yang mendorong inisiatif ini, seperti mengosongkan pusat data pada tanggal tertentu. Meskipun umum bagi para teknolog untuk ingin menulis ulang semuanya untuk memanfaatkan AWS layanan sepenuhnya, ini mungkin bukan tujuan bisnis Anda. Satu pelanggan fokus pada migrasi dua tahun dari seluruh infrastruktur skala web perusahaan ke. AWS Mereka menciptakan aturan dua minggu sebagai mekanisme untuk mencegah tim aplikasi menghabiskan waktu berbulan-bulan menulis ulang aplikasi mereka. Dengan menggunakan aturan dua minggu, pelanggan dapat mempertahankan migrasi jangka panjang dengan irama yang konsisten ketika ratusan aplikasi harus dipindahkan selama periode beberapa tahun. Untuk informasi selengkapnya, lihat posting blog [Aturan Dua Minggu: Memfaktorkan Ulang Aplikasi Anda untuk Cloud dalam 10 Hari](https://aws.amazon.com/blogs/enterprise-strategy/the-two-week-rule-refactor-your-applications-for-the-cloud-in-10-days/). Kami merekomendasikan meminimalkan perubahan apa pun yang tidak sesuai dengan hasil bisnis. Sebaliknya, bangun mekanisme untuk mengelola perubahan tambahan ini dalam proyek masa depan. ### Dokumentasikan end-to-end proses lebih awal Dokumentasikan proses migrasi lengkap dan penugasan kepemilikan pada tahap awal program migrasi besar. Dokumentasi ini penting dalam mendidik semua pemangku kepentingan tentang bagaimana migrasi akan berjalan dan peran serta tanggung jawab mereka. Dokumentasi juga akan membantu Anda memahami di mana masalah mungkin terjadi dan untuk memberikan pembaruan dan iterasi proses saat Anda maju melalui migrasi. Selama pengembangan proyek migrasi, pastikan bahwa setiap proses yang ada dipahami dan bahwa titik integrasi dan dependensi didokumentasikan dengan jelas. Sertakan tempat-tempat di mana keterlibatan dengan pemilik proses eksternal akan diperlukan, termasuk permintaan perubahan, permintaan layanan, dukungan vendor, dan dukungan jaringan dan firewall. Setelah proses dipahami, kami merekomendasikan untuk mendokumentasikan kepemilikan dalam matriks yang bertanggung jawab, akuntabel, dikonsultasikan, diinformasikan (RACI) untuk melacak aktivitas yang berbeda. Untuk menyelesaikan proses, buat rencana hitung mundur dengan mengidentifikasi garis waktu yang terlibat dalam setiap langkah migrasi. Rencana hitung mundur umumnya bekerja mundur dari tanggal dan waktu pemotongan migrasi beban kerja. Pendekatan dokumentasi ini bekerja dengan baik untuk perusahaan peralatan rumah tangga multinasional yang bermigrasi dengan AWS sukses dalam waktu kurang dari setahun dan keluar dari empat pusat data. Mereka memiliki enam tim organisasi yang berbeda dan beberapa pihak ketiga yang terlibat, yang memperkenalkan overhead manajemen yang mengakibatkan back-and-forth keputusan dan keterlambatan implementasi. Tim Layanan AWS Profesional, bersama dengan pelanggan dan pihak ketiga mereka, mengidentifikasi proses utama untuk kegiatan migrasi dan mendokumentasikannya dengan pemilik masing-masing. Matriks RACI yang dihasilkan dibagikan dan disepakati oleh semua tim yang terlibat. Menggunakan matriks RACI dan matriks eskalasi, pelanggan mengurangi pemblokir dan masalah yang menciptakan penundaan. Mereka kemudian dapat keluar dari pusat data lebih cepat dari jadwal. Dalam contoh lain menggunakan RACI dan matriks eskalasi, perusahaan asuransi dapat keluar dari pusat data dalam waktu kurang dari 4 bulan. Pelanggan memahami dan menerapkan model tanggung jawab bersama, dan matriks RACI terperinci diikuti untuk melacak kemajuan setiap proses dan aktivitas selama migrasi. Akibatnya, pelanggan dapat bermigrasi lebih dari 350 server dalam 12 minggu pertama implementasi. ### Dokumen pola migrasi standar dan artefak Anggap ini sebagai membuat pemotong kue untuk implementasi. Referensi, dokumentasi, runbook, dan pola yang dapat digunakan kembali adalah kunci untuk skala. Jurnal ini adalah pengalaman, pembelajaran, jebakan, masalah, dan solusi yang dapat digunakan kembali dan dihindari oleh proyek migrasi masa depan, yang secara signifikan mempercepat migrasi. Pola dan artefak juga merupakan investasi yang akan membantu meningkatkan proses dan memandu proyek masa depan. Misalnya, satu pelanggan melakukan migrasi selama setahun di mana aplikasi dimigrasikan oleh tiga Mitra SI AWS yang berbeda. Pada tahap awal, setiap AWS Mitra menggunakan standar, runbook, dan artefak mereka sendiri. Ini menempatkan banyak tekanan pada tim pelanggan, karena informasi yang sama dapat disajikan kepada mereka dengan cara yang berbeda. Setelah sakit awal ini, pelanggan menetapkan kepemilikan pusat atas semua dokumentasi dan artefak untuk digunakan dalam migrasi, dengan proses untuk mengirimkan perubahan yang direkomendasikan. Aset-aset ini meliputi: + Proses migrasi standar dan daftar periksa + Gaya diagram jaringan dan standar format + Aplikasi standar arsitektur dan keamanan berdasarkan kekritisan bisnis Selain itu, perubahan pada salah satu dokumen dan standar ini dikirim ke semua tim dengan irama mingguan, dan setiap mitra diminta untuk mengkonfirmasi penerimaan dan kepatuhan terhadap perubahan apa pun. Ini sangat meningkatkan komunikasi dan konsistensi untuk proyek migrasi, dan ketika upaya migrasi besar yang terpisah di unit bisnis lain dimulai, tim itu dapat mengadopsi proses dan dokumen yang ada, sangat mempercepat keberhasilan mereka. ### Menetapkan satu sumber kebenaran untuk metadata migrasi dan status Ketika datang untuk merencanakan migrasi besar, membangun sumber kebenaran penting untuk menjaga berbagai tim selaras dan memungkinkan keputusan berbasis data. Ketika Anda memulai perjalanan ini, Anda mungkin menemukan banyak sumber data yang dapat Anda gunakan, seperti database manajemen konfigurasi (CMDB), alat pemantauan kinerja aplikasi, daftar inventaris, dan sebagainya. Atau, Anda mungkin menemukan bahwa ada beberapa sumber data dan Anda harus membuat mekanisme untuk menangkap data yang dibutuhkan. Misalnya, Anda mungkin perlu menggunakan alat penemuan untuk mengungkap informasi teknis, dan untuk mensurvei para pemimpin TI untuk mendapatkan informasi bisnis. Penting untuk menggabungkan berbagai sumber data ke dalam satu kumpulan data yang dapat Anda gunakan untuk migrasi. Anda kemudian dapat menggunakan satu sumber kebenaran untuk melacak migrasi selama implementasi. Misalnya, Anda dapat melacak server mana yang telah dimigrasi. Pelanggan jasa keuangan yang ingin memigrasikan semua beban kerja untuk AWS fokus pada perencanaan migrasi dengan kumpulan data yang telah disediakan. Dataset ini memiliki kesenjangan kunci, seperti kekritisan bisnis dan informasi ketergantungan, sehingga program memulai latihan penemuan. Dalam contoh lain, sebuah perusahaan di industri yang sama pindah ke implementasi gelombang migrasi berdasarkan out-of-date pemahaman tentang inventaris infrastruktur server mereka. Mereka dengan cepat mulai melihat jumlah migrasi berkurang karena datanya salah. Dalam hal ini, pemilik aplikasi tidak dipahami, yang berarti bahwa mereka tidak dapat menemukan penguji tepat waktu. Selain itu, data tidak selaras dengan penonaktifan yang telah diselesaikan oleh tim aplikasi mereka, sehingga server berjalan tanpa digunakan untuk tujuan bisnis. ## Menjalankan migrasi besar Anda Setelah Anda menetapkan hasil bisnis Anda dan mengkomunikasikan strategi kepada para pemangku kepentingan, Anda dapat beralih ke perencanaan bagaimana Anda mengukir ruang lingkup migrasi besar ke dalam peristiwa atau gelombang migrasi berkelanjutan. Contoh berikut memberikan panduan utama untuk membuat rencana gelombang. **Contents** + [Rencanakan gelombang migrasi sebelumnya untuk memastikan aliran yang stabil](#plan-waves) + [Pertahankan implementasi gelombang dan perencanaan gelombang sebagai proses dan tim yang terpisah](#separate) + [Mulai dari yang kecil untuk hasil yang bagus](#start-small) + [Minimalkan jumlah jendela cutover](#cutover-numbers) + [Gagal cepat, terapkan pengalaman, dan iterasi](#iterate) + [Jangan lupa retrospektif](#retrospective) ### Rencanakan gelombang migrasi sebelumnya untuk memastikan aliran yang stabil Merencanakan migrasi Anda adalah salah satu fase terpenting dari program ini. Ini berlaku dengan pepatah “jika Anda gagal merencanakan, Anda berencana untuk gagal.” Merencanakan gelombang migrasi sebelumnya memungkinkan proyek mengalir dengan cepat karena tim menjadi lebih proaktif terhadap situasi migrasi. Ini membantu skala proyek dengan lebih mudah, dan meningkatkan pengambilan keputusan dan peramalan karena tuntutan proyek meningkat dan menjadi kompleks. Perencanaan ke depan juga meningkatkan kemampuan tim untuk beradaptasi dengan perubahan. Misalnya, pelanggan layanan keuangan besar sedang mengerjakan program keluar pusat data. Awalnya, pelanggan merencanakan gelombang migrasi secara berurutan, menyelesaikan satu gelombang sebelum mulai merencanakan gelombang berikutnya. Pendekatan ini menghasilkan lebih sedikit waktu untuk mempersiapkan. Ketika para pemangku kepentingan diberitahu bahwa aplikasi mereka sedang dimigrasikan AWS, mereka masih memiliki beberapa langkah yang harus dilakukan sebelum memulai migrasi. Ini menambah penundaan yang signifikan pada program. Setelah pelanggan menyadari hal ini, mereka menerapkan aliran perencanaan migrasi yang holistik dan berfokus pada masa depan di mana gelombang migrasi direncanakan beberapa bulan sebelumnya. Ini memberikan pemberitahuan yang cukup bagi tim aplikasi untuk melakukan aktivitas pra-migrasi mereka seperti memberi tahu AWS Mitra, analisis lisensi, dan sebagainya. Mereka kemudian dapat menghapus tugas-tugas itu dari jalur kritis program. ### Pertahankan implementasi gelombang dan perencanaan gelombang sebagai proses dan tim yang terpisah Ketika tim perencanaan gelombang dan implementasi gelombang terpisah, kedua proses dapat bekerja secara paralel. Dengan komunikasi dan koordinasi, ini menghindari perlambatan migrasi karena tidak cukup server atau aplikasi yang siap untuk mencapai kecepatan yang diharapkan. Misalnya, tim migrasi mungkin perlu memigrasi 30 server setiap minggu, tetapi hanya 10 server yang siap dalam gelombang saat ini. Tantangan ini sering disebabkan oleh hal-hal berikut: + Tim implementasi migrasi tidak terlibat dalam perencanaan gelombang, dan data yang dikumpulkan dalam fase perencanaan gelombang tidak lengkap. Tim implementasi migrasi harus mengumpulkan lebih banyak data server sebelum memulai gelombang. + Implementasi migrasi dijadwalkan dimulai tepat setelah perencanaan gelombang, tanpa buffer di antaranya. Sangat penting untuk merencanakan gelombang sebelumnya, dan untuk membuat penyangga antara persiapan dan dimulainya implementasi gelombang. Penting juga untuk memastikan bahwa tim perencanaan gelombang dan tim migrasi bekerja sama untuk mengumpulkan data yang tepat dan menghindari pengerjaan ulang. ### Mulai dari yang kecil untuk hasil yang bagus Rencanakan untuk memulai dari yang kecil dan meningkatkan kecepatan migrasi dengan setiap gelombang berikutnya. Gelombang awal harus berupa aplikasi tunggal, kecil, kurang dari 10 server. Tambahkan aplikasi dan server tambahan di gelombang berikutnya, bangun hingga kecepatan migrasi penuh Anda. Memprioritaskan aplikasi yang kurang kompleks atau berisiko, dan meningkatkan kecepatan pada jadwal, memberi tim waktu untuk menyesuaikan diri untuk bekerja sama dan mempelajari prosesnya. Selain itu, tim dapat mengidentifikasi dan menerapkan perbaikan proses dengan setiap gelombang, yang secara substansional dapat meningkatkan kecepatan gelombang selanjutnya. Satu pelanggan bermigrasi lebih dari 1.300 server dalam setahun. Dengan memulai dengan migrasi pilot dan beberapa gelombang yang lebih kecil, tim migrasi dapat mengidentifikasi berbagai cara untuk meningkatkan migrasi di kemudian hari. Misalnya, mereka mengidentifikasi segmen jaringan pusat data baru sebelumnya. Mereka bekerja dengan tim firewall mereka di awal proses untuk menerapkan aturan firewall yang memungkinkan komunikasi dengan alat migrasi. Ini membantu mencegah penundaan yang tidak perlu dalam gelombang future. Selain itu, tim dapat mengembangkan skrip untuk membantu mengotomatiskan lebih banyak penemuan dan proses pemotongan mereka dengan setiap gelombang. Memulai dari yang kecil membantu tim fokus pada perbaikan proses awal, dan sangat meningkatkan kepercayaan diri mereka. ### Minimalkan jumlah jendela cutover Migrasi massal membutuhkan pendekatan disiplin untuk mendorong skala. Menjadi terlalu fleksibel di beberapa daerah adalah anti-pola untuk migrasi besar. Dengan membatasi jumlah jendela cutover mingguan, waktu yang dihabiskan untuk aktivitas cutover memiliki nilai yang lebih tinggi. Misalnya, jika jendela cutover terlalu fleksibel, Anda bisa berakhir dengan 20 cutover dengan lima server masing-masing. Sebagai gantinya, Anda dapat memiliki dua cutover dengan masing-masing 50 server. Karena waktu dan upaya untuk setiap cutover serupa, memiliki pemotongan yang lebih sedikit dan lebih besar mengurangi beban operasional penjadwalan, dan membatasi penundaan yang tidak perlu. Sebuah perusahaan teknologi besar mencoba untuk bermigrasi dari beberapa pusat data yang disewa sebelum kontrak berakhir. Kehilangan kedaluwarsa akan menghasilkan persyaratan pembaruan jangka pendek yang mahal. Sebelumnya dalam migrasi, tim aplikasi diizinkan untuk mendikte jadwal migrasi hingga menit terakhir, termasuk memilih keluar dari migrasi karena alasan apa pun hanya beberapa hari sebelum pemotongan. Hal ini menyebabkan banyak penundaan pada tahap awal proyek. Seringkali, pelanggan harus bernegosiasi dengan tim aplikasi lain pada menit terakhir untuk mengisi. Pelanggan akhirnya meningkatkan disiplin perencanaan mereka, tetapi kesalahan awal ini menyebabkan stres terus-menerus bagi tim migrasi. Penundaan jadwal keseluruhan mengakibatkan beberapa aplikasi tidak berhasil keluar dari pusat data tepat waktu. ### Gagal cepat, terapkan pengalaman, dan iterasi Setiap migrasi pada awalnya memiliki jebakan. Gagal lebih awal membantu tim belajar, memahami kemacetan, dan menerapkan pelajaran yang dipetik ke gelombang yang lebih besar. Diharapkan bahwa beberapa gelombang pertama dalam migrasi akan lambat karena alasan berikut: + Anggota tim menyesuaikan satu sama lain dan prosesnya. + Migrasi besar biasanya melibatkan banyak alat dan orang yang berbeda. + Butuh waktu untuk mengintegrasikan, menguji, gagal, belajar, dan terus meningkatkan end-to-end proses. Masalah umum dan diharapkan selama beberapa gelombang pertama. Penting untuk memahami dan mengomunikasikan hal ini kepada seluruh organisasi, karena beberapa tim mungkin tidak suka mencoba hal-hal baru dan gagal. Kegagalan dapat mengecilkan hati tim dan menjadi pemblokir untuk migrasi masa depan. Memastikan semua orang memahami bahwa masalah awal adalah bagian dari pekerjaan dan mendorong semua orang untuk mencoba dan gagal adalah kunci keberhasilan migrasi. Satu perusahaan berencana untuk bermigrasi lebih dari 10.000 server dalam 24-36 bulan. Untuk mencapai tujuan itu, mereka perlu memigrasi hampir 300 server sebulan. Namun, itu tidak berarti mereka memigrasikan 300 server sejak hari pertama. Gelombang pasangan pertama adalah gelombang belajar sehingga tim dapat memahami bagaimana segala sesuatunya bekerja dan siapa yang memiliki izin untuk melakukan apa. Mereka juga mengidentifikasi integrasi yang akan meningkatkan proses, seperti mengintegrasikan dengan CMDB dan. CyberArk Mereka menggunakan gelombang pembelajaran untuk gagal, meningkatkan, dan gagal lagi, menyempurnakan proses dan otomatisasi. Setelah 6 bulan, mereka dapat bermigrasi lebih dari 120 server setiap minggu. ### Jangan lupa retrospektif Ini adalah bagian penting dari proses gesit. Di sinilah tim berkomunikasi, menyesuaikan, belajar, setuju, dan bergerak maju. Retrospektif pada tingkat paling dasar adalah melihat ke belakang, mendiskusikan apa yang terjadi, menentukan apa yang berjalan dengan baik dan apa yang perlu ditingkatkan. Perbaikan kemudian dapat dibangun berdasarkan diskusi tersebut. Retrospektif membungkus beberapa formalitas atau proses di sekitar gagasan pelajaran yang dipelajari. Retrospektif penting karena untuk mencapai skala dan kecepatan agar migrasi besar berhasil, proses, alat, dan tim harus terus berkembang dan meningkat. Retrospektif dapat memainkan peran penting dalam hal itu. Sesi pelajaran tradisional tidak terjadi sampai akhir program, sehingga seringkali pelajaran ini tidak ditinjau pada awal gelombang migrasi berikutnya. Dengan migrasi besar, pelajaran yang dipetik harus diterapkan pada gelombang berikutnya dan harus menjadi bagian penting dari proses perencanaan gelombang. Untuk satu pelanggan, retrospektif mingguan diadakan untuk mendiskusikan dan mendokumentasikan pelajaran yang dipetik dari pemotongan. Dalam sesi ini, mereka menemukan area di mana ada ruang untuk merampingkan dari sudut pandang proses atau otomatisasi. Hal ini mengakibatkan implementasi jadwal hitung mundur dengan aktivitas tertentu, pemilik, dan skrip otomatisasi untuk meminimalkan tugas manual, termasuk validasi alat pihak ketiga dan instalasi CloudWatch agen Amazon, selama pemotongan. Di perusahaan teknologi besar lainnya, retrospektif reguler diadakan dengan tim untuk mengidentifikasi masalah dengan gelombang migrasi sebelumnya. Ini menghasilkan peningkatan proses, skrip, dan otomatisasi yang mendorong waktu migrasi rata-rata turun sebesar 40 persen selama program berlangsung. ## Pertimbangan tambahan Banyak daerah harus diperhitungkan dalam program migrasi besar. Bagian berikut memberikan pemikiran tentang item lain yang harus dipertimbangkan. **Contents** + [Bersihkan saat Anda pergi](#clean-up) + [Menerapkan beberapa fase untuk setiap transformasi tambahan](#phases) ### Bersihkan saat Anda pergi Migrasi tidak dianggap berhasil jika biayanya 10 kali lipat dari yang Anda harapkan, dan proyek tidak selesai sampai sumber daya yang digunakan untuk migrasi ditutup dan dibersihkan. Pembersihan ini harus menjadi bagian dari kegiatan pasca-migrasi. Ini memastikan bahwa Anda tidak akan meninggalkan sumber daya dan layanan yang tidak terpakai di lingkungan Anda yang akan menambah biaya. Pembersihan pasca-migrasi juga merupakan praktik keamanan yang baik untuk mencegah ancaman dan kerentanan yang mengekspos lingkungan Anda. Dua hasil utama dari pindah ke AWS Cloud adalah penghematan biaya dan keamanan. Meninggalkan sumber daya yang tidak terpakai dapat mengalahkan tujuan bisnis pindah ke cloud. Sumber daya paling umum yang tidak dibersihkan meliputi: + Data uji + Database uji + Akun uji, termasuk aturan firewall, grup keamanan, dan alamat IP daftar kontrol akses jaringan (ACL jaringan) + Port disediakan untuk pengujian + Volume Amazon Elastic Block Store (Amazon EBS) + Snapshot + Replikasi (seperti menghentikan replikasi data dari lokal ke lokasi) AWS + File yang menggunakan ruang (seperti backup database sementara yang digunakan untuk bermigrasi) + Contoh yang menghosting alat migrasi Dalam salah satu contoh praktik pembersihan yang buruk, AWS Mitra SI tidak menghapus agen replikasi setelah migrasi berhasil. AWS Audit menemukan bahwa server replikasi dan volume EBS yang telah dimigrasi menelan biaya \$120.000 (USD) setiap bulan. Untuk mengurangi masalah ini, Layanan AWS Profesional membuat proses audit otomatis yang memberi tahu AWS Mitra SI ketika server basi masih direplikasi. AWS Mitra SI kemudian dapat mengambil tindakan pada contoh yang tidak digunakan dan basi. Untuk migrasi masa depan, sebuah proses diadopsi untuk menentukan periode hypercare pasca-migrasi 48 jam untuk memastikan adopsi platform yang lancar. Tim infrastruktur pelanggan kemudian mengajukan permintaan penonaktifan untuk server lokal. Disarankan bahwa setelah persetujuan permintaan penonaktifan, server dari gelombang masing-masing akan dihapus dari konsol layanan migrasi aplikasi. ### Menerapkan beberapa fase untuk setiap transformasi tambahan Saat melakukan migrasi besar, penting untuk tetap fokus pada tujuan inti Anda, seperti penutupan pusat data atau transformasi infrastruktur. Dalam migrasi yang lebih kecil, scope creep mungkin memiliki dampak minimal. Namun, beberapa hari upaya tambahan dikalikan dengan potensi ribuan server dapat menambah sejumlah besar waktu untuk program. Selain itu, perubahan tambahan mungkin juga memerlukan pembaruan dokumentasi, proses, dan pelatihan untuk tim dukungan. Untuk mengatasi potensi cakupan creep, Anda dapat menerapkan pendekatan multi-fase untuk migrasi Anda. Misalnya, jika tujuan Anda adalah untuk mengosongkan pusat data, fase 1 mungkin hanya mencakup rehosting beban kerja AWS secepat mungkin. Setelah beban kerja di-rehost, fase 2 dapat mengimplementasikan aktivitas transformasional tanpa mempertaruhkan hasil bisnis target. Misalnya, satu pelanggan berencana untuk keluar dari pusat data mereka dalam 12 bulan. Namun, migrasi mereka mencakup aktivitas transformasi lainnya, seperti meluncurkan alat pemantauan kinerja aplikasi baru dan meningkatkan sistem operasi. Lebih dari 1.000 server berada dalam lingkup migrasi, sehingga aktivitas ini menambahkan penundaan signifikan pada migrasi. Selanjutnya, pendekatan ini membutuhkan pelatihan dalam penggunaan perkakas baru. Pelanggan kemudian memutuskan untuk menerapkan pendekatan multi-fase dengan fokus awal pada rehost. Ini meningkatkan kecepatan migrasi mereka dan mengurangi risiko tidak memenuhi tanggal penutupan pusat data.