Lo que cuesta ir tres versiones por detrás

Una aplicación tres versiones mayores por detrás no llegó ahí por una decisión. Hubo un trimestre en el que la actualización no cabía, luego una entrega en la que un paquete aún no se había puesto al día, y luego un año en el que no se rompió nada. Y lo que tiene que un framework se quede sin soporte es que el día en que ocurre no se rompe nada.

El coste es real igualmente. Solo que está diferido, y se acumula.

La factura, desglosada

Dejan de llegar los arreglos de seguridad. Esta es la parte con fecha. Cada entrega de Laravel recibe unos dos años de arreglos de seguridad; pierda esa ventana y una vulnerabilidad revelada en el framework no tiene parche que usted pueda aplicar. El arreglo existe: está en una versión que su aplicación no puede instalar.

Sus dependencias se van sin usted. Los paquetes siguen al framework. Un año por detrás, está fijando una versión o dos. Tres años por detrás, el paquete que necesita ha dejado de soportar su restricción del todo, e instalar cualquier cosa nueva significa resolver un grafo que no tiene solución. Composer se lo cuenta de la manera menos útil disponible.

PHP se queda sin soporte por debajo. Las versiones de Laravel arrastran requisitos de PHP, y el PHP antiguo deja de recibir arreglos de seguridad según su propio calendario. Ahora el lenguaje, el framework y los paquetes tienen que moverse todos, y tienen que moverse en un orden.

Contratar se vuelve más difícil y la incorporación más lenta. Una desarrolladora que lleva tres años en Laravel no ha visto nunca las convenciones de su versión. Toda la documentación que encuentra describe otra cosa. El argumento más fuerte del propio framework - que cualquier persona que sepa Laravel puede leer cualquier código Laravel - deja de aplicarse al suyo.

El trabajo mismo se ralentiza. No porque la versión antigua sea lenta, sino porque todo es un apaño. Funcionalidades que en el Laravel actual son una línea son aquí un paquete, o un trait, o cuatrocientas líneas que alguien escribió en 2019 y luego se fue.

Por qué empeora en lugar de quedarse igual

Una actualización de una versión a la siguiente es casi mecánica. Los cambios incompatibles están documentados, suelen ser pocos, y las notas de la entrega le dicen dónde mirar.

Tres versiones no son tres veces ese trabajo, por dos motivos.

Los cambios interactúan. Una deprecación introducida en una entrega y retirada dos después es invisible en las guías de actualización individuales e inevitable cuando las hace juntas. Y no se puede avanzar limpiamente, porque los paquetes que le habrían llevado por las versiones intermedias ya no tienen versiones que satisfagan los dos extremos.

Así que el trabajo deja de ser aplicar la guía y pasa a ser entender qué hace realmente esta aplicación, que es caro precisamente porque hoy no lo sabe nadie.

Qué aspecto tiene bien hecho

Leer antes de escribir. Qué hace la aplicación, qué partes tienen pruebas, qué dependencias están abandonadas, qué PHP necesita. Eso produce un documento y una secuencia, y es la parte que la gente quiere saltarse.

Conseguir primero una red. Una actualización sin pruebas es una reescritura con pasos de más. Pruebas de funcionalidad sobre las rutas que mueven dinero y los trabajos que tocan otros sistemas suelen bastar; no cobertura completa, que cuesta más que la actualización.

El lenguaje primero donde aplique. Si PHP tiene que moverse, se mueve antes que el framework, porque el framework no puede.

Una versión cada vez, integrada cada vez. Actualizar, arreglar, desplegar, repetir. Cada paso es lo bastante pequeño para razonarlo y para revertirlo. Una única rama intentando las tres acaba como un conflicto de fusión con una fecha límite enganchada.

Borrar por el camino. Tres versiones de apaños acumulados incluyen algunos que existen solo porque entonces el framework no podía hacerlo. Ahora puede. Esos borrados son la parte del trabajo que se paga dos veces.

El número que conviene saber

La versión honesta de la cuenta: una actualización hecha cada año es un coste pequeño y predecible. Dejada tres, el mismo trabajo cuesta varias veces más, no porque el código haya cambiado más, sino porque hay que reconstruir el conocimiento de lo que hace la aplicación antes de poder mover nada con seguridad.

Y la acumulación no se detiene mientras usted decide. Otro año añade otra versión, otro conjunto de dependencias abandonadas, y otro grupo de personas que se han ido de la empresa desde que alguien entendía el módulo de pagos.

Si está leyendo esto porque ya sabe que va por detrás, el primer paso útil no es un presupuesto. Es averiguar exactamente cuánto, en qué orden tienen que moverse las cosas, y qué partes de la aplicación no sabe explicar nadie ahora mismo, porque esa última lista es de lo que está hecho el precio en realidad.

Leer la aplicación es una auditoría. Moverla es actualizaciones y rescate. Una vez al día, mantenerla al día es una tarea mensual pequeña, y ese es todo el argumento a favor de un acuerdo de mantenimiento.

Si la aplicación no está en Laravel, el mismo interés se acumula sobre el framework en el que esté. Las traemos por partes. No las reescribimos.