Memigrasikan aplikasi WebSphere ke Azure Virtual Machines

  • Artikel

Panduan ini menjelaskan apa yang harus Anda ketahui ketika Anda ingin memigrasikan aplikasi tradisional WebSphere Application Server (WAS) yang ada untuk dijalankan di Azure Virtual Machines. Untuk gambaran umum solusi tradisional WAS yang tersedia di Marketplace Azure, lihat Apa solusi untuk menjalankan kumpulan produk IBM WebSphere di Azure?

Pra-migrasi

Untuk memastikan keberhasilan migrasi, sebelum memulai, selesaikan langkah-langkah penilaian dan inventaris yang dijelaskan di bagian berikut.

Menentukan yang dimaksud dengan "migrasi selesai"

Panduan ini, dan penawaran Marketplace Azure yang sesuai, adalah titik awal untuk mempercepat migrasi beban kerja tradisional WAS Anda ke Azure. Penting untuk menentukan cakupan upaya migrasi Anda. Misalnya, apakah Anda melakukan "pengangkatan dan pergeseran" yang ketat dari infrastruktur yang ada ke Azure Virtual Machines? Jika demikian, Anda mungkin tergoda untuk mengupayakan "pengangkatan dan peningkatan" saat bermigrasi.

Lebih baik tetap sedekat mungkin dengan "pengangkatan dan pergeseran" murni, memperhitungkan perubahan yang diperlukan sebagaimana diperinci dalam panduan ini. Tentukan apa yang Anda maksud dengan "migrasi selesai" sehingga Anda tahu kapan Anda telah mencapai milestone ini. Setelah mencapai "migrasi selesai", Anda dapat mengambil rekam jepret Komputer Virtual seperti yang dijelaskan dalam Membuat rekam jepret hard disk virtual. Setelah memverifikasi bahwa Anda dapat berhasil memulihkan dari rekam jepret, Anda dapat melakukan peningkatan tanpa takut kehilangan kemajuan migrasi yang telah Anda capai sejauh ini.

Pastikan target adalah target yang sesuai untuk upaya migrasi Anda

Langkah pertama dalam migrasi aplikasi WAS yang berhasil ke Azure adalah memilih target migrasi yang paling tepat.

WAS tradisional berjalan dengan baik di Azure Virtual Machines. Target komputer virtual (VM) adalah pilihan termampu, karena paling mirip dengan penyebaran lokal. Pengalaman administratif dan penyebaran untuk komputer virtual dianalogikan dengan apa yang Anda miliki di tempat.

Opsi lain adalah bermigrasi ke kontainer dengan mengonversi beban kerja tradisional WAS ke kontainer aplikasi. Anda dapat menjalankan target kontainer pada Azure Kubernetes Service (AKS) dan Azure Red Hat OpenShift. Trade-off untuk kemudahan ini adalah biaya ekonomi.

Secara umum, biaya per menit untuk solusi berbasis VM lebih tinggi dibandingkan dengan kontainer. Meskipun solusi berbasis kontainer lebih murah untuk dijalankan, Anda harus membatasi aplikasi Anda agar sesuai dengan persyaratan platform orkestrasi kontainer.

Jika meminimalkan perubahan adalah faktor terpenting untuk upaya migrasi Anda, pertimbangkan migrasi berbasis VM. Dalam hal ini, lihat Memigrasikan aplikasi WebSphere ke Azure Virtual Machines.

Jika Anda dapat mentolerir konversi aplikasi anda untuk berjalan dalam kontainer untuk mengurangi biaya runtime, pertimbangkan migrasi berbasis AKS atau berbasis Azure Red Hat OpenShift.

Untuk migrasi berbasis AKS, Anda dapat mulai menggunakan tingkat Gratis. Dapatkan manajemen kluster gratis dan bayar hanya untuk komputer virtual, penyimpanan terkait, dan sumber daya jaringan yang digunakan. Dalam hal ini, lihat Memigrasikan aplikasi WebSphere ke Azure Kubernetes Service.

Untuk migrasi berbasis Azure Red Hat OpenShift, selain biaya komputasi dan infrastruktur, simpul aplikasi memiliki biaya lain untuk komponen lisensi OpenShift. Biaya ini ditagih berdasarkan jumlah simpul aplikasi dan jenis instans. Gunakan harga sesuai permintaan atau instans yang dipesan, mana pun yang paling sesuai dengan kebutuhan beban kerja dan bisnis Anda. Dalam hal ini, lihat Memigrasikan aplikasi WebSphere ke Azure Red Hat OpenShift.

