Qué significa el fin de vida de PHP 8.2 en la práctica
Cada versión de PHP sigue un ciclo de vida en dos fases: dos años de soporte activo (correcciones de errores y seguridad), luego dos años de soporte de seguridad únicamente — cuatro años en total por versión. PHP 8.2, lanzado en noviembre de 2022, terminó su soporte activo el 31 de diciembre de 2024. Desde el 1 de enero de 2025, solo se publican parches de seguridad críticos. El 31 de diciembre de 2026, incluso esa cobertura se detiene. Las vulnerabilidades descubiertas después de esa fecha en el motor PHP 8.2 no recibirán ningún parche oficial. Tus servidores seguirán ejecutando código, pero sin ninguna red de seguridad. Los CVE publicados después del EOL permanecerán explotables indefinidamente en las instalaciones no migradas.
Los riesgos concretos después del 31 de diciembre de 2026
- Vulnerabilidades zero-day sin parche oficial — cualquier vulnerabilidad descubierta en PHP 8.2 después del EOL permanecerá explotable indefinidamente; los atacantes siguen estos plazos y esperan.
- Incompatibilidad creciente con frameworks — Laravel 13 (Q1 2026) exige PHP 8.3 como mínimo y abandona oficialmente PHP 8.2; los proyectos no migrados no podrán actualizar el framework.
- Presión de los paquetes Composer — los mantenedores de paquetes dejan progresivamente de declarar compatibilidad con PHP 8.2 en su composer.json, causando bloqueos en las actualizaciones de dependencias.
- Retirada por los proveedores de hosting — algunos paneles de control y proveedores de hosting gestionado eliminan PHP 8.2 de sus entornos activos, forzando una migración de emergencia no planificada.
- Riesgo en auditorías de cumplimiento — los estándares ISO 27001, PCI-DSS y SOC 2 señalan el uso de runtimes EOL como una brecha inaceptable; una versión no mantenida puede bloquear una certificación.
- Pérdida del soporte de WordPress — WordPress recomienda PHP 8.3 como versión mínima en 2026; los plugins premium condicionan progresivamente su soporte a PHP 8.3 o superior.
- Divergencia progresiva de comportamiento — PHP 8.3 y 8.4 corrigen comportamientos internos y mejoran los mensajes de error; quedarse en 8.2 significa perder estas correcciones y ampliar la brecha con los entornos de desarrollo del equipo.
Inventariar tu stack — mapear los sitios en PHP 8.2
El primer reto para una agencia no es técnico, es cartográfico. Antes de cualquier migración, necesitas saber exactamente cuántos sitios están en PHP 8.2 y bajo qué configuración de servidor. Un inventario incompleto lleva a sitios olvidados que permanecen expuestos después del EOL. En cada VPS, ejecuta php -v por virtual host o consulta el archivo phpinfo.php temporal — elimínalo inmediatamente después de usarlo. En servidores cPanel o Plesk, la interfaz de administración expone la versión PHP por dominio. Lista cada sitio en una hoja de cálculo con: dominio, versión PHP activa, CMS o framework, versión del CMS, fecha de última actualización de dependencias, y nivel de criticidad.
PHP 8.2, 8.3 y 8.4 — ciclo de vida, EOL y funcionalidades clave
Desplace la tabla
| Criterio | PHP 8.2 | PHP 8.3 | PHP 8.4 |
|---|---|---|---|
| Fecha de lanzamiento | Noviembre 2022 | Noviembre 2023 | 21 de noviembre de 2024 |
| Fin del soporte activo | 31 de diciembre de 2024 | 31 de diciembre de 2025 | 31 de diciembre de 2026 |
| Fin del soporte de seguridad (EOL) | 31 de diciembre de 2026 | 31 de diciembre de 2027 | 31 de diciembre de 2028 |
| Readonly classes | Sí | Sí | Sí |
| Typed class constants | Sí | Sí | Sí |
| Property hooks | No | No | Sí (funcionalidad principal) |
| Visibilidad asimétrica | No | No | Sí |
| json_validate() | Sí | Sí | Sí |
| Compatibilidad Laravel 12 | Sí | Sí | Sí |
| Compatibilidad Laravel 13 | No | Sí | Sí |
| Compatibilidad Symfony 7.x | Sí | Sí | Sí |
| Compatibilidad Symfony 8.x | No | No | Sí (requiere 8.4) |
Probar la compatibilidad antes de migrar
Migrar sin pruebas previas es la principal causa de incidentes en producción. Dos herramientas complementarias cubren el grueso del análisis estático. PHPCompatibility es un conjunto de reglas para PHP_CodeSniffer: analiza el código fuente y reporta llamadas a funciones eliminadas, parámetros obsoletos y cambios de comportamiento entre versiones. Instálalo vía Composer (composer require --dev phpcompatibility/php-compatibility) y ejecútalo con el objetivo --runtime-version=8.3. PHPStan, por su parte, realiza análisis de tipos estático: configurado en nivel 5 o superior, detecta propiedades dinámicas (obsoletas desde PHP 8.2, fatales en 8.4), incompatibilidades de tipos y firmas de métodos incorrectas. El enfoque recomendado es ejecutar PHPStan primero en la base de código actual para establecer una línea base, luego cambiar la versión PHP objetivo a 8.3 o 8.4 en tu phpstan.neon para identificar las brechas.
Checklist de migración a PHP 8.3 o 8.4
Mapear el stack y establecer el orden de migración
Lista todos los sitios en PHP 8.2 con su CMS, framework y nivel de criticidad. Prioriza los sitios de e-commerce y las aplicaciones sensibles primero; los sitios de presentación estáticos pueden tratarse al final.
Ejecutar análisis estático con PHPCompatibility y PHPStan
Ejecuta
phpcs --standard=PHPCompatibility --runtime-version=8.3en el directorio fuente. Corrige las llamadas a funciones eliminadas y las propiedades dinámicas no declaradas antes de pasar al siguiente paso.Actualizar las dependencias Composer en un entorno aislado
En un entorno de staging con PHP 8.3 o 8.4 activo, ejecuta
composer updatey resuelve los conflictos de versión. Verifica que cada paquete crítico declare compatibilidad con la versión PHP objetivo en sucomposer.json.Validar con la suite de pruebas existente
Ejecuta PHPUnit, Pest o pruebas end-to-end contra la versión PHP objetivo. Si el proyecto carece de pruebas automatizadas, documenta los flujos críticos probados manualmente (autenticación, carrito, formularios, webhooks).
Actualizar el CMS o el framework si es necesario
WordPress: verifica la compatibilidad de cada plugin con PHP 8.3. Laravel: si el proyecto sigue en Laravel 11, evalúa la actualización a Laravel 12 al mismo tiempo que la migración PHP. Symfony: Symfony 7.4 LTS es compatible con PHP 8.2 a 8.4 sin cambiar el framework.
Cambiar la versión PHP en producción
En un VPS con PHP-FPM, actualiza el pool del virtual host nginx para apuntar al socket php8.3-fpm.sock o php8.4-fpm.sock. Recarga nginx y PHP-FPM. En un hosting gestionado, cambia la versión desde el panel de control o CLI.
Monitorizar los logs de error durante 48 horas
Activa el registro PHP (
log_errors = On,error_log = /var/log/php/error.log) y observa los avisos, advertencias y errores fatales durante al menos dos días laborables después del cambio.Actualizar el inventario y notificar al cliente
Actualiza tu hoja de mapeo con la nueva versión PHP y la fecha de migración. Envía una nota de cierre al cliente confirmando la actualización — esta trazabilidad es útil durante las auditorías de cumplimiento.
En un VPS, PHP-FPM permite ejecutar múltiples versiones en paralelo sin conflictos: cada virtual host nginx apunta a un socket FPM distinto (php8.2-fpm.sock, php8.3-fpm.sock, php8.4-fpm.sock). Esta arquitectura permite migrar sitio por sitio, manteniendo los proyectos no probados en PHP 8.2 mientras los proyectos validados ya corren en 8.3 o 8.4. Configuración tipo en nginx: fastcgi_pass unix:/run/php/php8.3-fpm.sock;. Empieza con los sitios menos críticos para afinar tu proceso.
Frameworks y CMS — fechas de abandono de PHP 8.2
Conocer el calendario de tus frameworks es esencial para anticipar las restricciones de migración. Laravel 12, lanzado el 24 de febrero de 2025, soporta PHP 8.2 a 8.5 y recibe correcciones de seguridad hasta el 24 de febrero de 2027. Sin embargo, Laravel 13 (lanzado en Q1 2026) exige PHP 8.3 como mínimo: cualquier aplicación que desee migrar a Laravel 13 deberá pasar primero a PHP 8.3. Symfony 7.x (todas las versiones de 7.0 a 7.4) exige PHP 8.2 como mínimo; la versión LTS Symfony 7.4, lanzada en noviembre de 2025, está soportada hasta noviembre de 2029 y es compatible con PHP 8.3 y 8.4. Symfony 8.x exige PHP 8.4 como mínimo. WordPress recomienda PHP 8.3 como versión mínima en 2026. Estos hitos deben aparecer en tu plan de migración.
Automatizar la monitorización de versiones en tu stack agencia
Un inventario manual envejece rápido: los clientes añaden plugins, cambian de proveedor de despliegue o instalan nuevas aplicaciones sin notificación. Automatizar la monitorización de versiones permite mantenerse informado sin esfuerzo diario. Un script cron simple puede consultar php -v vía SSH en cada servidor y escribir el resultado en un archivo de informe centralizado — una herramienta como Ansible o Fabric permite paralelizar esta recopilación en docenas de hosts. Las herramientas de monitorización de servidor exponen la versión PHP en sus métricas y pueden disparar alertas si aparece una versión no autorizada. El objetivo es que descubrir un sitio aún en PHP 8.2 después del 31 de diciembre de 2026 dispare una alerta automática, no una auditoría anual.
Solución de problemas — 4 errores frecuentes en la migración
Las migraciones PHP 8.2 → 8.3/8.4 siguen patrones de fallo recurrentes. Primero, las propiedades dinámicas: desde PHP 8.2, añadir una propiedad no declarada a una clase está obsoleto; en PHP 8.4 es un error fatal. El síntoma es un Warning Creation of dynamic property. La corrección: declarar todas las propiedades en la clase o añadir el atributo #[\AllowDynamicProperties] para clases heredadas. Segundo, las extensiones PECL faltantes: PHP 8.3 y 8.4 no compilan las mismas extensiones por defecto según la distribución; extensiones como imagick, redis o swoole deben reinstalarse explícitamente. Verifica con php8.3 -m | grep redis. Tercero, los conflictos de versiones Composer: un paquete que declara "php": "^8.2" puede generar incompatibilidad con otro que declara "php": "^8.3" si el composer.lock no se ha regenerado — siempre relanza composer update desde cero en el entorno staging. Cuarto, las directivas ini obsoletas: algunas directivas como mbstring.func_overload han sido eliminadas; un php.ini sin limpiar puede producir avisos al arrancar PHP-FPM.
Anticiparse para gestionar tu stack cliente con fluidez
Para una agencia que gestiona docenas de sitios, la migración PHP es un proyecto multisitio a pilotar con varios meses de antelación. Establece un plan por prioridad decreciente: los sitios de e-commerce y las aplicaciones de gestión crítica primero, los sitios de presentación al final. Comunica a tus clientes los riesgos de quedarse en PHP 8.2 después del 31 de diciembre de 2026 — un memorando fechado que explique las implicaciones de seguridad y cumplimiento suele ser suficiente para desbloquear el acuerdo y el presupuesto necesarios. Integra la actualización de la versión PHP en tus contratos de mantenimiento anuales: una línea dedicada evita renegociar cada migración.
VPS ServOrbit con PHP-FPM configurable
En un VPS ServOrbit, varias versiones de PHP-FPM coexisten en la misma máquina y cada virtual host apunta a la versión que elija. La actualización se realiza modificando una sola línea de configuración nginx y recargando PHP-FPM — sin reinicio del servidor, sin interrupción de los otros sitios alojados. Para los stacks de agencia, un VPS dedicado por cliente o un VPS compartido con aislamiento PHP-FPM por pool ofrece la flexibilidad necesaria para migrar sitio por sitio según tu calendario, sin depender del planning de un proveedor de hosting gestionado.
