El inventario de sus sistemas heredados se hace con una página por sistema que responde 7 preguntas: responsable, usuarios, datos y si incluyen datos personales, conexiones, qué se detiene si se detiene, fechas de renovación de licencias, y la tecnología y el fin de su soporte. Después asigna a cada sistema una de 5 decisiones: mantener, retirar, sustituir por un producto ya hecho, trasladar tal cual a la nube o reconstruir, una versión simplificada de las 7 estrategias de la guía oficial de migración de Amazon. La IA acelera la mitad técnica, pero no puede decirle quién es el responsable de un sistema.

En la parte 2 puntuó cada sistema sobre 8. La puntuación muestra el riesgo; el inventario le da lo que necesita para decidir.

Qué va en la página de cada sistema

No necesita un software especial para empezar. Basta una tabla sencilla, siempre que responda estas preguntas para cada sistema:

  • Responsable: una persona con nombre que decide sobre el sistema desde el lado del negocio, no el departamento de TI. Si no encuentra a nadie, ese es el primer hallazgo de su inventario.
  • Usuarios: qué departamentos lo usan, cuántas personas aproximadamente y si también lo usan clientes o proveedores de fuera de la empresa.
  • Datos: qué almacena, si incluye datos personales de clientes o empleados y dónde están realmente: un servidor en la oficina o una nube, y en qué país.
  • Conexiones: de dónde vienen sus datos y adónde van: facturación, el banco, la tienda en línea, la nómina, un archivo de Excel exportado cada semana.
  • Impacto de una caída: qué pasa si se detiene un día entero: ¿se paran las ventas, se retrasa la nómina o nadie lo nota?
  • Licencias y contratos: a quién paga, cuándo se renueva el contrato y si hay un plazo de preaviso antes de la renovación. La fecha de renovación suele marcar cuándo debe estar lista su decisión.
  • Tecnología y soporte: el lenguaje de programación, la base de datos y el sistema operativo, y cuándo termina el soporte de cada uno, como vimos en la parte 2.

Si el inventario muestra que algunos de sus sistemas reales son hojas de cálculo de las que depende el trabajo diario, explicamos cómo inventariarlas en qué hoja es el sistema.

La cuestión de los datos: no se la salte

La columna de datos personales importa más que cualquier otra, porque cambia la decisión. Un sistema que guarda nombres y teléfonos de clientes o expedientes de empleados está sujeto a la Ley de Protección de Datos Personales (PDPL), supervisada por la Autoridad Saudí de Datos e Inteligencia Artificial (SDAIA), y trasladar o tratar esos datos fuera del Reino durante la modernización requiere una revisión antes de empezar. Explicamos las obligaciones prácticas en nuestra guía de la PDPL para empresas.

Esto afecta también a las propias herramientas de modernización. Por ejemplo, la página oficial de Regiones de AWS Transform enumera 9 Regiones donde se pueden crear espacios de trabajo, ninguna en Oriente Medio, y advierte que los datos pueden procesarse en una Región distinta de aquella desde la que trabaja. Según la Agencia de Prensa Saudí el 1 de septiembre de 2026, Amazon anunció que su primera Región en la nube en el Reino va camino de abrir en diciembre de 2026. Así que anote dónde están hoy los datos de cada sistema, para saber qué herramientas pueden leerlos sin problemas.

Cómo acelera la IA el inventario, y lo que no puede saber

La mitad técnica de un inventario solía llevar semanas de revisar servidores y leer código a mano. Las herramientas actuales leen servidores y código y trazan automáticamente las conexiones entre ellos. Un ejemplo entre muchos: Amazon dice en la página de AWS Transform que sus agentes automatizan la migración desde el descubrimiento y la planificación por oleadas hasta el cambio final, y que su evaluación de mainframes reduce meses de descubrimiento a horas. Es una afirmación de Amazon, no un resultado garantizado. Su página de precios incluye actualmente la evaluación entre los agentes gratuitos.