Panduan cara penggunaan dalam dokumentasi Azure Red Hat OpenShift mencakup beberapa aspek yang relevan dengan migrasi. Untuk daftar lengkap panduan cara penggunaan, lihat dokumentasi Azure Red Hat OpenShift.

Tentukan apakah penawaran Marketplace Azure bawaan adalah titik awal yang baik

IBM dan Microsoft telah bermitra untuk membawa serangkaian templat solusi Azure ke Marketplace Azure untuk menyediakan titik awal yang solid untuk bermigrasi ke Azure. Untuk daftar penawaran, lihat Menjalankan keluarga produk WebSphere dan Liberty di Microsoft Azure, lalu pilih salah satu yang paling cocok dengan penyebaran Anda yang ada. Anda dapat melihat daftar penawaran di artikel gambaran umum Apa solusi untuk menjalankan keluarga produk IBM WebSphere di Azure?

Jika tidak ada penawaran yang ada yang merupakan titik awal yang baik, Anda harus mereproduksi penyebaran dengan tangan menggunakan sumber daya Azure Virtual Machine. Anda dapat menemukan panduan langkah demi langkah dalam Tutorial: Menginstal Penyebaran Jaringan Server Aplikasi IBM WebSphere secara manual tradisional di Azure Virtual Machines. Untuk informasi selengkapnya, lihat Apa itu IaaS?

Menentukan apakah versi tradisional WAS kompatibel

Versi tradisional WAS yang ada harus kompatibel dengan versi dalam penawaran IaaS. Anda dapat menemukan informasi versi dari halaman gambaran umum Instans Tunggal Server Aplikasi IBM WebSphere di Azure VM dan Kluster Server Aplikasi IBM WebSphere di Azure VM. Jika versi tradisional WAS yang ada tidak kompatibel dengan versi tersebut, Anda harus mereproduksi penyebaran dengan tangan menggunakan sumber daya Azure IaaS. Untuk informasi selengkapnya, lihat Apa itu IaaS?

Kapasitas server inventaris

Dokumentasikan perangkat keras (memori, CPU, disk) dari server produksi saat ini serta jumlah permintaan rata-rata dan puncak, juga pemanfaatan sumber daya. Informasi ini harus menginformasikan pilihan ukuran VM. Untuk informasi selengkapnya, lihat Ukuran untuk Cloud Services.

Inventaris semua rahasia

Sebelum muncul teknologi "konfigurasi sebagai layanan" seperti Azure Key Vault, tidak ada konsep "rahasia" yang terdefinisi dengan baik. Sebaliknya, Anda memiliki serangkaian pengaturan konfigurasi yang berbeda yang secara efektif berfungsi sebagai apa yang sekarang kita sebut "rahasia". Dengan server aplikasi seperti WAS, rahasia ini berada di banyak file konfigurasi dan penyimpanan konfigurasi yang berbeda. Periksa semua properti dan file konfigurasi di server produksi untuk rahasia dan kata sandi apa pun. File konfigurasi yang berisi kata sandi atau kredensial juga dapat ditemukan di dalam aplikasi Anda. WAS menyimpan data konfigurasi dalam beberapa dokumen dalam hierarki direktori berjenjang. Sebagian besar dokumen konfigurasi memiliki konten XML. Untuk informasi selengkapnya, lihat Dokumen konfigurasi dan konsep dasar Azure Key Vault.

Inventaris semua sertifikat

Dokumentasikan semua sertifikat yang digunakan untuk titik akhir SSL publik. Anda bisa melihat semua sertifikat di server produksi dengan menjalankan perintah berikut ini:

keytool -list -v -keystore <path to keystore>

Untuk informasi selengkapnya, lihat dokumen IBM Manajemen sertifikat di SSL

Memvalidasi bahwa versi Java yang didukung berfungsi dengan benar

Menggunakan WAS di Azure Virtual Machines memerlukan versi Java tertentu, jadi Anda perlu mengonfirmasi bahwa aplikasi Anda berjalan dengan benar menggunakan versi yang didukung tersebut.

IBM Java 8 hadir dengan distribusi WAS9. Sebaiknya gunakan Java JRE yang disediakan IBM. Untuk informasi selengkapnya, lihat Java SE 8 di WebSphere Application Server V9 tradisional.

Jika Anda ingin beralih ke Java SDK yang berbeda, ikuti dokumen IBM Mengalihkan Java SDK di WebSphere Application Server.

Inventaris sumber daya JNDI

Inventarisasikan semua sumber daya JNDI. Misalnya, sumber data seperti database mungkin memiliki nama JNDI terkait yang memungkinkan JPA untuk mengikat instans dengan benar EntityManager ke database tertentu. Untuk informasi selengkapnya tentang sumber daya dan database JNDI, lihat Sumber Data WebSphere dalam dokumentasi IBM. Sumber daya terkait JNDI lainnya, seperti perantara pesan JMS, mungkin memerlukan migrasi atau konfigurasi ulang. Untuk informasi selengkapnya tentang konfigurasi JMS, lihat Menggunakan sumber daya JMS.

Memeriksa konfigurasi profil Anda

Unit konfigurasi utama di WAS adalah profil. Dengan demikian, file resources.xml berisi banyak konfigurasi yang harus Anda pertimbangkan dengan cermat untuk migrasi. File menyertakan referensi ke lebih banyak file XML yang disimpan dalam subdirektori. IBM menyarankan agar Anda biasanya menggunakan Konsol IBM untuk mengonfigurasi objek dan layanan WAS yang dapat dikelola, dan mengizinkan WAS untuk mempertahankan folder profil/nama profil. Untuk informasi selengkapnya, lihat Mengelola profil pada sistem operasi terdistribusi dan IBM i.

Di dalam aplikasi Anda

Periksa file deployment.xml dan/atau file WEB-INF/web.xml.

Menentukan apakah replikasi sesi digunakan

Jika aplikasi Anda bergantung pada replikasi sesi, Anda memiliki opsi berikut:

  • Untuk sesi HTTP, sesuai dengan tingkat manajemen sesi, Anda dapat menggunakan memori atau database untuk mengumpulkan data sesi.
  • Untuk Sesi terdistribusi, Anda dapat menyimpan sesi dalam database menggunakan persistensi sesi database.
  • Untuk Cache dinamis, Anda dapat mengelola data sesi dalam replikasi memori-ke-memori atau database.
  • Refaktor aplikasi Anda untuk menggunakan database untuk manajemen sesi.
  • Refaktor aplikasi Anda untuk mengeksternalisasi sesi ke Azure Redis Service. Untuk informasi selengkapnya, lihat Azure Cache for Redis.

Untuk semua opsi ini, ada baiknya untuk menguasai bagaimana WAS melakukan Replikasi Status Sesi HTTP. Untuk informasi selengkapnya, lihat Mengelola kacang sesi dalam dokumentasi IBM.

Mendokumentasikan sumber data

Jika aplikasi Anda menggunakan database apa pun, Anda perlu mengambil informasi berikut:

  • Apa nama sumber datanya?
  • Apa konfigurasi kumpulan koneksinya?
  • Di mana saya dapat menemukan file JAR driver JDBC?

Untuk informasi selengkapnya tentang driver JDBC di WAS, lihat Menggunakan Driver JDBC dengan Server Aplikasi WebSphere.

Menentukan apakah WAS telah disesuaikan

Tentukan kustomisasi mana yang telah dibuat, dan tangkap apa yang telah dilakukan.

  • Apakah skrip penyalaan telah diubah? Skrip tersebut termasuk wsadmin, AdminControl, AdminConfig, AdminApp, dan AdminTask.
  • Apakah ada parameter khusus yang diteruskan ke JVM?
  • Apakah ada JAR yang ditambahkan ke classpath server?
  • Apakah fasilitas tingkat OS seperti systemd telah digunakan untuk menyebabkan komponen WAS dimulai secara otomatis setelah server dimulai ulang?

Anda perlu memperhitungkan pertimbangan migrasi tergantung pada jawaban atas pertanyaan-pertanyaan ini.

Menentukan apakah koneksi ke lokal diperlukan

Jika aplikasi Anda perlu mengakses salah satu layanan lokal Anda, Anda harus menyediakan salah satu layanan konektivitas Azure. Untuk informasi selengkapnya, lihat Memilih solusi untuk menyambungkan jaringan lokal ke Azure. Atau, Anda harus memfaktor ulang aplikasi untuk menggunakan API yang tersedia untuk umum yang diekspos sumber daya lokal Anda.

