¿Por qué hay que actualizar PHP ahora?
Porque PHP 8.1 dejó de recibir parches de seguridad el 31 de diciembre de 2025 y PHP 8.2 los pierde el 31 de diciembre de 2026. PHP 7.4 está sin soporte desde noviembre de 2022. Cuando sale una falla grave, esas versiones se quedan sin arreglo oficial. PHP 8.4 tiene parches de seguridad hasta el 31 de diciembre de 2028.
No es una fecha teórica. En octubre de 2026 salió PHP2Shell, una falla crítica que permite tomar un servidor sin contraseña. Las ramas con soporte recibieron parche el mismo día. PHP 7.4, 8.0 y 8.1 no: quien sigue ahí depende del paquete de su distribución, de un backport o de migrar a la carrera. Las fechas vienen de la tabla oficial de versiones de PHP y de la lista de ramas sin soporte.
| Rama | Parches de seguridad hasta | Estado al 25-oct-2026 |
|---|---|---|
| 7.4 | 28-nov-2022 | sin soporte |
| 8.0 | 26-nov-2023 | sin soporte |
| 8.1 | 31-dic-2025 | sin soporte |
| 8.2 | 31-dic-2026 | solo seguridad, quedan semanas |
| 8.3 | 31-dic-2027 | solo seguridad |
| 8.4 | 31-dic-2028 | soporte completo hasta el 31-dic-2026 |
| 8.5 | 31-dic-2029 | soporte completo |
¿Qué se rompe al pasar de PHP 7.4 a 8.4?
La mayor parte del trabajo está en el primer salto, de 7.4 a 8.0. Las versiones siguientes agregan avisos de funciones obsoletas («deprecated») que no rompen el sistema de inmediato, pero llenan los logs y se vuelven errores en versiones futuras. Este es el resumen de las guías oficiales de migración de PHP, con lo que más vemos fallar en código de empresas.
De 7.4 a 8.0: el salto grande
- Comparaciones entre número y texto: «0 == "foo"» ahora es falso. Formularios que mandan campos vacíos y se comparan contra 0 cambian de comportamiento sin dar error.
- Funciones eliminadas: «each()», «create_function()», «money_format()», «get_magic_quotes_gpc()» y otras. El sistema truena con «undefined function».
- Muchos avisos ahora son excepciones: «count()» sobre algo que no es contable o aritmética con arreglos lanzan «TypeError». Lo que antes pasaba en silencio ahora detiene la página.
- La arroba «@» ya no oculta errores fatales y «error_reporting» viene en «E_ALL» por defecto. Revisa que «display_errors» esté apagado en producción.
- «match» y «mixed» son palabras reservadas, los ternarios anidados necesitan paréntesis y los constructores con el nombre de la clase ya no funcionan.
- PDO trabaja en modo de excepciones por defecto: consultas que fallaban sin avisar ahora lanzan error.
La lista completa está en la guía de cambios incompatibles de PHP 8.0.
De 8.0 a 8.1, 8.2 y 8.3: avisos que se acumulan
- 8.1: pasar «null» a parámetros de funciones internas que no lo aceptan está obsoleto («strlen(null)», «str_contains($x, null)»). En código viejo aparece miles de veces. También quedan obsoletos «strftime()», «FILTER_SANITIZE_STRING» y las funciones «mhash», según la lista de PHP 8.1.
- 8.2: crear propiedades dinámicas en objetos queda obsoleto, salvo que la clase use «#[\AllowDynamicProperties]». También «utf8_encode()», «utf8_decode()» y la interpolación «${var}» dentro de textos, según la lista de PHP 8.2.
- 8.3: cambios puntuales, como «range()» más estricto y «number_format()» con decimales negativos, en la guía de PHP 8.3.
De 8.3 a 8.4: extensiones y tipos
- Las extensiones IMAP, OCI8, PDO_OCI y PSpell salieron del paquete de PHP y ahora se instalan desde PECL. Si tu sistema lee correo por IMAP o se conecta a Oracle, revisa esto primero, según la nota de extensiones retiradas.
- Parámetros con valor por defecto «null» sin tipo nulo explícito («function f(Tipo $a = null)») quedan obsoletos. Se corrige con «?Tipo $a = null».
- «trigger_error()» con «E_USER_ERROR» y la constante «E_STRICT» quedan obsoletos; «exit()» se comporta como función.
- El JIT de OPcache viene apagado por defecto y varias funciones lanzan «ValueError» donde antes solo avisaban. Detalle en las páginas de cambios y obsoletos de 8.4.
¿Cómo actualizar PHP paso a paso sin romper producción?
La regla es simple: nunca cambies la versión de PHP directo en producción. Se prepara en una copia, se prueba, se sube por etapas y siempre hay un camino de regreso. Así lo hacemos:
- Inventario. Lista cada servidor, contenedor y hosting donde corre PHP, con su versión real de PHP-FPM o del módulo de Apache (puede ser distinta a la de «php -v»). Incluye tareas programadas y scripts que corren por cron con otro binario.
- Dependencias. Revisa con Composer qué paquetes no aceptan PHP 8.4 y cuáles tienen una versión nueva que sí. El framework manda: Laravel 10 solo soporta PHP 8.1 a 8.3 y Laravel 11 llega hasta 8.4, según su política de soporte. A veces hay que subir el framework antes que PHP.
- Extensiones. Compara la lista de «php -m» del servidor actual contra lo que trae la instalación nueva. Las que más faltan: IMAP, OCI8, ionCube o extensiones compiladas a mano.
- Análisis del código. Herramientas de análisis estático encuentran funciones eliminadas y avisos de compatibilidad sin correr el sistema. No sustituyen las pruebas, pero te dicen dónde mirar primero.
- Ambiente de pruebas. Una copia de producción con PHP 8.4, la misma base de datos (anonimizada si tiene datos personales) y los registros de errores encendidos con «E_ALL». Ahí corren las pruebas automáticas y un recorrido manual de los flujos que dan dinero: login, facturación, pagos, reportes.
- Salida por etapas. Instala PHP 8.4 en paralelo a la versión actual (muchas distribuciones permiten varias versiones de PHP-FPM a la vez) y cambia un sitio o un porcentaje del tráfico primero. Vigila errores y tiempos de respuesta un día antes de seguir.
- Plan de regreso. Regresar debe ser cambiar el socket de PHP-FPM en nginx o Apache y recargar, no reinstalar. Si la migración tocó la base de datos, ten respaldo probado de antes del cambio.
- Reinicio y verificación. Reinicia PHP-FPM o Apache para que tome la versión y la configuración nuevas, y confirma desde fuera qué versión responde. Deja evidencia: versión antes, versión después, pruebas que pasaron.
php -v && php -m # versión y extensiones de la terminal composer check-platform-reqs # ¿las dependencias aceptan la versión de PHP instalada? composer why-not php 8.4.0 # qué paquete bloquea PHP 8.4 composer outdated --direct # dependencias directas con versión nueva composer audit # dependencias con avisos de seguridad conocidos sudo systemctl restart php8.4-fpm # reinicio del pool nuevo sudo nginx -t && sudo systemctl reload nginx
¿Qué hago si no llego al 31 de diciembre?
Un sistema mediano con buenas pruebas puede migrar en pocas semanas. Uno sin pruebas, con código de hace diez años y dependencias abandonadas, toma más. Si sabes que no llegas, no te quedes quieto: hay pasos que bajan el riesgo mientras terminas.
- Sube primero a la última versión de tu rama actual. En 8.2, eso significa tener el último parche antes de que termine el soporte.
- Usa los paquetes de tu distribución o de un proveedor de soporte extendido, que siguen publicando correcciones para ramas viejas por un tiempo.
- Reduce la exposición: firewall o WAF delante, panel de administración solo por VPN, nada de «phpinfo()» publicado y la versión de PHP oculta en las cabeceras.
- Vigila las fallas nuevas de tu versión. Publicamos las relevantes en las alertas de la semana.
- Migra por partes: si tienes varios sistemas, empieza por los que dan a internet.
Si tu sistema está hecho en Laravel, revisa también qué pasa con Laravel 11, que ya no recibe parches. Y si tienes sitios en WordPress, la versión de PHP del hosting importa igual: un WordPress hackeado muchas veces empieza por un servidor viejo.
Cuéntanos qué sistema tienes, en qué versión de PHP corre y dónde está alojado. Te respondemos con los siguientes pasos.
Planear mi migración a PHP 8.4Preguntas frecuentes
¿Cómo sé qué versión de PHP tengo?
En el servidor, con «php -v» en la terminal o con «phpinfo()» en una página temporal que borras después. Revisa también la versión de PHP-FPM o del módulo de Apache, que puede ser otra. En hosting compartido, está en el panel de control.
¿PHP 7.4 todavía es seguro?
No. PHP 7.4 dejó de recibir parches de seguridad el 28 de noviembre de 2022. Las fallas que se descubren desde entonces no tienen arreglo oficial, como pasó con PHP2Shell en octubre de 2026.
¿Cuándo termina el soporte de PHP 8.2?
El 31 de diciembre de 2026. Después de esa fecha PHP 8.2 ya no recibe parches de seguridad. PHP 8.1 terminó el 31 de diciembre de 2025.
¿Puedo saltar directo de PHP 7.4 a 8.4?
Sí, no hace falta instalar cada versión intermedia. Pero sí hay que revisar los cambios de cada una (8.0, 8.1, 8.2, 8.3 y 8.4), porque el código tiene que cumplir con todos. La mayoría de los problemas aparecen en el salto de 7.4 a 8.0.
¿Actualizar PHP rompe mi sitio?
Puede romperlo si el código usa funciones eliminadas o depende de comportamientos que cambiaron. Por eso se prueba en una copia antes, se sube por etapas y se deja listo un camino de regreso que tome minutos.
¿Tengo que actualizar Laravel o mis librerías antes que PHP?
Muchas veces sí. Cada versión del framework soporta un rango de PHP: Laravel 10 llega hasta PHP 8.3 y Laravel 11 hasta 8.4. Revisa con «composer why-not php 8.4.0» qué paquete te bloquea.
¿Es obligatorio reiniciar PHP-FPM después de actualizar?
Sí. Los procesos que ya están corriendo siguen usando la versión y la configuración anteriores hasta que reinicias PHP-FPM o Apache.
Fuentes
- PHP: Supported Versions
- PHP: Unsupported Branches (fin de vida)
- PHP Manual: Migrating from PHP 7.4.x to PHP 8.0.x — cambios incompatibles
- PHP Manual: Migrating from PHP 8.0.x to PHP 8.1.x — funciones obsoletas
- PHP Manual: Migrating from PHP 8.1.x to PHP 8.2.x — funciones obsoletas
- PHP Manual: Migrating from PHP 8.2.x to PHP 8.3.x — cambios incompatibles
- PHP Manual: Migrating from PHP 8.3.x to PHP 8.4.x — cambios incompatibles
- PHP Manual: Migrating from PHP 8.3.x to PHP 8.4.x — funciones obsoletas
- PHP Manual: Migrating from PHP 8.3.x to PHP 8.4.x — extensiones retiradas
- Laravel: política de soporte por versión
Escrita por Samuel Hinojosa y el equipo de seguridad de WITS · Actualizada el 25 oct 2026 · Markdown
