--- title: "Software en una versión sin soporte: qué hacer" description: "Qué pasa cuando PHP, Node, .NET o tu framework llegan a fin de soporte: riesgos reales, cómo hacer inventario y cómo actualizar por saltos sin parar." canonical: https://caricalia.com/notas/aplicacion-version-sin-soporte last-updated: 2026-10-09 --- # Software en una versión sin soporte: qué hacer > Una versión sin soporte no deja de funcionar el día que caduca. Deja de recibir parches, y a partir de ahí el riesgo y el coste de actualizar crecen cada mes. Publicado: 2026-10-09 Autor: carlos Temas: mantenimiento, legacy, actualizaciones --- ## Qué hacer si tu aplicación usa una versión sin soporte Si tu aplicación corre sobre una versión de lenguaje, framework o base de datos sin soporte, no se va a apagar mañana. Lo que ha cambiado es que nadie publica ya parches de seguridad para esa versión. Haz primero un inventario de todo lo que tiene fecha de caducidad. Después actualiza por saltos, una versión mayor cada vez, con el sistema en marcha. Reescribir solo tiene sentido si el negocio ya no se parece a lo que hace la aplicación. Esta situación casi siempre aparece en un software heredado, cuando se ha ido quien lo mantenía. Es uno de los primeros puntos que miramos al hacernos cargo de un sistema en [mantenimiento de software](/mantenimiento-de-software). ## Qué significa que una versión llegue a fin de soporte Cada proyecto publica una política de soporte con fechas. Durante un tiempo, la versión recibe correcciones de errores. Después, solo parches de seguridad críticos. Cuando termina esa segunda fase, la versión llega a su fin de vida y no recibe nada más. PHP lo explica así en su [página de versiones soportadas](https://www.php.net/supported-versions.php): cada rama tiene dos años de soporte activo desde su lanzamiento y dos años más solo para problemas de seguridad críticos. Laravel da 18 meses de correcciones y dos años de parches de seguridad por versión, según su política recogida en [endoflife.date](https://endoflife.date/laravel). Las fechas de las versiones que más encontramos en sistemas heredados, a 9 de octubre de 2026: | Tecnología | Versión | Fin del soporte de seguridad | Fuente | |---|---|---|---| | PHP | 5.6 | 31 de diciembre de 2018 | [endoflife.date](https://endoflife.date/php) | | PHP | 7.4 | 28 de noviembre de 2022 | [endoflife.date](https://endoflife.date/php) | | PHP | 8.1 | 31 de diciembre de 2025 | [endoflife.date](https://endoflife.date/php) | | PHP | 8.2 | 31 de diciembre de 2026 | [php.net](https://www.php.net/supported-versions.php) | | Node.js | 18 | 30 de abril de 2025 | [endoflife.date](https://endoflife.date/nodejs) | | Node.js | 20 | 30 de abril de 2026 | [endoflife.date](https://endoflife.date/nodejs) | | .NET | 6 | 12 de noviembre de 2024 | [endoflife.date](https://endoflife.date/dotnet) | | .NET | 8 | 10 de noviembre de 2026 | [endoflife.date](https://endoflife.date/dotnet) | | AngularJS | 1.8 | 31 de diciembre de 2021 | [endoflife.date](https://endoflife.date/angularjs) | | Laravel | 10 | 4 de febrero de 2025 | [endoflife.date](https://endoflife.date/laravel) | | MySQL | 5.7 | 31 de octubre de 2023 | [endoflife.date](https://endoflife.date/mysql) | | MySQL | 8.0 | 30 de abril de 2026 | [endoflife.date](https://endoflife.date/mysql) | Fíjate en las filas con fecha de 2026. PHP 8.2 y .NET 8 dejan de recibir parches en las próximas semanas. Si tu sistema está ahí, el plan de actualización tendría que estar ya escrito. ## Qué riesgos tiene seguir en una versión sin soporte El riesgo no es que la aplicación falle un día concreto. Son cuatro cosas que van llegando poco a poco, y cada una sube el precio de la siguiente. **Los fallos de seguridad se quedan abiertos.** La propia página de PHP lo dice de las versiones sin soporte: quien las use puede estar expuesto a vulnerabilidades sin parchear y debería actualizar cuanto antes. Cuando se publica un fallo nuevo, las versiones con soporte reciben el arreglo y la tuya no. **El proveedor de alojamiento te empuja.** Los proveedores dejan de ofrecer versiones viejas, o las cobran aparte. Amazon lo hace con sus bases de datos gestionadas: desde el 1 de marzo de 2024 cobra un suplemento a quien sigue en MySQL 5.7, y al acabar ese periodo extra actualiza la versión mayor por su cuenta, según su [documentación de RDS Extended Support](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/extended-support.html). Esa actualización automática se hace en la fecha que fija el proveedor, no cuando tú estás preparado. **Las librerías dejan de funcionar con tu versión.** Las piezas de terceros que usa tu aplicación sacan versiones nuevas que exigen un lenguaje reciente. Si no puedes actualizar el lenguaje, tampoco puedes actualizar la librería. Así te quedas también sin sus parches. **Los servicios externos suben sus requisitos.** Pasarelas de pago, bancos, servicios de correo y administraciones endurecen sus conexiones cada cierto tiempo. Stripe, por ejemplo, exige que las páginas de pago usen TLS 1.2 o superior, según su [guía de seguridad](https://docs.stripe.com/security/guide). Un servidor muy antiguo puede no saber conectar así, y el problema aparece el día que cobrar deja de funcionar. ## Cómo saber qué versiones tiene tu sistema Antes de decidir nada hace falta una lista. Cuesta poco hacerla y casi nadie la tiene. | Qué revisar | Dónde se ve | |---|---| | Versión del lenguaje (PHP, Node.js, .NET, Java, Python) | En el servidor y en los ficheros de configuración del proyecto | | Versión del framework | En el fichero de dependencias: `composer.json`, `package.json`, el `.csproj` | | Librerías de terceros | En el fichero de bloqueo de dependencias: `composer.lock`, `package-lock.json` | | Base de datos | En el panel del proveedor o con una consulta de versión | | Sistema operativo del servidor | En el propio servidor o en el panel del alojamiento | | Servicios externos y sus requisitos | En los avisos que mandan a la cuenta de correo del administrador | La última fila es la que más se pierde cuando se va quien mantenía el sistema. Esos avisos llegan, con meses de antelación, a un correo que ya no lee nadie. Qué cuentas hay que recuperar primero lo contamos en [software que depende de una sola persona](/notas/software-depende-de-una-persona). Con la lista hecha, marca al lado de cada pieza su fecha de fin de soporte. Ese calendario es tu plan de mantenimiento de los próximos dos años. ## Cómo se actualiza sin parar el sistema La regla que más ahorra es saltar versiones mayores de una en una. Pasar de PHP 7.4 a 8.4 de golpe junta en un solo cambio todo lo que se rompió en cada versión intermedia. Cuando algo falla, no sabes cuál de ellas lo ha provocado. El orden que seguimos: 1. **Una copia que se ha restaurado.** Antes de tocar nada, una copia de seguridad que se ha restaurado en otro entorno para comprobar que sirve. 2. **Un entorno de pruebas igual al real.** Con la misma versión de todo y datos parecidos a los de producción. 3. **Comprobaciones de lo que no puede romperse.** Antes de actualizar, se escriben pruebas automáticas de lo que mueve dinero: cobrar, facturar, registrar un pedido. Si el sistema no tiene ninguna, este es el paso más largo y el que más vale. 4. **Primero las librerías, después el lenguaje.** Se suben las dependencias a la última versión que aún admite tu lenguaje actual. Luego se sube el lenguaje un salto. 5. **Un salto, a producción, y el siguiente.** Cada salto se publica y se deja funcionar unos días antes del siguiente. Si algo falla, se vuelve atrás un solo paso. Hay una excepción conocida: cuando el framework no tiene sucesor directo. AngularJS y Angular, por ejemplo, son proyectos distintos, y pasar de uno a otro es una migración, no una actualización. Ahí se aplica la sustitución por partes de la que hablamos en [reescribir o refactorizar](/notas/reescribir-o-refactorizar). ## Cuándo compensa actualizar y cuándo sustituir | Actualiza si | Plantéate sustituir si | |---|---| | La aplicación sigue haciendo lo que el negocio necesita | Media empresa trabaja con hojas de cálculo al lado del sistema | | El framework tiene sucesor directo | El framework no tiene sucesor y la migración equivale a rehacerla | | Hay una persona que entiende las reglas de negocio | Nadie sabe ya qué hace cada parte, ni hay forma de averiguarlo | | Tus datos y tu forma de trabajar están dentro, y migrarlos sería caro | Un producto estándar hace lo mismo y migrar los datos es sencillo | En la mayoría de los sistemas que vemos, la respuesta es actualizar. Lo caro de un sistema heredado rara vez es el lenguaje: son las reglas de negocio que solo están escritas en el código. Esas reglas se pierden al reescribir, y casi nunca se recuperan todas. Lo contamos con más detalle en [un sistema legacy es código sin dueño](/notas/sistema-legacy-codigo-sin-dueno). ## Cuánto cuesta ponerse al día Depende de cuántas versiones tengas que saltar, de si hay pruebas automáticas y de cuántas librerías hayan quedado abandonadas por el camino. No hay una cifra publicada que sirva para tu caso. Sí hay una regla útil: cuanto más se espera, más saltos se acumulan y más librerías dejan de tener versión compatible. Si el sistema está en mantenimiento continuo, estas subidas entran en la cuota. Cómo se calcula el coste del mantenimiento, y qué modelos de contrato hay, lo explicamos en [cuánto cuesta el mantenimiento de un software](/notas/cuanto-cuesta-mantenimiento-software). ## Preguntas frecuentes ### ¿Mi aplicación va a dejar de funcionar cuando acabe el soporte? No ese día. Sigue funcionando igual, pero deja de recibir parches de seguridad. Lo que suele romperla después es un cambio externo: el alojamiento retira la versión, una librería deja de ser compatible o un servicio de pago endurece su conexión. ### ¿Puedo seguir en PHP 7.4? Funcionar, funciona, pero no recibe parches de seguridad desde el 28 de noviembre de 2022. Cada mes que pasa hay más librerías que no lo admiten y más alojamientos que lo retiran o lo cobran aparte. ### ¿Es mejor saltar directamente a la última versión? No en un solo paso. Se llega a la última, pero pasando por cada versión mayor intermedia, publicando cada salto en producción antes del siguiente. Así, cuando algo falla, sabes qué lo ha roto. ### ¿Cuánto tarda una actualización de versión? Depende sobre todo de si el sistema tiene pruebas automáticas. Con pruebas, cada salto se comprueba en poco tiempo. Sin ellas, escribirlas es la parte más larga. ### ¿Quién debería avisarme de que una versión caduca? Quien mantiene el sistema. Si no hay nadie, los avisos de los proveedores llegan a un correo que no lee nadie. Por eso el inventario de versiones va al principio de cualquier traspaso. Si tu sistema tiene piezas caducadas y no sabes por dónde empezar, en el [diagnóstico](/diagnostico) hacemos el inventario y el plan de saltos con el código delante.