PHP 7.4 dejó de recibir parches de seguridad el 28 de noviembre de 2022 y su última versión fue la 7.4.33. Para actualizar hay que pasar a PHP 8.3 o superior, y el trabajo real está en los cambios de PHP 8.0 que rompen código viejo.
Son casi cuatro años sin correcciones. En ese tiempo aparecieron fallas nuevas, entre ellas PHP2Shell, corregida el 21 de octubre de 2026 solo en 8.2.35, 8.3.36, 8.4.27 y 8.5.12. En DCisGlobal todavía encontramos sistemas de facturación, tiendas y CRM sobre 7.4 que parecen andar bien, pero funcionan sin red de seguridad.
Qué implica que PHP 7.4 esté sin soporte
Implica que nadie corrige las fallas que aparecen. El sitio oficial de PHP lo dice sin rodeos: quien usa una versión sin soporte puede quedar expuesto a vulnerabilidades sin parchear y debería actualizar cuanto antes.
Hay un segundo costo, menos visible. Los proveedores de hosting retiran versiones viejas, y las librerías y plugins dejan de publicar actualizaciones para 7.4. El sistema queda congelado: cada mejora cuesta más porque hay que esquivar dependencias viejas.
El contexto de la falla más reciente está en qué es PHP2Shell y qué hacer.
A qué versión conviene actualizar PHP 7.4
Directo a 8.3 o superior. PHP 8.0 y 8.1 ya están sin soporte, y 8.2 lo pierde el 31 de diciembre de 2026. Quedarse a mitad de camino obliga a repetir el proyecto en pocos meses.
PHP 8.3 tiene soporte de seguridad hasta el 31/12/2027, 8.4 hasta el 31/12/2028 y 8.5 hasta el 31/12/2029. Si las dependencias lo permiten, 8.4 o 8.5 dan más años de margen por un esfuerzo parecido.
Los cambios de PHP 7.4 a 8 que suelen romper sistemas viejos
La guía oficial «Migrating from PHP 7.4.x to PHP 8.0.x» de php.net lista los cambios incompatibles. Estos son los que más vemos en sistemas de empresa, traducidos a lo que se nota en el negocio:
| Cambio técnico | Qué se nota en el negocio |
|---|---|
| Se eliminaron funciones como create_function(), each() o money_format() | Pantallas o procesos que dejan de cargar por completo |
| Cambió la comparación entre números y textos: 0 == "foo" ya no da verdadero | Filtros, búsquedas o validaciones que devuelven otro resultado sin mostrar ningún error |
| Varios avisos pasaron a ser errores, por ejemplo count() sobre algo que no es una lista | Un reporte o un cobro que se corta a mitad de camino en lugar de seguir con un aviso |
| Los métodos con el nombre de la clase ya no actúan como constructores | Objetos que se crean sin sus datos iniciales y fallan más adelante |
| PDO, la capa de acceso a la base de datos, lanza excepciones por defecto | Errores de base de datos que antes pasaban en silencio ahora detienen la página |
| Ternarios anidados sin paréntesis y llamadas estáticas a métodos no estáticos | Código antiguo que directamente deja de ejecutarse |
| El operador @ ya no silencia errores fatales | Problemas que estaban ocultos salen a la luz |
¿Tu versión de PHP es segura?
Escribí la versión exacta que corre tu servidor y te decimos al instante si está expuesta y qué hacer.
Lo más trabajoso suele ser lo último: problemas que existían desde hace años y quedaban tapados. PHP 8 no rompe un sistema sano; deja de mirar para otro lado.
Qué cambia de PHP 8.0 a 8.3
Superado el salto a 8.0, el resto es más liviano. Las guías «Migrating from PHP 8.0.x to PHP 8.1.x», «8.1.x to 8.2.x» y «8.2.x to 8.3.x» documentan sobre todo funciones obsoletas:
- En 8.1, pasar null a funciones internas que esperan texto o número genera avisos de función obsoleta. En sistemas viejos suelen aparecer en muchos lugares y llenan los registros.
- En 8.2 quedan obsoletas las propiedades dinámicas en objetos y las funciones utf8_encode() y utf8_decode(), habituales en sistemas que mezclan codificaciones de texto.
- En 8.3, la lista de cambios incompatibles es corta y puntual.
Estos avisos no detienen el sistema, pero conviene resolverlos en el mismo proyecto para no arrastrarlos.
Qué hacer ahora
- Confirmar versión y alcance. Qué sistemas corren sobre 7.4 y en qué servidores.
- Revisar las dependencias. Framework, CMS, plugins y librerías: cuáles tienen versión compatible con PHP 8.3 y cuáles no.
- Analizar el código propio. Las herramientas de análisis estático detectan buena parte de los cambios incompatibles antes de ejecutar nada.
- Probar en una copia con PHP 8.3 o superior. Recorrer los procesos que generan ingresos: ventas, facturación y cobranzas.
- Mostrar todos los avisos en pruebas. Lo que en producción estaba oculto tiene que aparecer en el entorno de pruebas, no frente a un cliente.
- Pasar a producción con respaldo y un plan claro para volver atrás si algo falla.
El detalle del proceso está en la guía cómo actualizar PHP en sistemas sin soporte. Si el servidor muestra «PHP/8.0.30», corresponde leer PHP 8.0: vulnerabilidades y fin de soporte; para 8.1, PHP 8.1 fin de soporte: por qué pasar a PHP 8.3.
Cómo lo resolvemos en DCisGlobal
Hacemos un diagnóstico tecnológico del sistema y entregamos un plan con lo que hay que cambiar, en qué orden y con qué costo. Si actualizar no conviene, lo decimos y evaluamos un desarrollo a medida por etapas.
La migración se hace en un entorno de pruebas, se valida con tu equipo y pasa a producción con respaldo. Después podemos ocuparnos del soporte y mantenimiento para que el sistema no vuelva a quedar atrás.
