Has heredado un sistema sin documentación: por dónde empezar

Nada de esto exige entender el sistema. Son preguntas que se responden mirando, y hasta que no estén respondidas cualquier decisión técnica es una apuesta.

Quién puede entrar a producción

La lista de personas con acceso al servidor, a la base de datos y al panel de la nube. Suele incluir a alguien que ya no está, y esa es la primera cosa que se arregla.

Cómo se despliega

Qué comando, desde dónde y quién lo ha ejecutado por última vez. Si la respuesta es «se sube por FTP desde el portátil de alguien», eso no es una crítica: es el dato que ordena todo lo demás.

Las copias de seguridad, y la última restauración

Que existan copias no es la pregunta. La pregunta es cuándo fue la última vez que alguien restauró una y comprobó que el sistema arrancaba con ella. Si nadie lo ha hecho nunca, no sabes si tienes copias.

Los procesos programados

Los cron, las colas y las tareas que solo corren a fin de mes. Son lo que más sorprende, porque no aparecen mientras miras el código y sí aparecen el día 1 a las tres de la mañana.

Dónde están los secretos

Claves de API, credenciales, certificados. Si están dentro del repositorio, ya lo sabes: hay que rotarlas, y eso pasa a ser urgente y no importante-algún-día.

Las integraciones con terceros

Con qué habla el sistema y con qué credenciales: pasarela de pago, correo, mensajería, el ERP. Cada una es una cuenta que alguien paga y que puede caducar sin avisar.

El tamaño real de los datos

Cuánto pesa la base de datos y cuánto crece al mes. Determina si una migración se hace en una ventana de mantenimiento o hay que planificarla de otra manera.

Las versiones de todo

Del lenguaje, del framework, del sistema operativo y del motor de base de datos. Es el apartado siguiente y es el que suele traer la primera fecha límite.

Un sistema heredado no suele fallar por su código: falla porque algo debajo dejó de recibir parches y nadie lo estaba mirando. Esa es la parte con fecha, y la fecha la pone otro.

• La versión del lenguaje. Si es PHP, la fecha está publicada: el calendario de soporte de PHP y Symfony dice hasta cuándo recibe parches cada rama, y cuál exige cuál.
• El sistema operativo del servidor. Una distribución fuera de soporte deja de recibir parches de seguridad aunque tu aplicación siga intacta.
• El motor de base de datos, que suele ir un par de versiones por detrás de todo lo demás.
• Las dependencias abandonadas: las que no han tenido una versión nueva en años. No caducan en una fecha, caducan el día que aparece un fallo y no hay quien lo arregle.

Con el inventario delante, cada parte del sistema cae en uno de tres sitios. La decisión no se toma por lo antiguo que sea el código, sino por lo que cuesta cada cambio y por lo que pasa si se cae.

1. Mantener

   Funciona, cambia poco y su tecnología sigue con soporte. No se toca. La tentación de reescribir esto es la que se lleva los presupuestos.

2. Envolver

   Funciona pero nadie quiere entrar. Se le pone una interfaz por delante y lo nuevo se construye contra ella, mientras lo de dentro se sustituye por partes. El sistema no para en ningún momento.

3. Sustituir

   Cada cambio cuesta desproporcionadamente, o la tecnología ya no recibe parches. Se sustituye por trozos y cada trozo entra en producción cuando está: nunca hay una versión paralela esperando a integrarse al final, que es donde estos proyectos se atascan.

Lo que no aparece en esta lista es reescribirlo entero de una vez. Con un sistema en producción que no puede pararse, esa opción no compite: el negocio sigue cambiando mientras dura la reescritura, y la versión nueva persigue a un objetivo que se mueve.