Sebagian besar proyek migrasi dimulai dengan sebuah keputusan: beralih dari Oracle Java SE ke OpenJDK, mengganti distribusi Linux yang sudah habis masa dukungannya, atau mengonsolidasikan server ke private cloud. Di atas kertas, rencananya biasanya terlihat sederhana. Kemudian tim proyek menemukan runtime Java yang tidak diketahui siapa pun, server yang tidak memiliki penanggung jawab, dan aplikasi yang diam-diam bergantung pada versi lama. Jadwal pun mundur dan anggaran membengkak.

Cara menghindarinya adalah dengan memulai dari discovery: inventaris yang lengkap dan faktual tentang apa yang benar-benar terpasang. Artikel ini menjelaskan apa saja yang perlu dikumpulkan, cara mengumpulkannya di Windows dan Linux, kejutan apa yang perlu diantisipasi, serta cara mengubah hasilnya menjadi rencana migrasi.

Mengapa discovery harus dilakukan sebelum migrasi

Kualitas sebuah migrasi hanya sebaik informasi yang menjadi dasarnya. Tanpa inventaris, Anda memperkirakan cakupan berdasarkan ingatan, spreadsheet lama, dan catatan lisensi, padahal tidak satu pun dari sumber tersebut mencerminkan apa yang benar-benar berjalan saat ini.

Inventaris yang baik memberi Anda tiga hal:

• Cakupan: berapa banyak mesin, runtime, dan aplikasi yang terdampak, sehingga Anda dapat memperkirakan upaya dan biaya secara realistis.
• Risiko: sistem mana yang menjalankan versi yang tidak didukung atau belum di-patch, dan sistem mana yang kritis bagi bisnis.
• Kepemilikan: siapa yang bertanggung jawab atas setiap sistem, sehingga pengujian dan persetujuan memiliki penanggung jawab yang jelas.

Inventaris juga melindungi Anda dalam diskusi terkait lisensi. Jika vendor menanyakan berapa banyak instalasi yang Anda miliki, inventaris yang mutakhir memungkinkan Anda menjawab berdasarkan fakta, bukan tebakan.

Apa yang perlu dikumpulkan: versi, vendor, path, dan penanggung jawab

Untuk setiap instalasi Java, kumpulkan setidaknya informasi berikut:

• Host: nama mesin, alamat IP, dan apakah mesin tersebut berupa server, mesin virtual, atau PC desktop.
• Versi: string versi lengkap, misalnya 1.8.0_202 atau 17.0.10, bukan sekadar “Java 8” atau “Java 17”.
• Vendor: pihak yang membangun runtime tersebut, seperti Oracle atau salah satu distribusi OpenJDK. Nomor versi saja tidak memberi tahu Anda hal ini.
• Jenis dan path: apakah berupa JDK lengkap atau hanya JRE, serta direktori tempat runtime tersebut terpasang.
• Penggunaan: aplikasi atau layanan mana yang menggunakannya, jika dapat diketahui.
• Penanggung jawab: tim atau orang yang bertanggung jawab atas mesin atau aplikasi tersebut.

Untuk server Linux, kumpulkan juga distribusi dan versinya, versi kernel, paket-paket utama yang terpasang, serta layanan yang sedang berjalan. Informasi ini menunjukkan server mana yang termasuk dalam migrasi Linux selain migrasi Java.

Windows, Linux, dan PC desktop: pendekatan yang berbeda

Setiap lingkungan memerlukan metode yang sedikit berbeda. Perintah-perintah di bawah ini hanyalah titik awal; dalam praktiknya, tim biasanya membungkusnya dalam sebuah skrip dan menjalankannya di semua mesin menggunakan alat manajemen yang sudah ada.

Server Windows

Runtime Java yang terpasang sering kali mendaftarkan dirinya di bawah registry key Windows HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft, tetapi tidak semuanya melakukannya. Menelusuri sistem file lebih dapat diandalkan:

Get-ChildItem -Path C:\ -Filter java.exe -Recurse -ErrorAction SilentlyContinue |
  Select-Object FullName, @{n='Version'; e={$_.VersionInfo.ProductVersion}}

Periksa setiap drive, bukan hanya C:, karena server aplikasi sering dipasang di drive data terpisah.

Server Linux

Di Linux, gabungkan package manager dengan pencarian file, karena banyak runtime Java yang diekstrak dari arsip alih-alih dipasang sebagai paket:

cat /etc/os-release
rpm -qa | grep -i -E 'jdk|jre|java'
find / -xdev -type f -name java -perm -u+x 2>/dev/null

Di Debian atau Ubuntu, gunakan dpkg -l | grep -i -E 'jdk|jre' sebagai pengganti rpm. Untuk setiap biner java yang ditemukan, menjalankannya dengan -version akan menampilkan versi dan biasanya juga vendornya. Sebagian besar direktori JDK juga berisi file release yang mencantumkan nama implementor.

PC desktop

Desktop adalah bagian inventaris yang paling sering terlupakan. Developer memasang JDK mereka sendiri, dan aplikasi bisnis terkadang memasang runtime Java tanpa sepengetahuan pengguna. Karena jumlah desktop banyak, gunakan inventaris perangkat lunak dari alat manajemen endpoint Anda jika memungkinkan, dan jalankan skrip ringan hanya di tempat informasi tersebut belum tersedia.

Kejutan yang umum ditemui (JRE yang dibundel, server yang terlupakan)

Hampir setiap proyek discovery menemukan hal-hal yang tidak diduga siapa pun. Yang paling umum adalah:

• Runtime yang dibundel: banyak aplikasi komersial menyertakan runtime Java privatnya sendiri di dalam direktori instalasinya. Runtime ini mungkin tidak muncul di registry ataupun di daftar paket mana pun.
• Beberapa versi dalam satu mesin: runtime lama jarang dihapus saat runtime baru dipasang, sehingga satu server bisa memiliki tiga atau empat versi.
• Server yang terlupakan: mesin uji, server batch lama, dan mesin virtual yang tidak pernah dinonaktifkan, yang sering kali menjalankan versi usang dan belum di-patch.
• Penanggung jawab tidak diketahui: mesin yang tidak diakui oleh siapa pun. Mesin seperti ini memerlukan keputusan sebelum migrasi dimulai, meskipun keputusannya adalah mematikannya.

Dari inventaris ke rencana migrasi

Setelah data terkumpul, satukan di satu tempat dan tinjau bersama para pemilik sistem. Kemudian kelompokkan instalasi ke dalam beberapa kategori:

Kelompok	Isinya	Tindakan
Hapus	Runtime yang sudah tidak digunakan	Hapus instalasinya sekarang untuk mengurangi risiko dan eksposur lisensi
Ganti	Runtime yang Anda kelola sendiri	Beralih ke build OpenJDK yang didukung setelah pengujian
Koordinasikan	Runtime yang dibundel dengan aplikasi pihak ketiga	Dapatkan pernyataan dukungan dari vendor aplikasi terlebih dahulu
Selidiki	Apa pun yang tidak memiliki penanggung jawab atau tujuan yang jelas	Temukan penanggung jawabnya, atau putuskan untuk mematikannya

Dari kelompok-kelompok ini, Anda dapat menyusun jadwal yang realistis: mulailah dari sistem berisiko rendah untuk membuktikan prosesnya, lalu lanjutkan ke sistem yang kritis bagi bisnis dengan jalur rollback yang sudah diuji.

Bagaimana LOGIQ dapat membantu

LOGIQ menjalankan proyek discovery dan migrasi untuk lingkungan Java dan Linux, menggunakan skrip dan prosedur yang telah disempurnakan dalam proyek nyata pelanggan di server Windows, server Linux, dan PC desktop. Jika Anda memerlukan bantuan untuk menyusun inventaris atau mengubahnya menjadi rencana migrasi, hubungi LOGIQ.