Menentukan apakah Antrean atau Topik Java Message Service (JMS) sedang digunakan

Jika aplikasi Anda menggunakan Antrean atau Topik JMS, Anda perlu memigrasikannya ke server JMS yang dihosting secara eksternal. Salah satu strategi bagi mereka yang menggunakan JMS adalah menggunakan Azure Bus Layanan dan Advanced Message Queuing Protocol. Untuk informasi selengkapnya, lihat Menggunakan JMS dengan Azure Service Bus dan AMQP 1.0.

Jika Anda telah mengonfigurasi penyimpanan persisten JMS, Anda harus mengambil konfigurasinya dan menerapkannya setelah migrasi.

Jika Anda menggunakan IBM MQ, Anda dapat memigrasikan perangkat lunak ini ke Azure Virtual Machines dan menggunakannya apa adanya.

Microsoft memiliki solusi untuk mengintegrasikan IBM MQ dengan Logic Apps. Untuk informasi selengkapnya, lihat Koneksi ke server IBM MQ dari alur kerja di Azure Logic Apps.

Tentukan Apakah Anda menggunakan Pustaka Java EE Bersama yang Anda buat sendiri

Jika menggunakan fitur pustaka Java EE Bersama, Anda memiliki dua opsi:

  • Refaktor kode aplikasi Anda untuk menghapus semua dependensi di pustaka Anda, dan sebagai gantinya gabungkan fungsionalitas langsung ke dalam aplikasi Anda.
  • Tambahkan pustaka tersebut ke classpath server.

Tentukan apakah bundel OSGi digunakan

Jika Anda menggunakan bundel OSGi yang ditambahkan ke WAS, Anda perlu menambahkan file JAR yang setara langsung ke aplikasi web Anda.

Tentukan apakah aplikasi Anda berisi kode khusus OS

Jika aplikasi Anda berisi kode apa pun dengan dependensi pada OS host, Anda harus melakukan refaktor untuk menghapus dependensi tersebut. Misalnya, Anda mungkin perlu mengganti penggunaan / atau \ di jalur sistem file dengan File.Separator atau Paths.get.

Menentukan apakah IBM Integration Bus sedang digunakan

Jika aplikasi Anda menggunakan IBM Integration Bus, Anda perlu mengambil bagaimana IBM Integration Bus dikonfigurasi. Untuk informasi selengkapnya, lihat dokumentasi IBM Integration Bus.

Menentukan apakah aplikasi Anda terdiri dari beberapa WAR

Jika aplikasi Anda terdiri dari beberapa WAR, Anda harus memperlakukan masing-masing WAR tersebut sebagai aplikasi terpisah dan melalui panduan ini untuk masing-masing WAR.

Menentukan apakah aplikasi Anda dikemas sebagai EAR

Jika aplikasi Anda dikemas sebagai file EAR, pastikan untuk memeriksa file application.xml, ibm-application-bnd.xmi, dan ibm-application-ext.xmi dan ambil konfigurasinya. Untuk informasi selengkapnya, lihat Membangun paket arsip perusahaan (EAR) di WebSphere.

Identifikasi semua proses dan daemon luar yang berjalan di server produksi

Jika Anda memiliki proses yang berjalan di luar server aplikasi, seperti memantau daemon, Anda harus menghilangkannya atau memigrasikannya di tempat lain.

Menentukan apakah dan bagaimana sistem berkas digunakan

Sistem file VM beroperasi dengan cara yang sama seperti sistem file lokal sehubungan dengan persistensi, penyalaan, dan pematian. Meski begitu, penting untuk menyadari kebutuhan sistem file Anda dan memastikan VM memiliki performa dan ukuran penyimpanan yang memadai.

Konten statis baca-saja

Jika aplikasi Anda saat ini menyajikan konten statis, Anda memerlukan lokasi alternatif untuk itu. Anda mungkin ingin mempertimbangkan untuk memindahkan konten statik ke Azure Blob Storage dan menambahkan Azure CDN untuk unduhan secepat kilat secara global. Untuk informasi selengkapnya, lihat Hosting situs web statis di Penyimpanan Azure dan Mulai Cepat: Mengintegrasikan akun Microsoft Azure Storage dengan Azure CDN. Anda juga dapat langsung menyebarkan konten statis ke aplikasi dalam paket Azure Spring Apps Enterprise. Untuk informasi selengkapnya, lihat Menyebarkan file statis web.

