Lo que vence entre noviembre de 2026 y fin de 2027
Ocho vencimientos estructuran el calendario de un parque de sitios de clientes. Dos ya han pasado: Node.js 20 (30 de abril de 2026) y Debian 11 LTS (31 de agosto de 2026). Ya no se planifican, se recuperan. Cuatro caen en los próximos doce meses: PostgreSQL 14, PHP 8.2, Node.js 22 y Ubuntu 22.04. Dos cierran 2027: PostgreSQL 15 y PHP 8.3.
La tabla siguiente los ordena por fecha, con la fuente primaria y la acción que conviene incluir en el plan. Una regla de lectura: la fecha es la que publica el fabricante, al día exacto cuando la da, al mes cuando solo publica el mes. Nada procede de un sitio de terceros sin confirmación en la fuente. Para el detalle de una migración, siga la guía indicada en la primera columna: este artículo ordena, no rehace los tutoriales.
Calendario de fin de vida, por orden de fecha
Desplace la tabla
| Componente y guía detallada | Fin de soporte y fuente | Acción que planificar |
|---|---|---|
| Node.js 20 — guía: Node.js 20 al final de su vida, migrar su VPS | 30 de abril de 2026, ya vencido — repositorio nodejs/Release, schedule.json | Deuda: migrar a Node.js 22 o 24 sin esperar |
| Debian 11 — guía: Debian 11 al final de su vida, Plesk, dist-upgrade o migración | 31 de agosto de 2026, ya vencido — wiki.debian.org/LTS | Deuda: dist-upgrade a Debian 13 o migración |
| PostgreSQL 14 — guía: PostgreSQL al final de su vida, planificar la actualización | 12 de noviembre de 2026, última versión — postgresql.org/support/versioning | Volcado y restauración o pg_upgrade a una versión mayor soportada |
| PHP 8.2 — guía: PHP 8.2 fin de vida, lista de migración | 31 de diciembre de 2026, soporte de seguridad — php.net/supported-versions | Pasar todos los sitios a PHP 8.4, ya que PHP 8.3 termina un año después |
| Node.js 22 | 30 de abril de 2027 — repositorio nodejs/Release, schedule.json | Pasar a Node.js 24, soportado hasta el 30 de abril de 2028 |
| Ubuntu 22.04 LTS — procedimiento: Ubuntu 24.04 a 26.04, do-release-upgrade | mayo de 2027, mantenimiento de seguridad estándar — ubuntu.com/about/release-cycle | Subir a Ubuntu 24.04 antes de que empiece el mes |
| PostgreSQL 15 | 11 de noviembre de 2027, última versión — postgresql.org/support/versioning | Prever la siguiente versión mayor, con PostgreSQL 16 hasta el 9 de noviembre de 2028 |
| PHP 8.3 | 31 de diciembre de 2027, soporte de seguridad — php.net/supported-versions | Nada que hacer en los sitios que ya usan PHP 8.4 (seguridad hasta el 31 de diciembre de 2028); los demás pasan a ella |
Soporte activo, soporte de seguridad, última versión: tres sentidos de la palabra fin
Los fabricantes no entienden todos lo mismo por fin. PHP distingue dos fases: el soporte activo, que aporta correcciones de errores y de seguridad, y después el soporte de seguridad, que solo entrega correcciones críticas. PHP 8.2 salió del soporte activo el 31 de diciembre de 2024, y PHP 8.3 el 31 de diciembre de 2025. Las fechas de la tabla son, por tanto, las del soporte de seguridad: 31 de diciembre de 2026 para PHP 8.2, 31 de diciembre de 2027 para PHP 8.3. PHP 8.4 sigue en soporte activo hasta el 31 de diciembre de 2026 y en seguridad hasta el 31 de diciembre de 2028.
PostgreSQL habla de última versión: pasada la fecha, no sale ninguna versión menor más para esa versión mayor. Node.js habla del fin de vida de la línea, Debian y Ubuntu del fin del mantenimiento de seguridad estándar. En todos los casos, después de la fecha, un fallo descubierto ya no lo corrige el soporte estándar del fabricante: esa fecha, y no la caída del sitio, define el riesgo.
Cómo ordenar el parque: seis reglas de prioridad
- Primero las deudas — Node.js 20 y Debian 11 han superado su fecha de fin; pasan antes que cualquier vencimiento futuro, aunque el sitio no muestre ningún síntoma.
- Después, la fecha más cercana — el orden de la tabla es el orden de trabajo, salvo una restricción del cliente en sentido contrario.
- La tarea más larga antes que la más corta — una versión mayor de PostgreSQL exige una restauración probada; un cambio de versión de PHP se valida sitio por sitio. La primera se lanza antes.
- El sistema sostiene el resto — la versión de Debian o de Ubuntu condiciona a menudo las versiones de PHP y de bases de datos que ofrecen sus repositorios; la actualización del sistema se planifica junto con ellas.
- El cliente con varios vencimientos va primero — un sitio que acumula PHP 8.2, Node.js 20 y PostgreSQL 14 cuesta tres intervenciones si se trata componente a componente, una sola si se trata por ventana.
- La fecha incierta se trata desde su inicio — cuando el fabricante solo publica el mes, se planifica antes del mes, no el último día.
Las deudas ya vencidas: Node.js 20 y Debian 11
Dos filas de la tabla ya no son previsiones. Node.js 20 llegó a su fin el 30 de abril de 2026, y Debian 11 al fin de su soporte LTS el 31 de agosto de 2026. El error clásico es anotarlas en el presupuesto del año siguiente cuando ya están fuera de soporte. Una deuda se cuantifica y se salda; no se planifica al ritmo de un fin de vida futuro.
Para Node.js, el destino es la línea 22 o la línea 24. La 22 termina el 30 de abril de 2027 y la 24 el 30 de abril de 2028: elegir la 24 evita volver al mismo trabajo dentro de seis meses. Para Debian, el destino es Debian 13, cuyo soporte LTS termina el 30 de junio de 2030. Debian 12 es solo una etapa: su soporte LTS va del 11 de junio de 2026 al 30 de junio de 2028. Los procedimientos completos están en nuestras guías sobre Node.js 20 y sobre Debian 11; aquí no se repiten.
PostgreSQL: el vencimiento que no se recupera en el sitio
PostgreSQL 14 publica su última versión el 12 de noviembre de 2026, PostgreSQL 15 el 11 de noviembre de 2027 y PostgreSQL 16 el 9 de noviembre de 2028. El ritmo es anual, y es la única familia de la tabla en la que cambiar de versión no es una simple actualización: una versión mayor no se instala encima de la anterior, porque el formato de almacenamiento cambia de una mayor a otra.
Quedan dos vías: la copia lógica restaurada en la nueva versión (pg_dump y luego pg_restore), o pg_upgrade, que convierte el directorio de datos. En ambos casos, prevea una parada proporcional al tamaño de la base y una restauración probada antes del cambio. Para un parque, esto sitúa a PostgreSQL al frente de la cola en cuanto se acerca su fecha, aunque el sitio que lo usa sea sencillo. Los dos métodos se detallan en nuestra guía sobre la actualización de versión de PostgreSQL.
MySQL: una ausencia deliberada de la tabla
MySQL no figura en la tabla, a propósito. Una fecha de vencimiento para MySQL 8.0 circula en endoflife.date, pero no la hemos encontrado en la documentación de Oracle que hemos leído: sin fuente primaria, queda fuera. Lo que sí está establecido es el modelo de las series LTS: cinco años de soporte premier, tres años de soporte extendido y un paso de LTS a LTS sin saltarse ninguna serie. MySQL 8.4 es una serie LTS. Si algunos clientes siguen en la 8.0, la guía de migración a MySQL 8.4 sigue siendo la referencia; añada la fila a la tabla en cuanto haya leído la fecha en el fabricante.
Agrupar por cliente y por ventana: el método en siete pasos
Leer las versiones de cada servidor de cliente
En Debian o Ubuntu:
lsb_release -d. En RHEL o AlmaLinux:cat /etc/os-release. Después, para cada pila:php -v,node -v,psql --version. Una línea por servidor y por componente en una hoja de cálculo.No olvidar los contenedores
Un servidor al día puede alojar una imagen antigua. Lístelas con
docker image lsy consulte cada imagen:docker run --rm <image> php -vodocker run --rm <image> node -v.Poner su fecha de fin en cada línea
Copie la fecha de la tabla de este artículo junto a cada componente leído. La columna resultante es la única que necesitará para ordenar.
Calcular el primer vencimiento de cada cliente
Para cada cliente, conserve la fecha más próxima entre todos los servidores. Fija la ventana del cliente: todo lo que vence en los meses siguientes se une a la misma intervención.
Elegir una única ventana por cliente
PHP, Node.js y sistema en la misma intervención, con una sola copia de seguridad previa y un solo plan de vuelta atrás. La tabla de ventanas, más abajo, propone un reparto por vencimiento.
Ensayar en una copia antes de tocar producción
Restaure la copia de seguridad en una máquina de pruebas, ejecute la actualización y compruebe el sitio. En PostgreSQL, restaure el volcado y lance las consultas de la aplicación antes de cambiar.
Anotar y recalcular
Tras cada intervención, actualice la fila con la nueva versión y su fecha de fin. El calendario se recalcula solo, y la hoja de cálculo pasa a ser el registro de la agencia.
Ventanas de intervención propuestas
Desplace la tabla
| Ventana | Vencimientos cubiertos | Agrupación recomendada |
|---|---|---|
| Ventana 1: antes del 12 de noviembre de 2026 | Solo PostgreSQL 14 | Solo la actualización de PostgreSQL cabe en estos quince días; las deudas de Node.js 20 y Debian 11 se tratan en paralelo, sin esperar a esta fecha |
| Ventana 2: antes del 31 de diciembre de 2026 | PHP 8.2 | Pasar todos los sitios directamente a PHP 8.4, para evitar una segunda tarea en el año; ventana que conviene fijar antes del congelación de fin de año |
| Ventana 3: dos meses antes del 30 de abril de 2027 | Node.js 22 y Ubuntu 22.04 (mayo de 2027) | Una sola intervención: entorno de ejecución y sistema, fijada dos meses antes de la primera fecha: esperar al 30 de abril de 2027 no dejaría ningún margen |
| Ventana 4: antes del 11 de noviembre de 2027 | PostgreSQL 15 | Siguiente versión mayor con volcado y restauración o pg_upgrade, ensayada en una copia |
| Ventana 5: antes del 31 de diciembre de 2027 | PHP 8.3 | Solo afecta a los sitios que se quedaron en PHP 8.3, que pasan a PHP 8.4; puede fusionarse con la ventana 4 para los clientes que acumulan ambas |
Ubuntu 22.04: por qué «mayo de 2027» sin día
Para Ubuntu 22.04 LTS, Canonical anuncia el fin del mantenimiento de seguridad estándar en mayo de 2027, sin publicar un día. El sitio endoflife.date muestra el 1 de junio de 2027. Las dos lecturas son compatibles con un fin de mes, pero solo la redacción de Canonical es una fuente primaria; el día del otro sitio es una lectura. Por eso escribimos «mayo de 2027» y planificamos la actualización antes de que empiece el mes.
La versión siguiente, Ubuntu 24.04 LTS, se anuncia con mantenimiento estándar hasta mayo de 2029. El procedimiento do-release-upgrade se describe en nuestra guía Ubuntu 24.04 a 26.04; se aplica igual de una LTS a la siguiente, con una copia de seguridad completa antes de cada salto.
Un calendario se decide, no se delega
Las fechas de este artículo son las de su redacción: vuelva a comprobarlas en la fuente antes de planificar, porque un fabricante puede modificarlas. ServOrbit proporciona las guías; la administración de sus servidores y la conducción de las migraciones siguen siendo de su responsabilidad, guía proporcionada, sin asistencia directa. Pruebe siempre en una copia.
Ver todo el parque en una sola tabla
Un calendario de fin de vida solo tiene valor si se ve todo el parque en un mismo lugar. La plataforma para agencias de ServOrbit.com centraliza los dominios, los alojamientos y los VPS de sus clientes, con sus vencimientos de renovación: es el punto de partida del paso 1, una lista de clientes y de máquinas al día en lugar de una hoja de cálculo reconstruida cada trimestre. Los fines de vida del software no los sigue la plataforma: las versiones instaladas en cada servidor se leen en las máquinas, con los comandos de arriba, y se contrastan con esta tabla.
La documentación oficial
Versiones de PHP soportadas: https://www.php.net/supported-versions.php
Política de versiones de PostgreSQL: https://www.postgresql.org/support/versioning/
Calendario de versiones de Node.js: https://github.com/nodejs/Release/blob/main/schedule.json
Debian LTS: https://wiki.debian.org/LTS
Ciclo de versiones de Ubuntu: https://ubuntu.com/about/release-cycle
Versiones de MySQL y series LTS: https://dev.mysql.com/doc/refman/8.4/en/mysql-releases.html
Fechas de Ubuntu en endoflife.date: https://endoflife.date/ubuntu
