Migración de PHP y Symfony
Tu PHP y tu Symfony vuelven a recibir parches de seguridad.
Tu aplicación PHP vuelve a recibir parches de seguridad sin que tu negocio pare un solo día. Trabajamos con sistemas que llevan años en producción y que nadie se atreve a tocar: son los que más lo necesitan y los que menos se pueden permitir una parada.
Qué ramas de PHP tienen soporte hoy
Una rama sin soporte no recibe parches de seguridad. No deja de funcionar el día del EOL: sigue funcionando, y esa es exactamente la razón por la que se posterga. El riesgo aparece con el primer fallo que ya no se corrige. Datos de php.net, actualizados a .
| Rama | Soporte activo hasta | Parches de seguridad hasta | Situación hoy |
|---|---|---|---|
| PHP 8.5 | 31 de diciembre de 2027 | 31 de diciembre de 2029 | Soporte completo |
| PHP 8.4 | 31 de diciembre de 2026 | 31 de diciembre de 2028 | Soporte completo |
| PHP 8.3 | Terminado | 31 de diciembre de 2027 | Solo seguridad |
| PHP 8.2 | Terminado | 31 de diciembre de 2026 | Solo seguridad, quedan meses |
| PHP 8.1 y anteriores | Terminado | Terminado | Sin parches de seguridad |
Qué ramas de Symfony tienen soporte hoy
Los dos calendarios se condicionan, y por eso esta tabla se lee junto a la anterior: cada rama de Symfony exige una versión mínima de PHP, así que mover una puede obligar a mover la otra. Datos de symfony.com, a fecha de .
| Rama | Correcciones hasta | Parches de seguridad hasta | Exige PHP |
|---|---|---|---|
| Symfony 8.1 | Enero de 2027 | Enero de 2027 | 8.4 o superior |
| Symfony 7.4 (LTS) | Noviembre de 2028 | Noviembre de 2029 | 8.2 o superior |
| Symfony 6.4 (LTS) | Noviembre de 2026 | Noviembre de 2027 | 8.1 o superior |
| Symfony 5.4 (LTS) | Terminado | Febrero de 2029 | 7.2.5 o superior |
| Symfony 8.0, 7.3 y anteriores no LTS | Terminado | Terminado | — |
Qué pasa realmente cuando la rama caduca
- Las vulnerabilidades dejan de corregirse
- Tu código no se rompe solo. Lo que cambia es que una vulnerabilidad descubierta en enero ya no tiene parche, y la que se publique el año que viene tampoco.
- El cumplimiento empieza a fallar
- Un componente sin soporte es un hallazgo en cualquier auditoría de seguridad, y bloquea certificaciones como el ENS o la ISO 27001. También aparece en las revisiones de proveedor que hacen tus clientes sujetos a la directiva NIS2.
- Las dependencias se congelan antes que el lenguaje
- Las bibliotecas dejan de publicar versiones compatibles mucho antes de que la rama caduque. Llega un punto en que actualizar una sola dependencia obliga a saltar de versión de PHP, y entonces la migración ya no se puede planificar: se hace con prisa.
- Cuesta más encontrar quien lo conozca
- Cada año que pasa hay menos gente con experiencia en una rama sin soporte, y encontrar a quien la conozca lleva más tiempo.
Cómo lo hacemos
El objetivo es llegar a la última versión. El camino pasa por una rama con soporte primero, y desde ahí tu software evoluciona sin que cada salto vuelva a ser un proyecto.
Inventario de lo que bloquea el salto
Qué versión corre, qué dependencias declaran compatibilidad con la rama de destino, cuáles están abandonadas y cuáles no tienen sucesor. Sale del
composer.jsony delcomposer.lock, sin tocar producción.Red de seguridad antes de mover nada
Si tu sistema no tiene pruebas que cubran su comportamiento, se escriben antes de migrar. Migrar sin red es lo que convierte una migración en una crisis.
Salto por tramos, en producción
Se sube de rama en incrementos que se despliegan y se usan. Nunca hay una versión paralela que haya que integrar al final, que es donde estos proyectos se quedan encallados.
Dependencias al día y sostenibles
Las bibliotecas abandonadas se sustituyen por alternativas mantenidas, con preferencia por las de licencia libre para que la siguiente actualización no dependa de las condiciones de un tercero.
Que la próxima no sea un proyecto
Tu sistema queda con las pruebas, la integración continua y la documentación necesarias para que subir de rama vuelva a ser una tarea de mantenimiento.
El aval
El método está probado donde más cuesta: una plataforma de SmartCities que llevamos evolucionando cinco años seguidos, desde PHP 5 hasta las ramas con soporte de hoy y desde Symfony 1.4 hasta las versiones actuales del framework. Sin reescribir el sistema desde cero y sin detener el servicio en ningún momento.
Preguntas frecuentes
- ¿Hay que parar el servicio durante la migración?
- No. Se sube por tramos que se despliegan y se usan, así que en ningún momento existe una versión paralela esperando a integrarse. Tu servicio sigue en producción durante todo el proceso.
- ¿Y si el código no tiene pruebas?
- Es el caso habitual en los sistemas que llevan años funcionando. Las pruebas se escriben antes de mover nada, empezando por lo que tu negocio no puede permitirse que falle. Ese trabajo no se pierde al terminar la migración: es lo que hace que la siguiente sea rutina.
- ¿Hasta qué versión conviene subir?
- Hasta una que tenga soporte activo, no necesariamente la última. Saltar a la rama más reciente el día que sale suele significar esperar a que las dependencias la alcancen; subir a la anterior estable da margen de años y se hace con las bibliotecas ya listas.
- ¿Cuánto cuesta y cuánto tarda?
- Depende de cuántas dependencias bloqueen el salto y de qué cobertura de pruebas tengas, que es justo lo que mide el inventario del primer paso. Hasta tenerlo, cualquier número sería inventado; con él sobre la mesa, hablamos de alcance y plazos con datos.
- ¿Podéis migrar desde PHP 5.6 o PHP 7?
- Sí, y son los saltos que mejor conocemos: la plataforma de SmartCities que llevamos cinco años evolucionando arrancó en PHP 5, y ese recorrido —cada rama intermedia, cada dependencia que se quedó por el camino— es de donde sale el método por tramos. Son los saltos más largos y los que más se benefician de hacerlos por partes, porque intentarlos de una vez es lo que hace que se abandonen a mitad.
¿Por dónde empezamos?
Dos formas de arrancar, según lo que tengas hoy delante. Respuesta en un día laborable.