Konten statis yang diterbitkan secara dinamis

Jika aplikasi Anda memungkinkan konten statis yang diunggah/ diproduksi oleh aplikasi Anda tetapi tidak dapat diubah setelah pembuatannya, Anda dapat menggunakan Azure Blob Storage dan Azure CDN seperti yang dijelaskan di atas, dengan Azure Function untuk menangani unggahan dan refresh CDN. Kami telah menyediakan implementasi sampel untuk penggunaan Anda di Pengunggahan dan pramuat CDN konten statis dengan Azure Functions. Anda juga dapat langsung menyebarkan konten statis ke aplikasi dalam paket Azure Spring Apps Enterprise. Untuk informasi selengkapnya, lihat Menyebarkan file statis web.

Menentukan topologi jaringan

Kumpulan penawaran Marketplace Azure saat ini adalah titik awal untuk migrasi Anda. Jika penawaran tidak mencakup aspek arsitektur yang perlu Anda migrasikan, Anda perlu mengambil topologi jaringan penyebaran yang ada. Kemudian, Anda perlu mereproduksi topologi jaringan itu di Azure, bahkan setelah berdiri dengan penawaran dasar dengan salah satu templat solusi.

Topologi jaringan adalah topik yang luas, tetapi referensi berikut dapat memberikan beberapa arah pada upaya migrasi Anda:

Memperhitungkan penggunaan adaptor JCA dan adaptor sumber daya

Jika aplikasi Anda yang ada menggunakan adaptor JCA atau adaptor sumber daya lainnya untuk terhubung ke sistem perusahaan lain, pastikan Anda menerapkan konfigurasi untuk artefak ini ke WAS yang berjalan di Azure Virtual Machines. Untuk informasi selengkapnya, lihat Adaptor sumber daya relasional dan JCA dalam dokumentasi IBM.

Akun untuk autentikasi dan otorisasi

Sebagian besar aplikasi memiliki semacam autentikasi dan otorisasi. Jika Anda menggunakan OpenID untuk autentikasi, Anda dapat mengonfigurasi autentikasi koneksi OpenID dengan ID Microsoft Entra. Untuk informasi selengkapnya, lihat Autentikasi Koneksi OpenID dengan ID Microsoft Entra.

Menentukan apakah pengklusteran WAS digunakan

Kemungkinan besar, Anda telah menyebarkan aplikasi Anda di beberapa server WAS untuk mencapai ketersediaan tinggi. Anda dapat memigrasikan kluster ini langsung dari penginstalan lokal Anda ke WAS yang berjalan di Azure Virtual Machines. Untuk informasi selengkapnya, lihat Penyebaran Jaringan Server Aplikasi WebSphere dalam dokumentasi IBM.

Akun untuk persyaratan penyeimbangan beban

Penyeimbangan beban adalah bagian penting dari migrasi kluster WAS Anda ke Azure. Solusi term mudah adalah menggunakan dukungan bawaan untuk Azure Application Gateway atau Server HTTP IBM yang disediakan dalam penawaran Marketplace Azure untuk Kluster Server Aplikasi IBM WebSphere.

Untuk ringkasan kemampuan Azure Application Gateway dibandingkan dengan solusi penyeimbangan beban Azure lainnya, lihat Opsi penyeimbangan beban.

Tentukan apakah fitur Klien Aplikasi Java EE digunakan

Jika aplikasi Anda menggunakan fitur Java EE Application Client, aplikasi tersebut akan terus berfungsi tidak berubah setelah bermigrasi ke Azure Virtual Machines. Untuk informasi selengkapnya, lihat Menggunakan Modul Java EE Client Application.

Migration

Pilih penawaran WAS tradisional di Azure Virtual Machines

Penawaran berikut tersedia untuk WAS di Azure Virtual Machines.

