El 31 de diciembre de 2026 termina el soporte de seguridad de PHP 8.2 por parte del proyecto PHP. Si tu sitio utiliza esa rama, este trimestre es un buen momento para preparar el cambio: averiguar qué ejecuta, ensayar una versión compatible y acordar cómo regresar si aparece un problema. Fuente: calendario oficial de soporte de PHP (abre en otra pestaña).
La fecha no apaga tu página automáticamente. Señala el fin de una etapa de mantenimiento del motor que ejecuta su código. Un sitio puede seguir mostrando su portada y, al mismo tiempo, necesitar una decisión sobre la plataforma que lo sostiene. Esperar a que algo falle convierte una actualización planificable en una tarea que compite con la operación diaria.
El calendario del motor también pertenece al negocio
PHP es una de las piezas con las que se ejecutan aplicaciones web. El dueño del sitio suele ver contenidos, pedidos y formularios; el proveedor ve además versiones, extensiones y configuración. Para decidir bien, ambas conversaciones tienen que encontrarse en una pregunta concreta: ¿qué actividades deben seguir funcionando después del cambio?
El calendario oficial distingue soporte activo, correcciones de seguridad y fin de vida. PHP 8.2 ya está en la segunda etapa. Las ramas 8.3, 8.4 y 8.5 tienen horizontes diferentes; eso permite comparar opciones sin confundir «todavía funciona» con «sigue recibiendo mantenimiento». Las fechas siguientes corresponden al proyecto PHP, no a compromisos adicionales que un proveedor pudiera ofrecer por separado.
| Rama | Fin del soporte de seguridad |
|---|---|
| PHP 8.2 | 31 de diciembre de 2026 |
| PHP 8.3 | 31 de diciembre de 2027 |
| PHP 8.4 | 31 de diciembre de 2028 |
| PHP 8.5 | 31 de diciembre de 2029 |
No elijas una rama sólo por la última fecha de la tabla. Antes hay que confirmar qué versiones admite la aplicación, qué componentes están mantenidos y qué ofrece el entorno de alojamiento. Si el proveedor habla de soporte extendido, pide su alcance, responsable y vigencia por escrito; no lo deduzcas del número que muestra el panel.
La portada es la parte fácil del examen
Pensemos en una tienda hipotética. La persona encargada cambia la versión en su panel, abre el inicio y ve las mismas fotografías. Da la tarea por terminada. Sin embargo, todavía faltan los recorridos que sostienen la venta: iniciar sesión, calcular un envío, confirmar un pedido y recibir su aviso. Este ejemplo no describe una falla observada; muestra por qué conviene definir la prueba antes de tocar el entorno.
Las diferencias entre versiones pueden alcanzar funciones y extensiones. Por ejemplo, la guía de PHP 8.4 documenta cambios de comportamiento de exit() y modificaciones en los tipos que devuelven algunas extensiones. Un componente que depende de esos detalles puede necesitar adaptación. No significa que cada sitio vaya a fallar, sino que la compatibilidad requiere revisar lo que utiliza. Fuente: cambios incompatibles al migrar a PHP 8.4 (abre en otra pestaña).
En WordPress hay otra distinción útil. Sus requisitos recomiendan PHP 8.3 o superior, pero esa recomendación general no certifica cada tema, plugin o personalización instalada en tu sitio. Usa la referencia para conversar con el proveedor y completa la revisión con el inventario real. Fuente: requisitos oficiales de WordPress (abre en otra pestaña).
Preparar una actualización que alguien pueda aceptar
Solicita una propuesta pequeña y comprobable. Debe identificar la versión actual, la versión candidata, los componentes que necesitan revisión y los recorridos que se probarán. También debe decir quién autoriza el cambio y quién puede ejecutarlo. Así evitas que «actualizar PHP» signifique una cosa para administración y otra para quien mantiene el código.
- Levantar el inventario. Confirmar el entorno que atiende el sitio, las extensiones necesarias y las versiones de sus componentes. Incluir tareas programadas o procesos que no pasan por la portada.
- Ensayar en un entorno separado. Usar una copia controlada con configuración representativa. Aislar correos, pagos y conexiones para que las pruebas no contacten clientes ni produzcan operaciones reales.
- Probar el trabajo importante. Definir entradas de prueba y resultados esperados. Revisar formularios, acceso, archivos y operaciones específicas del negocio, junto con los registros de errores.
- Acordar la entrega y recuperación. Preparar respaldo, ventana, responsables y condiciones para detenerse. Identificar qué datos nuevos podrían aparecer durante el cambio antes de diseñar una reversión.
- Comprobar después de publicar. Repetir los recorridos acordados en producción de forma controlada y observar el comportamiento durante la ventana definida.
Esta secuencia es una propuesta editorial para organizar el trabajo; no sustituye el procedimiento del proveedor ni describe una migración que hayamos ejecutado en tu sistema. Su ventaja es que permite hablar de resultados: qué formulario se comprobó, qué pedido de prueba se revisó y qué persona confirmó el funcionamiento.
En proyectos que usan Composer, el equipo técnico cuenta con check-platform-reqs para comprobar requisitos de PHP y extensiones de los paquetes instalados contra la plataforma real. Es una comprobación útil de dependencias, aunque no recorre por sí misma las funciones del negocio. Fuente: documentación de Composer (abre en otra pestaña).
Si algo impide migrar, nómbralo
Un plugin sin mantenimiento, una integración antigua o la falta de código fuente requieren decisiones distintas. Pide que el impedimento quede identificado: qué componente es, quién lo mantiene, qué alternativa existe y qué trabajo falta. «El sitio es viejo» no ayuda a elegir entre sustituir una pieza, adaptar código o planear una modernización más amplia.
Acinsoft puede ayudarte a evaluar el alojamiento y las dependencias del sitio desde su servicio de hosting e infraestructura (abre en otra pestaña), delimitando qué corresponde al entorno y qué necesita trabajo de desarrollo. Ese diagnóstico permite preparar una propuesta sin asumir que cambiar una opción del panel resolverá cada incompatibilidad.
Al terminar la actualización, conserva una ficha breve: versión entregada, fecha, recorridos comprobados, responsable y siguiente revisión. La próxima vez que alguien pregunte si el sitio está mantenido, tendrás una respuesta que va más allá de abrir la página de inicio.
Corte de información: 3 de octubre de 2026. Fechas del proyecto PHP; compatibilidad y posibles servicios extendidos deben comprobarse en cada instalación.
