Symfony y PHP 8.4: modernizar sin reescribirlo todo
Symfony y PHP 8.4 en 2026: modernizar una aplicación sin reescribirlo todo
Migrar un proyecto Symfony a PHP 8.4 no consiste simplemente en cambiar una versión en composer.json, ejecutar composer update y cruzar los dedos.
En una aplicación que lleva varios años en producción, el verdadero reto está en otra parte: saber qué se puede modernizar, qué conviene conservar y cómo avanzar sin convertir una actualización técnica en un proyecto interminable.
Porque, en el mundo real, no empezamos de cero cada seis meses.
Hay clientes que atender, datos que preservar, funcionalidades que ya funcionan y un equipo que debe seguir entregando mientras se lleva a cabo la migración.
Y es precisamente ahí donde la combinación de Symfony y PHP 8.4 resulta especialmente interesante.
PHP 8.4 no está obsoleto solo porque exista PHP 8.5
PHP 8.5 se publicó a finales de 2025, pero eso no convierte de repente a PHP 8.4 en una versión antigua que haya que descartar.
PHP 8.4 sigue recibiendo soporte activo hasta finales de 2026 y, después, actualizaciones de seguridad hasta el 31 de diciembre de 2028. Para una empresa que prioriza la estabilidad y no quiere correr detrás de cada nueva versión en cuanto aparece, sigue siendo una base perfectamente sólida.
Consultar el calendario oficial de versiones de PHP
Por parte de Symfony, PHP 8.4 se ha convertido incluso en la versión mínima requerida por Symfony 8. La rama estable actual, Symfony 8.1, requiere PHP 8.4 o una versión posterior.
Consultar la información sobre Symfony 8.1
En otras palabras, PHP 8.4 no es simplemente una versión de transición. Es la base sobre la que Symfony construye actualmente sus versiones modernas.
Novedades útiles, no solo decorativas
PHP 8.4 incorpora varios cambios importantes: los hooks de propiedades, la visibilidad asimétrica, los lazy objects, el atributo #[Deprecated], una nueva API DOM compatible con HTML5, además de distintas mejoras de rendimiento y coherencia del lenguaje.
Descubrir las novedades de PHP 8.4
Evidentemente, nadie necesita reescribir todo su proyecto para empezar a utilizar cada nueva funcionalidad el lunes por la mañana.
Pero algunas de ellas permiten simplificar código que llevamos años escribiendo de la misma manera.
Hooks de propiedades
Hasta ahora, en cuanto queríamos controlar cómo se leía o modificaba una propiedad, era habitual terminar con un getter, un setter y varias líneas de código para una operación bastante sencilla.
PHP 8.4 permite asociar directamente un comportamiento a una propiedad:
final class Product
{
public float $price {
set {
if ($value < 0) {
throw new InvalidArgumentException(
'El precio no puede ser negativo.'
);
}
$this->price = round($value, 2);
}
}
}
La validación y la normalización permanecen cerca del dato al que afectan, sin necesidad de multiplicar los métodos únicamente para leer o modificar un valor.
Es útil, pero no es una invitación a meter toda la lógica de negocio dentro de las propiedades.
Como ocurre a menudo con PHP, una funcionalidad resulta interesante cuando simplifica el código. Lo es mucho menos cuando se utiliza en todas partes simplemente porque acaba de aparecer.
Una propiedad pública que no todo el mundo puede modificar
La visibilidad asimétrica permite separar los permisos de lectura y escritura.
Una propiedad puede, por ejemplo, ser accesible públicamente para lectura y, al mismo tiempo, solo poder modificarse desde la propia clase:
final class Order
{
public private(set) OrderStatus $status = OrderStatus::Pending;
public function markAsPaid(): void
{
$this->status = OrderStatus::Paid;
}
}
El resto de la aplicación puede consultar el estado del pedido, pero no puede decidir arbitrariamente que está pagado.
Este tipo de detalles hace que los objetos sean más explícitos y evita que modificaciones sensibles puedan realizarse desde cualquier parte del proyecto.
La separación de la visibilidad de lectura y escritura es una de las novedades principales de PHP 8.4.
Consultar las nuevas funcionalidades de PHP 8.4
Lazy objects: donde PHP 8.4 beneficia directamente a Symfony
Los lazy objects son objetos que solo se inicializan cuando realmente son necesarios.
El concepto ya existía en Symfony y Doctrine, especialmente para cargar determinados servicios o relaciones únicamente cuando la aplicación los necesita.
El problema era que, hasta ahora, los frameworks tenían que crear sus propios sistemas de proxies y generar código para conseguir este comportamiento.
PHP 8.4 integra ahora este mecanismo directamente en el lenguaje mediante su API de Reflection.
Desde Symfony 7.3, los servicios configurados con carga diferida pueden utilizar automáticamente los lazy objects nativos cuando la aplicación se ejecuta con PHP 8.4 o una versión posterior.
No hay que reescribir nada especial en el proyecto: Symfony detecta la versión de PHP y utiliza automáticamente el mecanismo nativo.
Descubrir la integración en Symfony 7.3
Probablemente no sea la funcionalidad que enseñarías primero en una demostración comercial.
Pero, por debajo, es exactamente el tipo de evolución que importa: menos código generado, menos soluciones específicas del framework y una funcionalidad importante gestionada ahora directamente por el propio PHP.
Una migración progresiva sigue siendo posible
Adoptar PHP 8.4 no significa que haya que pasar inmediatamente a la última versión mayor de Symfony.
Symfony 6.4 admite PHP 8.1 o versiones posteriores y seguirá recibiendo actualizaciones de seguridad hasta noviembre de 2027.
Symfony 7.4, la versión LTS actual, funciona a partir de PHP 8.2 y seguirá recibiendo actualizaciones de seguridad hasta noviembre de 2029.
Consultar la información sobre Symfony 7.4
Por tanto, un equipo puede empezar actualizando PHP, estabilizar la aplicación, revisar las dependencias y resolver las alertas antes de plantearse una migración más importante del framework.
Suele ser mucho más razonable que intentar cambiar al mismo tiempo:
-
La versión de PHP
-
La versión mayor de Symfony
-
Doctrine
-
El sistema de autenticación
-
La infraestructura
-
La mitad de la arquitectura
Cambiar diez cosas a la vez puede dar la impresión de avanzar rápido.
Pero cuando algo falla en producción, averiguar exactamente qué ha provocado el problema deja de ser tan divertido.
No, cambiar la versión en composer.json no es suficiente
Antes de realizar una migración, suelo empezar comprobando qué dependencias siguen bloqueando PHP 8.4:
composer why-not php 8.4
Después compruebo los requisitos de plataforma realmente instalados en la máquina o dentro del contenedor:
composer check-platform-reqs
A continuación vienen las etapas menos espectaculares, pero mucho más importantes:
-
Actualizar las dependencias compatibles
-
Ejecutar los tests automatizados
-
Identificar las deprecaciones
-
Comprobar las extensiones PHP utilizadas
-
Analizar el código con PHPStan o Psalm
-
Probar comandos, workers y tareas programadas
-
Generar la caché de producción
-
Revisar los logs después del despliegue
PHP 8.4 introduce algunas incompatibilidades y nuevos errores para ciertos usos que anteriormente se toleraban.
Por este motivo, la guía oficial recomienda explícitamente probar la aplicación antes de cambiar la versión de PHP utilizada en producción.
Consultar la guía de migración a PHP 8.4
Para una migración mayor de Symfony, la documentación también recomienda resolver las deprecaciones antes de modificar las restricciones de versión y, después, realizar la actualización con Composer junto con todas las dependencias necesarias.
Consultar la guía de actualización mayor de Symfony
Este trabajo puede parecer menos atractivo que una reescritura completa.
Sin embargo, suele ser lo que marca la diferencia entre una migración controlada y tres días apagando incendios en producción.
Aprovechar la migración para limpiar, sin intentar rehacerlo todo
Actualizar a PHP 8.4 puede ser una buena oportunidad para revisar determinadas partes del proyecto:
-
Definir mejor los tipos que todavía son demasiado genéricos
-
Sustituir construcciones que ya no son necesarias
-
Eliminar dependencias abandonadas
-
Resolver las deprecaciones acumuladas
-
Reforzar la cobertura de tests en las funcionalidades críticas
-
Simplificar código que se ha ido complicando con los años
Pero también hay que saber cuándo parar.
Un servicio antiguo, algo verboso, correctamente probado y perfectamente estable no necesita necesariamente ser reescrito por completo utilizando las últimas funcionalidades del lenguaje.
En cambio, un componente frágil, difícil de entender y lleno de efectos secundarios probablemente merezca algo más que un simple cambio de versión.
La experiencia consiste precisamente en saber distinguir entre ambas situaciones.
Symfony sigue teniendo sentido para proyectos que deben durar
Lo que valoro de Symfony no es solamente la cantidad de componentes disponibles o la calidad de su documentación.
Es, sobre todo, la posibilidad de hacer evolucionar una aplicación paso a paso.
Se puede modernizar el entorno PHP sin reescribir inmediatamente la lógica de negocio.
Se pueden resolver las deprecaciones de forma progresiva.
Se pueden actualizar las dependencias una a una, reforzar los tests y preparar la siguiente versión mayor sin paralizar todo el proyecto durante varios meses.
Evidentemente, el framework por sí solo no garantiza un código limpio.
Una mala arquitectura sigue siendo una mala arquitectura, incluso utilizando la última versión de Symfony y todos los atributos de moda.
La mantenibilidad sigue dependiendo de las decisiones técnicas, los tests, la comprensión del negocio y la forma en la que trabaja el equipo.
Pero Symfony proporciona una base lo suficientemente estable como para acompañar esta evolución sin obligarnos a empezar desde cero con cada nueva versión.
Mi opinión
En 2026, PHP 8.4 sigue siendo una muy buena elección para una aplicación Symfony.
Es lo suficientemente reciente como para beneficiarse de las mejoras modernas del lenguaje, lo suficientemente madura como para haber dejado de sentirse experimental y compatible con varias ramas de Symfony que todavía reciben mantenimiento.
¿Hay que migrar únicamente para poder escribir PHP 8.4 en la documentación del proyecto?
No.
Pero si la aplicación sigue funcionando con una versión antigua de PHP, las dependencias empiezan a convertirse en un obstáculo o la deuda técnica hace que cada evolución sea más complicada, la migración puede ser un excelente punto de partida.
No hace falta tirarlo todo y empezar de nuevo.
Lo primero es auditar, probar y establecer una ruta de migración segura. Después, modernizar lo que realmente aporta valor, paso a paso.
Es menos espectacular que una reescritura completa.
Pero, en muchos proyectos, también es mucho más útil.