Selama penyebaran penawaran, Anda diminta untuk memilih ukuran komputer virtual untuk simpul WAS Anda. Penting untuk mempertimbangkan semua aspek ukuran (memori, prosesor, disk) dalam pilihan ukuran VM Anda. Untuk informasi selengkapnya, lihat Ukuran untuk Cloud Services (klasik).

  • Instans Tunggal Server Aplikasi IBM WebSphere di Azure VM

    Penawaran ini mengotomatiskan sebagian besar langkah boilerplate untuk menyediakan satu instans WebSphere pada Azure Virtual Machine. Ini membuat profil server Aplikasi dengan konsol admin WAS.

  • Kluster Server Aplikasi IBM WebSphere di Azure VM

    Penawaran ini mengotomatiskan sebagian besar langkah boilerplate untuk menyediakan kluster WebSphere di Azure VM. Ini membuat manajer penyebaran dengan konsol admin WAS pada Azure VM dan jumlah agen simpul yang diperlukan pada Azure VM yang dipisahkan.

Menyediakan penawaran

Setelah Anda memilih penawaran mana yang akan dimulai, provisikan penawaran tersebut dengan mengikuti instruksi di Menyebarkan Kluster Server Aplikasi WebSphere (tradisional) di Azure Virtual Machines.

Memigrasikan profil

Setelah menyediakan penawaran, Anda dapat memeriksa konfigurasi profil. Untuk informasi selengkapnya, lihat Konsep profil dalam dokumentasi IBM.

Menyambungkan database

Setelah memigrasikan profil, Anda dapat menyambungkan database dengan mengikuti instruksi dalam Mengonfigurasi sumber data WebSphere Application Server dalam dokumentasi IBM.

Akun untuk KeyStores

Anda harus memperhitungkan migrasi setiap KeyStores SSL yang digunakan oleh aplikasi Anda. Untuk informasi selengkapnya, lihat Konfigurasi keystore untuk SSL dalam dokumentasi IBM.

Menyambungkan sumber JMS

Setelah menyambungkan database, Anda dapat mengonfigurasi JMS dengan mengikuti instruksi di Menyiapkan JMS di Server Aplikasi IBM WebSphere dalam dokumentasi IBM.

Akun untuk autentikasi dan otorisasi

Sebagian besar aplikasi memiliki semacam autentikasi dan otorisasi. Jika Anda menggunakan OpenID untuk autentikasi, Anda dapat mengonfigurasi autentikasi koneksi OpenID dengan ID Microsoft Entra. Untuk informasi selengkapnya, lihat Autentikasi Koneksi OpenID dengan ID Microsoft Entra.

Akun untuk pengelogan

Anda dapat mengonfigurasi Elastic Stack dengan mengikuti instruksi di Menganalisis log Server Aplikasi WebSphere dengan Elastic Stack dalam dokumentasi IBM. Azure menyediakan dukungan untuk Elastic. Untuk informasi selengkapnya, lihat Apa itu integrasi Elastic dengan Azure? Anda dapat menggabungkan pengetahuan dalam kedua sumber daya ini untuk mencapai solusi pengelogan yang dioptimalkan Azure untuk WAS pada VM.

Memigrasikan aplikasi Anda

Teknik yang digunakan untuk menyebarkan aplikasi dari tim pengembangan ke dalam server pengujian, penahapan, dan produksi sangat bervariasi dari kasus ke kasus. Dalam beberapa kasus, ada platform CI/CD yang sangat berkembang yang menghasilkan aplikasi yang disebarkan ke Server Aplikasi WebSphere. Dalam kasus lain, prosesnya bisa lebih manual. Salah satu manfaat menggunakan Azure Virtual Machines untuk memigrasikan aplikasi tradisional WAS ke cloud adalah bahwa proses Anda yang ada terus berfungsi.

Anda harus mengonfigurasi Grup Keamanan Jaringan yang disediakan penawaran untuk mengizinkan akses dari alur CI/CD Anda, atau sistem penyebaran manual. Untuk informasi selengkapnya, lihat Kelompok keamanan jaringan.

Pengujian

Anda harus mengonfigurasi pengujian dalam kontainer terhadap aplikasi untuk mengakses server baru yang berjalan di Azure. Seperti halnya masalah CI /CD, Anda harus memastikan aturan keamanan jaringan yang diperlukan memungkinkan pengujian Anda mengakses aplikasi yang disebarkan ke Azure. Untuk informasi selengkapnya, lihat Kelompok keamanan jaringan.

Pasca-migrasi

Setelah mencapai sasaran migrasi yang ditentukan dalam langkah pramigrasi, lakukan beberapa pengujian penerimaan end-to-end untuk memverifikasi bahwa semuanya berfungsi seperti yang diharapkan. Untuk panduan tentang beberapa potensi peningkatan pascamigrasi, lihat rekomendasi berikut: