Memigrasi aplikasi WebLogic Server ke Azure Virtual Machines

  • Artikel

Panduan ini menjelaskan apa yang harus Anda ketahui ketika ingin memigrasikan aplikasi WebLogic yang ada untuk dijalankan di Azure Virtual Machines. Untuk gambaran umum solusi WebLogic Server yang tersedia di Marketplace Azure, lihat Apa solusi untuk menjalankan Oracle WebLogic Server di Azure Virtual Machines?

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 Azure Marketplace yang sesuai, adalah titik awal untuk mempercepat migrasi beban kerja WebLogic Server 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. Saat mencapai "migrasi selesai", Anda dapat mengambil snapshot Mesin Virtual Anda seperti yang dijelaskan dalam Membuat snapshot. 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 WLS yang berhasil ke Azure adalah memilih target migrasi yang paling tepat. WLS berjalan dengan baik pada komputer virtual (VM) Azure atau Azure Kubernetes Service (AKS). Target VM adalah pilihan term mudah, karena paling mirip dengan penyebaran lokal. Pengalaman administratif dan penyebaran untuk komputer virtual sangat dianalogikan dengan apa yang Anda miliki di tempat. Trade-off untuk kemudahan ini adalah biaya ekonomi. Secara umum, biaya per menit untuk solusi berbasis VM lebih tinggi dibandingkan dengan AKS. Meskipun solusi berbasis AKS lebih murah untuk dijalankan, Anda harus membatasi aplikasi Anda agar sesuai dengan persyaratan AKS. Jika meminimalkan perubahan adalah faktor terpenting untuk upaya migrasi Anda, pertimbangkan migrasi berbasis VM. Dalam hal ini, lihat Memigrasikan aplikasi WebLogic ke Azure Virtual Machines. Jika Anda dapat mentolerir konversi aplikasi agar berjalan dalam Kubernetes untuk mengurangi biaya runtime, pertimbangkan migrasi berbasis AKS. Dalam hal ini, lanjutkan dengan Memigrasikan aplikasi WebLogic Server ke Azure Kubernetes Service.

Tentukan apakah penawaran Marketplace Azure bawaan adalah titik awal yang baik

Oracle dan Microsoft telah bermitra untuk membawa serangkaian templat solusi Azure ke Marketplace Azure untuk menyediakan titik awal yang solid untuk bermigrasi ke Azure. Lihat dokumentasi Oracle Fusion Middleware untuk daftar penawaran dan pilih salah satu yang paling cocok dengan penyebaran Anda yang ada. Anda dapat melihat daftar penawaran di artikel gambaran umum Oracle WebLogic Server 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 di Menginstal Oracle WebLogic Server di Azure Virtual Machines secara manual. Untuk informasi selengkapnya, lihat Apa itu IaaS?

Menentukan apakah versi WebLogic kompatibel

Versi WebLogic Anda yang ada harus kompatibel dengan versi dalam penawaran IaaS. Untuk melihat penawaran untuk WebLogic versi 12.2.1.3, kueri Marketplace Azure untuk Oracle WebLogic 12.2.1.3. Jika versi WebLogic yang ada tidak kompatibel dengan versi tersebut, Anda harus mereproduksi penyebaran dengan tangan menggunakan sumber daya Azure IaaS. Untuk informasi selengkapnya, lihat dokumentasi Azure.

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 WebLogic Server, rahasia ini ada 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. Pastikan untuk memeriksa weblogic.xml di WAR Anda. File konfigurasi yang berisi kata sandi atau kredensial juga dapat ditemukan di dalam aplikasi Anda. Untuk informasi selengkapnya, kunjungi 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>

Memvalidasi bahwa versi Java yang didukung berfungsi dengan benar

Semua jalur migrasi untuk WebLogic ke Azure memerlukan versi Java tertentu, yang bervariasi untuk setiap jalur. Anda harus memvalidasi bahwa aplikasi Anda dapat berjalan dengan benar menggunakan versi yang didukung tersebut.

Catatan

Validasi ini sangat penting jika server Anda saat ini berjalan pada JDK yang tidak didukung (seperti Oracle JDK atau IBM OpenJ9).

Untuk mendapatkan versi Java Anda saat ini, masuk ke server produksi Anda dan jalankan perintah berikut:

java -version

Catatan

Saat bermigrasi ke WLS di komputer virtual Azure, persyaratan untuk versi Java tertentu ditentukan oleh Java yang telah diinstal sebelumnya pada komputer virtual. Saat bermigrasi ke WLS di AKS, versi Java tertentu ditentukan oleh gambar kontainer yang dipilih. Ada berbagai pilihan, tetapi semuanya menggunakan Oracle JDK.

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 WebLogic Server di dokumentasi Oracle. Sumber daya terkait JNDI lainnya, seperti perantara pesan JMS, mungkin memerlukan migrasi atau konfigurasi ulang. Untuk informasi selengkapnya tentang konfigurasi JMS, lihat Oracle WebLogic Server 12.2.1.4.0.

Memeriksa konfigurasi domain Anda

Unit konfigurasi utama di WebLogic Server adalah domain. Dengan demikian, file config.xml berisi banyak konfigurasi yang harus Anda pertimbangkan dengan saksama untuk migrasi. File tersebut mencakup referensi ke file XML tambahan yang disimpan di subdirektori. Oracle menyarankan agar Anda biasanya menggunakan Konsol Administrasi untuk mengonfigurasi objek dan layanan yang dapat dikelola WebLogic Server serta mengizinkan WebLogic Server mempertahankan file config.xml. Untuk informasi selengkapnya, lihat File Konfigurasi Domain.

Di dalam aplikasi Anda

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

Menentukan apakah replikasi sesi digunakan

Jika aplikasi Anda bergantung pada replikasi sesi, dengan atau tanpa Oracle Coherence*Web, Anda memiliki tiga opsi:

  • Coherence*Web dapat berjalan bersama WebLogic Server di mesin virtual Azure, tetapi Anda harus mengonfigurasi opsi ini secara manual setelah menyediakan penawaran. Jika menggunakan Coherence saja, Anda juga dapat menjalankannya di mesin virtual Azure, tetapi Anda harus mengonfigurasi opsi ini secara manual setelah menyediakan penawaran.
  • 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 Anda menguasai bagaimana Weblogic melakukan Replikasi Keadaan Sesi HTTP. Untuk informasi selengkapnya, lihat Replikasi Keadaan Sesi HTTP di dokumentasi Oracle.

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 WebLogic, lihat Menggunakan Driver JDBC dengan WebLogic Server.

Tentukan apakah WebLogic telah dikustomisasikan

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

  • Apakah skrip penyalaan telah diubah? Skrip tersebut mencakup setDomainEnv, commEnv, startWebLogic, dan stopWebLogic.
  • Apakah ada parameter khusus yang diteruskan ke JVM?
  • Apakah ada JAR yang ditambahkan ke classpath server?

Menentukan apakah Manajemen atas REST digunakan

Jika siklus hidup aplikasi Anda meliputi penggunaan Manajemen atas REST, Anda perlu menangkap port mana yang digunakan untuk mengakses REST API dan menentukan bagaimana port diautentikasi dan diekspos. Setelah migrasi, Anda harus memastikan bahwa port dan mekanisme autentikasi yang sama ini terekspos sehingga siklus hidup aplikasi Anda dapat beroperasi dengan cara yang sama seperti sebelum migrasi. Untuk informasi selengkapnya, lihat Mengelola Oracle WebLogic Server dengan RESTful Management Services.

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 harus memigrasikannya ke server JMS yang dihosting secara eksternal. Azure Service Bus dan Advanced Message Queuing Protocol dapat menjadi strategi migrasi yang baik bagi mereka yang menggunakan JMS. Untuk informasi selengkapnya, lihat Menggunakan JMS dengan Azure Service Bus dan AMQP 1.0.

Jika penyimpanan persisten JMS telah dikonfigurasi, Anda harus menangkap konfigurasinya dan menerapkannya setelah migrasi.

Jika menggunakan Oracle Message Broker, Anda dapat memigrasikan perangkat lunak ini ke mesin virtual Azure dan menggunakannya apa adanya.

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 menggunakan bundel OSGi yang ditambahkan ke server WebLogic, Anda harus 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 Oracle Service Bus sedang digunakan

Jika aplikasi Anda menggunakan Oracle Service Bus (OSB), Anda harus menangkap cara OSB dikonfigurasi. Untuk informasi selengkapnya, lihat Tentang Penginstalan Oracle Service 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 dan weblogic-application.xml serta menangkap konfigurasinya.

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 WebLogic Scripting Tool (WLST) digunakan

Jika saat ini Anda menggunakan WLST untuk melakukan penyebaran, Anda perlu menilai apa yang dilakukannya. Jika WLST mengubah parameter (runtime) aplikasi Anda sebagai bagian dari penyebaran, Anda harus memastikan bahwa perilaku ini terus berfungsi saat menguji aplikasi Anda setelah migrasi.

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 dimigrasi, Anda harus menangkap topologi jaringan dari penyebaran yang ada dan memproduksinya ulang di Azure, bahkan setelah menyiapkan penawaran dasar dengan salah satu templat solusi.

Ini adalah topik yang sangat luas, tetapi referensi berikut dapat memberikan beberapa arahan untuk upaya migrasi Anda:

Akun untuk penggunaan Adaptor JCA dan Adaptor Sumber Daya

Jika aplikasi Anda yang ada menggunakan Adaptor JCA dan/atau Adaptor Sumber Daya untuk tersambung ke sistem enterprise lain, pastikan konfigurasi untuk artefak ini diterapkan ke WebLogic Server yang berjalan di Azure Virtual Machines. Untuk informasi selengkapnya, lihat Membuat dan Mengonfigurasi Adaptor Sumber Daya

Akun untuk penggunaan penyedia keamanan kustom dan JAAS

Jika aplikasi Anda menggunakan JAAS, Anda perlu memastikan konfigurasi penyedia keamanan dimigrasikan dengan benar. Untuk informasi selengkapnya, lihat Tentang Mengonfigurasi Penyedia Keamanan WebLogic di dokumentasi Oracle.

Menentukan apakah pengklusteran WebLogic digunakan

Kemungkinan besar, Anda telah menyebarkan aplikasi Anda di beberapa server WebLogic untuk mencapai ketersediaan tinggi. Anda dapat memigrasi kluster ini langsung dari penginstalan lokal Anda ke WebLogic yang berjalan di Azure Virtual Machines. Untuk informasi selengkapnya, lihat File Konfigurasi Domain di dokumentasi Oracle.

Akun untuk persyaratan penyeimbangan beban

Penyeimbangan beban adalah bagian penting dari migrasi kluster Oracle WebLogic Server ke Azure. Solusi termudah adalah menggunakan dukungan bawaan untuk Azure Application Gateway yang disediakan dalam penawaran Azure Marketplace untuk kluster Oracle WebLogic Server. Untuk tutorial mengenai topik ini, lihat Tutorial: Memigrasi kluster WebLogic Server ke Azure dengan Azure Application Gateway sebagai penyeimbang beban.

Untuk ringkasan kemampuan Azure Application Gateway dibandingkan dengan solusi penyeimbangan beban Azure lainnya, lihat Gambaran umum opsi penyeimbangan beban di Azure.

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 WebLogic di Azure Virtual Machines

Penawaran berikut tersedia untuk WebLogic di Azure Virtual Machines.

Selama penyebaran penawaran, Anda diminta untuk memilih ukuran Komputer Virtual untuk simpul server WebLogic Anda. Penting untuk mempertimbangkan semua aspek ukuran (memori, prosesor, disk) dalam pilihan ukuran VM Anda. Untuk informasi selengkapnya, lihat Dokumentasi Azure untuk ukuran mesin virtual

Node Tunggal Server WebLogic tanpa Server Admin

Penawaran ini menciptakan satu VM dan menginstal WebLogic, tetapi tidak mengonfigurasi domain apa pun, yang berguna untuk skenario di mana Anda memiliki konfigurasi domain yang sangat dikustomisasi.

Node Tunggal Server WebLogic tanpa Server Admin

Penawaran ini memprovisikan satu VM dan menginstal Server WebLogic. Penawaran ini membuat domain dan memulai server admin.

Kluster Node N Server WebLogic

Penawaran ini menciptakan kluster VM Server WebLogic dengan ketersediaan tinggi.

Kluster Dinamis Node N WebLogic Server

Penawaran ini menciptakan kluster dinamis mesin virtual WebLogic Server dengan ketersediaan tinggi dan dapat diskalakan.

Menyediakan penawaran

Setelah memilih penawaran yang akan dimulai, ikuti instruksi dalam dokumentasi untuk penawaran guna menyediakan penawaran tersebut. Pastikan untuk memilih nama domain yang cocok dengan nama domain Anda yang ada. Anda bahkan dapat mencocokkan kata sandi domain dengan kata sandi domain yang ada.

Memigrasikan domain

Setelah menyediakan penawaran, Anda dapat memeriksa konfigurasi domain dan mengikuti panduan ini untuk detail tentang cara memigrasikan domain.

Menyambungkan database

Setelah memigrasikan domain, Anda dapat menyambungkan database dengan mengikuti instruksi dalam dokumentasi penawaran. Instruksi ini membantu Anda memperhitungkan rahasia database dan string akses apa pun yang terlibat.

Akun untuk KeyStores

Anda harus memperhitungkan migrasi setiap KeyStores SSL yang digunakan oleh aplikasi Anda. Untuk informasi selengkapnya, lihat Mengonfigurasi Keystores.

Menyambungkan sumber JMS

Setelah menghubungkan database, Anda dapat mengonfigurasi JMS. Untuk informasi selengkapnya, lihat Fusion Middleware Mengelola Sumber Daya JMS untuk Oracle WebLogic Server dalam dokumentasi WebLogic.

Akun untuk autentikasi dan otorisasi

Sebagian besar aplikasi memiliki semacam autentikasi dan otorisasi. Jika Anda menggunakan LDAP untuk autentikasi, Anda dapat menyiapkan Microsoft Entra Domain Services dengan LDAP yang aman dan mengonfigurasi koneksi LDAP di WebLogic Server. Untuk informasi selengkapnya, lihat Membuat dan mengonfigurasi domain terkelola Microsoft Entra Domain Services dan Mengonfigurasi LDAP aman untuk domain terkelola Microsoft Entra Domain Services.

Akun untuk pengelogan

Gunakan integrasi dengan Elastic di Azure yang disediakan oleh templat solusi marketplace Oracle WebLogic Server. Pendekatan ini adalah cara term mudah untuk memperhitungkan pengelogan. Anda dapat melihat daftar penawaran di artikel gambaran umum Apa solusi untuk menjalankan Oracle WebLogic Server di Azure Virtual Machines? Tutorial lengkap untuk mengonfigurasi Elastic disediakan di:

Jika integrasi Elastic tidak sesuai, Anda harus membawa konfigurasi pengelogan yang ada saat memigrasikan domain. Untuk informasi selengkapnya, lihat Mengonfigurasi tingkat pencatat java.util.logging serta Mengonfigurasi File Log dan Memfilter Pesan Log untuk Oracle WebLogic Server dalam dokumentasi Oracle.

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 WebLogic Server. Dalam kasus lain, prosesnya bisa lebih manual. Salah satu manfaat menggunakan Azure Virtual Machines untuk memigrasikan aplikasi WebLogic 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 atau sistem penyebaran manual Anda. Untuk informasi selengkapnya, lihat Kelompok keamanan jaringan.

Pengujian

Setiap pengujian dalam kontainer terhadap aplikasi harus dikonfigurasi untuk mengakses server baru yang berjalan dalam 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: