Actualizar PHP sin romper tu sistema: guía paso a paso

Para actualizar PHP sin romper tu sistema necesitas cinco cosas: elegir una versión con soporte vigente (a octubre de 2026, PHP 8.4 u 8.5), hacer un inventario de código y dependencias, probar en un ambiente idéntico al de producción, corregir con ayuda de herramientas como PHPCompatibility y Rector, y cortar con un plan de reversa listo. El cambio de versión en sí toma minutos; lo que evita sorpresas es todo lo que haces antes.

Este artículo es la continuación práctica de nuestra guía sobre PHP2Shell, la vulnerabilidad crítica de PHP de octubre de 2026. Ahí explicamos la urgencia: aplicar el parche de tu rama hoy y, si estás en PHP 8.1 o anterior, planear la migración porque no habrá versión oficial corregida. Aquí te explicamos cómo hacer esa migración de rama, por ejemplo de PHP 7.4 u 8.0 a 8.4, sin detener tu operación.

¿Por qué no basta con cambiar la versión en el panel?

Porque cambiar de rama no es lo mismo que aplicar un parche. Pasar de 8.3.35 a 8.3.36 corrige fallas sin cambiar el comportamiento del lenguaje; pasar de 7.4 a 8.4 atraviesa cinco versiones con cambios incompatibles, funciones eliminadas y avisos que ahora detienen la ejecución.

Definición rápida: una rama de PHP es la serie de versiones que comparten los dos primeros números (8.3, 8.4). Dentro de una rama solo llegan correcciones; al cambiar de rama cambian funciones, reglas y comportamientos del lenguaje.

En un sitio pequeño y bien mantenido, el salto puede salir a la primera. En un sistema administrativo o un ERP web con años de historia, lo normal es que algo falle: un reporte que ya no cuadra, una librería de PDF que truena o un plugin que deja la pantalla en blanco. El problema no es que falle, sino que falle en producción frente a tus usuarios.

¿A qué versión de PHP conviene actualizar?

La referencia oficial es la tabla de versiones soportadas de PHP. A octubre de 2026 se ve así:

Rama	Lanzamiento	Soporte activo hasta	Parches de seguridad hasta	Estado
PHP 8.5	20 nov 2025	31 dic 2027	31 dic 2029	Soporte activo
PHP 8.4	21 nov 2024	31 dic 2026	31 dic 2028	Soporte activo
PHP 8.3	23 nov 2023	31 dic 2025	31 dic 2027	Solo seguridad
PHP 8.2	8 dic 2022	31 dic 2024	31 dic 2026	Solo seguridad, termina este año
PHP 8.1 y anteriores	—	—	Terminado	Sin soporte

Cómo decidir:

• PHP 8.4 es la opción más segura para la mayoría de los sistemas en producción: lleva casi dos años en el mercado, los frameworks y librerías populares ya la soportan y tiene parches hasta finales de 2028.
• PHP 8.5 te da un año más de vida útil, pero confirma antes que todas tus dependencias la soportan oficialmente.
• PHP 8.3 solo tiene sentido como paso intermedio o si una dependencia crítica todavía no soporta 8.4. Te deja con poco más de un año de parches.
• PHP 8.2 no es destino: deja de recibir parches el 31 de diciembre de 2026.

Si usas WordPress, su página de requisitos recomienda PHP 8.3 o superior; revisa también los requisitos de tu tema y de tus plugins.

Paso 1: haz el inventario antes de tocar nada

La mayoría de las migraciones que salen mal fallan aquí, no en el código. Antes de estimar tiempos, documenta:

1. Qué sistemas tienes y dónde corren. Sitio web, tienda, portal de clientes, sistema interno, scripts programados (cron) y APIs. Es común olvidar un script que genera reportes cada noche o una integración con un proveedor.
2. La versión exacta de PHP de cada uno. En la web y en la terminal, porque pueden ser distintas. Si no sabes cómo revisarla, la guía de PHP2Shell lo explica para WordPress, cPanel, Hostinger y servidores propios.
3. Framework y versión. Laravel, Symfony, CodeIgniter, Yii, WordPress o PHP “puro”. Cada framework tiene su propia tabla de versiones de PHP soportadas, y muchas veces actualizar PHP obliga a actualizar el framework.
4. Extensiones de PHP que usa el sistema. Por ejemplo mysqli, pdo_mysql, gd, intl, soap, openssl, zip. Alguna extensión vieja puede ya no existir en la versión nueva.
5. Dependencias de Composer (si hay composer.json) o librerías copiadas a mano dentro del proyecto (el caso típico en sistemas viejos).
6. Integraciones externas: timbrado de facturación electrónica, bancos, pasarelas de pago, paqueterías. Algunas usan SDK en PHP que también deben actualizarse.
7. Quién conoce el sistema. Si nadie del equipo original está disponible, súmalo como riesgo y planea más tiempo de pruebas.

El resultado de este paso es una lista priorizada: qué sistemas están expuestos a internet, cuáles son críticos para facturar o vender, y cuáles pueden esperar.

Paso 2: arma un ambiente de pruebas que se parezca a producción

Sin un ambiente de pruebas, cada actualización se vuelve una apuesta. Lo que necesitas es una copia del sistema con la versión nueva de PHP, lo más parecida posible a producción:

• Mismo sistema operativo y servidor web (Apache con PHP-FPM, Nginx, LiteSpeed) y las mismas extensiones.
• Copia reciente de la base de datos, anonimizando datos sensibles de clientes si el ambiente lo van a usar personas externas.
• Integraciones en modo de pruebas. Usa el ambiente de pruebas del PAC para timbrar, sandbox de la pasarela de pagos y cuentas de correo de prueba. No dejes que una copia del sistema envíe facturas o correos reales a tus clientes.
• Contenedores cuando sea posible. Con Docker puedes levantar la misma aplicación con PHP 7.4 y con PHP 8.4 lado a lado y comparar resultados.

Muchos hostings compartidos ofrecen un entorno de pruebas (staging) con un clic. En un VPS o en la nube, el ambiente de pruebas es un servidor o contenedor adicional; en nube e infraestructura es parte de lo que dejamos configurado.

Paso 3: encuentra las incompatibilidades con herramientas

Revisar a mano miles de archivos no escala. Hay dos herramientas de código abierto que hacen la mayor parte del trabajo pesado.

PHPCompatibility: el diagnóstico

PHPCompatibility es un conjunto de reglas para PHP_CodeSniffer que analiza tu código y te dice qué no es compatible con una versión o rango de versiones. Para analizar código contra PHP 8 necesitas la versión 10 (a octubre de 2026 se publica como versión de desarrollo; la última estable, 9.3.5, es de 2019 y no cubre los cambios de PHP 8). Se instala con Composer, como indica su documentación. Por ejemplo, para revisar compatibilidad con PHP 8.4 en adelante:

phpcs -p . --standard=PHPCompatibility --runtime-set testVersion 8.4-

Te entrega una lista de archivos y líneas con funciones eliminadas, sintaxis obsoleta y cambios de comportamiento. Dos advertencias: el propio proyecto aclara que su cobertura no es total, y al ser un análisis estático no detecta problemas que solo aparecen al ejecutar el código (por ejemplo, un null que llega donde antes llegaba texto). Úsalo como mapa, no como garantía.

Rector: las correcciones automáticas

Rector reescribe código automáticamente aplicando reglas. Su configuración básica para subir de versión es:

<?php

use Rector\Config\RectorConfig;

return RectorConfig::configure()
    ->withPaths([__DIR__ . '/src'])
    ->withPhpSets();

Con withPhpSets() vacío, Rector toma la versión de PHP declarada en tu composer.json (por eso primero hay que subir ahí la versión destino, por ejemplo "php": "^8.4") y aplica los cambios necesarios para llegar a ella. Recomendaciones de uso:

• Córrelo primero con --dry-run para ver los cambios sin aplicarlos.
• Aplica los cambios en una rama de Git aparte y revísalos como cualquier otro cambio de código.
• Avanza por partes (una carpeta o un módulo a la vez) para que la revisión sea manejable.

Qué cambios vas a encontrar con más frecuencia

Origen	Cambio típico	Qué hacer
Sistemas en PHP 5	Funciones mysql_* (eliminadas desde PHP 7.0)	Migrar a PDO o mysqli, idealmente con consultas preparadas
PHP 7.x → 8.0	Eliminación de each(), create_function() y otras funciones	Reemplazar por foreach, funciones anónimas, etc.
PHP 7.x → 8.0	Comparación entre texto y número cambia de resultado (0 == "a" ya es falso)	Revisar validaciones y búsquedas que dependían del comportamiento viejo
PHP 7.x → 8.0	Muchos avisos se volvieron errores que detienen la ejecución	Probar flujos completos, no solo que la página cargue
PHP 8.1	Pasar null a funciones internas que esperan texto genera aviso de obsoleto	Corregir antes de que se vuelva error en una versión futura
PHP 8.2	Propiedades dinámicas en clases quedan obsoletas	Declarar las propiedades o usar el atributo correspondiente
PHP 8.4	Parámetros implícitamente opcionales con null quedan obsoletos	Declarar el tipo como ?Tipo

La lista completa de cambios por versión está en las guías oficiales de migración, por ejemplo la guía de migración a PHP 8.4. Revisa la sección de cambios incompatibles de cada versión intermedia que atraviesas.

Paso 4: resuelve las dependencias de Composer

En sistemas modernos, el código propio suele ser lo más fácil. Lo difícil son las dependencias: un paquete abandonado puede bloquear toda la actualización.

Comandos útiles de Composer:

• composer outdated --direct: lista las dependencias directas que tienen versiones nuevas.
• composer why-not php 8.4: te dice qué paquetes impiden instalar con PHP 8.4.
• composer audit: revisa si alguna dependencia instalada tiene vulnerabilidades conocidas.

Y una práctica que evita sorpresas: declarar en composer.json la versión de PHP del servidor de producción con config.platform.php. Así, Composer resuelve las dependencias como si estuviera en esa versión, aunque tu computadora tenga otra.

Cuando una dependencia está abandonada, las opciones son, en orden de preferencia: cambiarla por una alternativa mantenida, actualizar a una versión mayor que sí soporte PHP 8 (con sus propios cambios), usar un fork mantenido por la comunidad y, como último recurso, mantener tú una copia parchada. En WordPress pasa lo mismo con los plugins; hablamos de eso en seguridad de WordPress para empresas.

Paso 5: prueba lo que importa al negocio

Que la página de inicio cargue no significa que el sistema funcione. Arma una lista de flujos críticos y pruébalos en el ambiente nuevo:

• Inicio de sesión, recuperación de contraseña y permisos por rol.
• Alta de clientes, pedidos, cotizaciones y cálculo de impuestos.
• Timbrado, cancelación y descarga de CFDI en ambiente de pruebas.
• Generación de PDF, Excel y correos.
• Reportes con montos: compara los resultados contra producción con los mismos datos. Los cambios en comparaciones y redondeos pueden mover cifras sin que nada “truene”.
• Tareas programadas (cron), importaciones y APIs.

Activa el registro de errores (error_log) con nivel completo durante las pruebas y revísalo a diario. Los avisos de “obsoleto” que aparezcan hoy son los errores de la próxima versión.

Si el sistema tiene pruebas automatizadas, córrelas con la versión nueva en tu pipeline de integración continua. Si no tiene, este es un buen momento para escribir al menos pruebas de los cálculos críticos; también es una de las primeras recomendaciones cuando se planea modernizar un sistema legado.

Paso 6: planea el corte y la reversa

El corte es el momento en que producción pasa a la versión nueva. Un buen plan cabe en una hoja y responde estas preguntas:

Pregunta	Ejemplo de respuesta
¿Cuándo?	Horario de menor uso, con el equipo técnico disponible las siguientes horas
¿Quién decide si se revierte?	Una persona con nombre, no “el equipo”
¿Qué respaldo se toma justo antes?	Base de datos completa y archivos, verificados
¿Cómo se valida?	Lista de flujos críticos del paso 5, ejecutada en producción
¿Cuál es el criterio de reversa?	Cualquier falla en facturación, cobro o inicio de sesión que no se corrija en X minutos
¿Cómo se revierte?	Regresar a la versión anterior de PHP (que sigue instalada) y, si hace falta, restaurar la base

Algunas técnicas que reducen el riesgo:

• Mantener ambas versiones instaladas. En servidores Linux es normal tener varias versiones de PHP-FPM conviviendo; revertir es cambiar a qué versión apunta el servidor web.
• Desplegar en un servidor nuevo y mover el tráfico al final. Si algo falla, el servidor viejo sigue intacto. En la nube esto es sencillo y es la estrategia que preferimos para sistemas críticos.
• Congelar cambios de datos riesgosos durante la ventana de corte, como cierres de mes o importaciones masivas.
• Avisar a los usuarios clave y pedirles que reporten cualquier cosa rara las primeras 48 horas.

La reversa solo funciona si el respaldo se puede restaurar. Si no tienes claro cuánto tardarías en restaurar tu base de datos, revisa nuestra guía de respaldos 3-2-1 para PyMEs antes del corte.

¿Y si el sistema está en PHP 5 o tiene código que nadie entiende?

Hay sistemas donde actualizar PHP deja de ser una tarea de mantenimiento y se vuelve un proyecto. Las señales:

• El sistema usa funciones mysql_*, frameworks sin soporte desde hace años o librerías copiadas a mano.
• No hay control de versiones (Git) ni documentación.
• PHPCompatibility reporta cientos de problemas repartidos en todo el código.
• Las reglas de negocio están mezcladas con el HTML en los mismos archivos.

En ese caso, las opciones son: migrar el código actual a PHP 8 con correcciones intensivas, reescribir por módulos mientras el sistema viejo sigue operando, o reemplazar el sistema. Explicamos las ventajas y riesgos de cada estrategia en cómo modernizar un sistema legado sin detener tu operación. Mientras decides, aplica las medidas de aislamiento que listamos en el artículo de PHP2Shell: sacar el sistema de internet si no necesita estar expuesto, ponerlo detrás de un WAF y tener respaldos fuera del servidor. Ninguna de esas medidas corrige el problema; solo te dan tiempo.

Si la modernización termina en un sistema nuevo, conviene elegir bien la base técnica desde el principio; lo explicamos en cómo elegir el stack tecnológico para tu software.

Checklist para actualizar PHP

• Elegir la versión destino con la tabla oficial de soporte (hoy, 8.4 u 8.5).
• Inventariar sistemas, versiones, extensiones, dependencias e integraciones.
• Montar un ambiente de pruebas con la versión nueva.
• Correr PHPCompatibility y corregir, con ayuda de Rector donde aplique.
• Resolver dependencias de Composer o plugins abandonados.
• Probar los flujos críticos del negocio y comparar reportes.
• Escribir el plan de corte y de reversa, con responsable.
• Respaldar y verificar la restauración antes del corte.
• Cortar, validar y vigilar los registros de errores la primera semana.
• Agendar la siguiente revisión: las ramas de PHP tienen fecha de fin y conviene saber cuándo te toca otra vez.

Cómo te ayuda Tecsolt

En Tecsolt desarrollamos y mantenemos software desde junio de 2017. Somos un equipo 100% remoto con base en León, Guanajuato, y hemos entregado más de 100 proyectos.

Podemos ayudarte a:

• Diagnosticar tus sistemas: versiones, dependencias, riesgos y un estimado de esfuerzo realista.
• Migrar de PHP 5 o 7 a PHP 8.4 u 8.5, con ambiente de pruebas, corrección de código y plan de reversa.
• Modernizar por módulos cuando migrar no basta, con software y ERP a la medida.
• Operar la infraestructura con parches, respaldos y monitoreo en nube e infraestructura, principalmente sobre Google Cloud.

El código y los accesos quedan a nombre de tu empresa. Si tu sistema es un sitio o tienda en WordPress, revisa también nuestro servicio de diseño y desarrollo web. Cuando estés listo, agenda una reunión para revisar tu caso.

Preguntas frecuentes

¿A qué versión de PHP conviene actualizar en 2026?

A octubre de 2026, PHP 8.4 y 8.5 tienen soporte activo; 8.4 recibe parches de seguridad hasta el 31 de diciembre de 2028 y 8.5 hasta el 31 de diciembre de 2029. PHP 8.3 solo recibe parches de seguridad hasta finales de 2027 y PHP 8.2 termina el 31 de diciembre de 2026. Para un sistema que vas a mantener varios años, 8.4 es el punto de equilibrio entre estabilidad y vida útil, siempre que tus dependencias lo soporten.

¿Puedo pasar directamente de PHP 7.4 a PHP 8.4?

Sí, y suele ser más eficiente que ir versión por versión en producción. Lo que no conviene es saltarse la revisión: hay que analizar el código contra los cambios incompatibles de 8.0, 8.1, 8.2, 8.3 y 8.4 y probarlo en un ambiente idéntico al de producción antes del corte. Las herramientas como PHPCompatibility y Rector revisan todo el rango de una vez.

¿Qué se rompe al actualizar de PHP 7 a PHP 8?

Lo más común son funciones eliminadas (como each() o create_function()), comparaciones entre texto y números que ahora dan otro resultado, errores que antes eran avisos y ahora detienen la ejecución, y librerías de Composer que no soportan la versión nueva. En sistemas muy viejos aparece además el uso de las funciones mysql_*, que se eliminaron desde PHP 7.0.

¿Cuánto tarda actualizar PHP en un sistema a la medida?

Depende del tamaño del código, de cuántas dependencias están abandonadas y de si existen pruebas automatizadas. Un sitio en PHP 8.1 con dependencias al día puede migrar en días; un sistema en PHP 5 o 7 sin pruebas ni Composer puede requerir semanas o convertirse en un proyecto de modernización. El inventario inicial es lo que permite estimarlo con seriedad.

¿Qué hago si después de actualizar PHP el sistema falla?

Ejecuta el plan de reversa que preparaste antes del corte: regresar a la versión anterior de PHP (que debe seguir instalada) y, si hubo cambios de datos, restaurar la base desde el respaldo tomado justo antes. Después analiza los registros de errores en el ambiente de pruebas, corrige y agenda un nuevo corte. Sin plan de reversa, cualquier falla se convierte en una emergencia.

¿Basta con cambiar la versión de PHP en el panel del hosting?

Solo si ya probaste el sitio con la versión nueva en una copia. Cambiar la versión en cPanel o hPanel es un clic, pero no revisa la compatibilidad de tu código ni de tus plugins. Si el sitio se cae, muchas veces el panel permite regresar a la versión anterior, pero conviene tener un respaldo antes de intentarlo.

• #php
• #actualizar php
• #sistemas legados
• #composer
• #seguridad web