La guía de migración de Amazon también da señales prácticas para detectar sistemas que puede retirar, usando los datos de la propia herramienta de descubrimiento:

  • Un sistema cuyo uso medio de CPU y memoria está por debajo del 5 por ciento es lo que la guía llama una aplicación zombi.
  • Un sistema que usa entre el 5 y el 20 por ciento durante 90 días es lo que llama una aplicación inactiva.
  • Un sistema sin ninguna conexión entrante en los últimos 90 días es candidato a retirarse.

Pero la herramienta no sabe quién es el responsable del sistema, cuándo se renueva su contrato, que el único empleado que lo entiende se jubila el año que viene, ni que de él sale un único informe anual de zakat. Eso viene de una breve entrevista con el responsable y los usuarios de cada sistema. La máquina rellena las columnas técnicas; las personas rellenan las columnas de negocio.

Las cinco decisiones para cada sistema

Después del inventario, asigna una decisión a cada sistema. Esta es una visión simplificada de las siete estrategias de la guía de Amazon:

DecisiónQué significa, en pocas palabrasCuándo encaja
MantenerSe queda como está por ahora, con seguimientoEstable y aislado, ligado a hardware especial, actualizado hace poco o a la espera de una versión ya hecha del proveedor
RetirarLo apaga y archiva sus datosSin valor para el negocio, casi sin uso o con tecnología sin soporte que no merece modernizarse
Sustituir por un producto ya hechoCompra un producto o suscripción que hace el mismo trabajoEl trabajo que hace es corriente y no lo diferencia, y un producto lo cubre sin grandes cambios
Trasladar tal cualLo lleva a la nube sin cambiar el códigoEl problema es el servidor y el hardware, no el software en sí
ReconstruirLo reescribe o cambia su estructuraSus reglas de negocio son lo que lo diferencia, y no se puede modificar o nadie sabe mantenerlo

La guía advierte que reconstruir es la opción más compleja y costosa, y para las grandes migraciones recomienda trasladar primero el sistema y modernizarlo cuando el traslado haya terminado. Si su decisión es la nube, empiece por nuestra guía para pasar a la nube para empresas saudíes.

La visión de Origami

Construimos sistemas, los conectamos y modernizamos los antiguos, y aun así empezamos cada proyecto de modernización por el inventario, no por el código. Un sistema cuyas conexiones desconoce puede romper algo que no verá hasta que un cliente se queje, y el inventario a menudo muestra que la decisión correcta para muchos sistemas es mantenerlos o retirarlos, no reconstruirlos.

Por eso usamos herramientas de IA para leer servidores y código y trazar las conexiones rápidamente, luego nos sentamos con el responsable de cada sistema para completar lo que la herramienta no puede saber, y salimos con una decisión por sistema y un orden claro para empezar. Si quiere ver cómo trabajamos, eche un vistazo a nuestros servicios.

El ejercicio de esta semana: una página por sistema

Tome los sistemas que obtuvieron 6 sobre 8 o más en el ejercicio de la parte 2 y rellene esta tabla para cada uno en una sola página:

ElementoRespuesta
Nombre del sistema y qué hace, en una frase
Responsable de negocio
Usuarios (departamentos, número aproximado, terceros externos)
Datos, si incluyen datos personales y dónde se almacenan
Conexiones entrantes y salientes
Qué se detiene si se detiene un día
Licencias, fecha de renovación y plazo de preaviso
Tecnología y fin de su soporte
Puntuación de la parte 2 sobre 8
Decisión provisional, una de las cinco

Escriba la decisión a lápiz. Sigue siendo provisional hasta que sepa qué reglas viven dentro del sistema, y ese es el tema de la próxima parte.

Próximamente

Ya tiene un inventario y una decisión provisional para cada sistema. Pero los sistemas que decidió reconstruir esconden su activo más valioso: las reglas de negocio reales de descuentos, precios, recargos por demora y aprobaciones, enterradas en el código y en la cabeza de las personas. En la parte 4 explicamos cómo la IA extrae esas reglas de su sistema antiguo y las escribe como especificaciones claras, y por qué la persona responsable de cada proceso debe confirmar cada regla antes de escribir cualquier código nuevo.

Fuentes