La mayoría de los proyectos de migración parten de una decisión: pasar de Oracle Java SE a OpenJDK, sustituir una distribución Linux que llega al final de su vida útil o consolidar servidores en una nube privada. Sobre el papel, el plan suele parecer sencillo. Después, el equipo del proyecto descubre runtimes de Java que nadie conocía, servidores sin responsable y aplicaciones que dependen discretamente de una versión antigua. Los plazos se alargan y los presupuestos crecen.

La forma de evitarlo es empezar por el descubrimiento: un inventario completo y objetivo de lo que realmente está instalado. Este artículo explica qué recopilar, cómo hacerlo en Windows y Linux, qué sorpresas cabe esperar y cómo convertir los resultados en un plan de migración.

Por qué el descubrimiento va antes que la migración

Una migración solo es tan buena como la información en la que se basa. Sin un inventario, el alcance se estima a partir de la memoria, de hojas de cálculo antiguas y de registros de licencias, y ninguno de ellos refleja lo que realmente se está ejecutando hoy.

Un buen inventario le aporta tres cosas:

• Alcance: cuántas máquinas, runtimes y aplicaciones se ven afectados, para estimar el esfuerzo y el coste de forma realista.
• Riesgo: qué sistemas ejecutan versiones sin soporte o sin parches, y cuáles son críticos para el negocio.
• Responsabilidad: quién es responsable de cada sistema, para que las pruebas y la aprobación tengan un responsable claro.

También le protege en las conversaciones sobre licencias. Si un proveedor le pregunta cuántas instalaciones tiene, un inventario actualizado le permite responder con datos en lugar de suposiciones.

Qué recopilar: versiones, proveedores, rutas y responsables

Para cada instalación de Java, recopile como mínimo lo siguiente:

• Host: nombre de la máquina, dirección IP y si se trata de un servidor, una máquina virtual o un equipo de escritorio.
• Versión: la cadena de versión completa, por ejemplo 1.8.0_202 o 17.0.10, no solo “Java 8” o “Java 17”.
• Proveedor: quién ha compilado el runtime, como Oracle o una distribución de OpenJDK. La versión por sí sola no lo indica.
• Tipo y ruta: si es un JDK completo o solo un JRE, y el directorio en el que está instalado.
• Uso: qué aplicaciones o servicios lo utilizan, si es posible averiguarlo.
• Responsable: el equipo o la persona a cargo de la máquina o de la aplicación.

En los servidores Linux, recopile también la distribución y su versión, la versión del kernel, los principales paquetes instalados y los servicios en ejecución. Así sabrá qué servidores forman parte de una migración de Linux, además de una de Java.

Windows, Linux y equipos de escritorio: enfoques distintos

Cada entorno requiere un método ligeramente distinto. Los comandos siguientes son un punto de partida; en la práctica, los equipos los integran en un script y lo ejecutan en todas las máquinas con sus herramientas de gestión habituales.

Servidores Windows

Los runtimes de Java instalados suelen registrarse en la clave del registro de Windows HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft, pero no todos lo hacen. Buscar en el sistema de archivos es más fiable:

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

Revise todas las unidades, no solo C:, porque los servidores de aplicaciones a menudo se instalan en una unidad de datos independiente.

Servidores Linux

En Linux, combine el gestor de paquetes con una búsqueda de archivos, ya que muchos runtimes de Java se descomprimen desde un archivo comprimido en lugar de instalarse como paquete:

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

En Debian o Ubuntu, utilice dpkg -l | grep -i -E 'jdk|jre' en lugar de rpm. Al ejecutar cada binario java encontrado con -version, se muestra la versión y, normalmente, el proveedor. La mayoría de los directorios de JDK incluyen además un archivo release que indica el implementador.

Equipos de escritorio

Los equipos de escritorio son la parte del inventario que más a menudo se olvida. Los desarrolladores instalan sus propios JDK y algunas aplicaciones de negocio instalan un runtime de Java sin avisar. Como hay muchos equipos, utilice siempre que pueda el inventario de software de su herramienta de gestión de endpoints y ejecute un script ligero solo donde falte esa información.

Sorpresas habituales (JRE integrados, servidores olvidados)

Casi todos los proyectos de descubrimiento encuentran cosas que nadie esperaba. Las más habituales son:

• Runtimes integrados: muchas aplicaciones comerciales incluyen su propio runtime de Java privado dentro de su directorio de instalación. Es posible que no aparezca en el registro ni en ninguna lista de paquetes.
• Varias versiones en una misma máquina: los runtimes antiguos rara vez se eliminan al instalar uno nuevo, por lo que un servidor puede tener tres o cuatro.
• Servidores olvidados: máquinas de pruebas, antiguos servidores de procesos por lotes y máquinas virtuales que nunca se dieron de baja, a menudo con versiones obsoletas y sin parches.
• Responsables desconocidos: máquinas que nadie reclama. Requieren una decisión antes de que empiece la migración, aunque esa decisión sea apagarlas.

Del inventario al plan de migración

Una vez recopilados los datos, consolídelos en un único lugar y revíselos con los responsables de los sistemas. A continuación, agrupe las instalaciones por categorías:

Grupo	Qué contiene	Qué hacer
Eliminar	Runtimes que ya no se utilizan	Desinstalarlos ya para reducir el riesgo y la exposición en materia de licencias
Sustituir	Runtimes que gestiona usted mismo	Pasar a una compilación de OpenJDK con soporte tras realizar pruebas
Coordinar	Runtimes integrados en aplicaciones de terceros	Obtener primero la declaración de soporte del proveedor de la aplicación
Investigar	Todo lo que no tenga responsable ni una finalidad clara	Localizar al responsable o decidir apagarlo

A partir de estos grupos puede elaborar un calendario realista: empiece por los sistemas de bajo riesgo para validar el proceso y continúe después con los sistemas críticos para el negocio, con un procedimiento de vuelta atrás probado.

Cómo puede ayudarle LOGIQ

LOGIQ lleva a cabo proyectos de descubrimiento y migración para entornos Java y Linux, con scripts y procedimientos perfeccionados en proyectos reales de clientes en servidores Windows, servidores Linux y equipos de escritorio. Si desea ayuda para elaborar su inventario o convertirlo en un plan de migración, póngase en contacto con LOGIQ.