Llevo aplicaciones Laravel y Symfony antiguas hacia versiones actuales, con una estrategia progresiva basada en auditoría, tests automatizados y despliegues controlados.
No se trata de cambiar dependencias y esperar que todo siga funcionando. Se trata de actualizar el framework sin perder la lógica de negocio, reduciendo la deuda técnica y dejando una base más segura y mantenible para seguir desarrollando.
¿Tu aplicación se ha quedado atrás?
Una aplicación legacy puede seguir funcionando durante años, pero eso no significa que esté en buenas condiciones.
Mantener un framework desactualizado puede dificultar:
- Corregir vulnerabilidades de seguridad.
- Actualizar PHP, Composer o las dependencias del proyecto.
- Incorporar nuevas funcionalidades.
- Encontrar desarrolladores que puedan mantener el código.
- Desplegar en infraestructuras actuales.
- Resolver errores provocados por librerías abandonadas.
- Evolucionar el producto sin aumentar continuamente el riesgo.
Las versiones de PHP, Laravel y Symfony tienen ciclos de soporte definidos. Actualizar no consiste únicamente en instalar la última versión: también hay que comprobar la compatibilidad de la aplicación, sus dependencias y su infraestructura.
Qué actualizo
Trabajo con aplicaciones desarrolladas con:
- Laravel 9 y versiones posteriores, con migración hacia versiones actuales como Laravel 12 o Laravel 13.
- Symfony 2 y versiones posteriores, incluyendo migraciones hacia Symfony 6 o Symfony 7.
- Código propio con lógica de negocio compleja.
- Proyectos sin tests automatizados o con una cobertura insuficiente.
- Aplicaciones con paquetes obsoletos o dependencias difíciles de sustituir.
- Sistemas que necesitan actualizar PHP, Composer, base de datos o herramientas de empaquetado.
La versión de destino se determina después de analizar el proyecto. No siempre tiene sentido saltar directamente a la última versión disponible: en algunos casos es más seguro utilizar versiones intermedias o una versión con soporte prolongado.
Sin compromiso. Revisamos objetivos, situación actual y si tiene sentido preparar una propuesta.
Una actualización basada en evidencias
Antes de modificar el framework, creo una red de seguridad que permita detectar regresiones y comprobar que la aplicación sigue haciendo lo que debe.
1. Auditoría inicial
Analizo:
- Versión actual de Laravel, Symfony y PHP.
- Dependencias de Composer y librerías JavaScript.
- Paquetes abandonados o incompatibles.
- Estado de la base de datos y de la infraestructura.
- Deuda técnica relevante.
- Tests existentes y nivel de cobertura.
- Flujos críticos de negocio.
- Riesgos y saltos de versión necesarios.
El resultado es un diagnóstico técnico y una propuesta de actualización por etapas.
2. Construcción de la red de seguridad
Cuando la aplicación no tiene suficiente cobertura, incorporo los tests necesarios antes de realizar los saltos más delicados.
Según las necesidades del proyecto, se combinan:
- Tests unitarios.
- Tests de integración.
- Tests end-to-end.
- Cobertura de ramas.
- Pruebas de los flujos críticos de negocio.
- Comprobaciones de permisos, pagos, formularios, comunicaciones y procesos internos.
La cobertura no se fija con una cifra arbitraria. Se acuerda en función del riesgo, la criticidad de la aplicación y el presupuesto disponible.
3. Actualización progresiva
Realizo los saltos intermedios que sean necesarios para controlar la estabilidad de la aplicación.
En cada etapa:
- Actualizo el framework y sus dependencias.
- Adapto el código propio a los cambios de la nueva versión.
- Sustituyo paquetes incompatibles cuando sea necesario.
- Actualizo el sistema de empaquetado y las librerías frontend.
- Ejecuto los tests automatizados.
- Reviso los errores y comportamientos inesperados.
- Documento los cambios realizados.
No fuerzo una migración directa si el proyecto necesita pasar por varias versiones para reducir el riesgo.
4. Despliegue controlado
El trabajo se desarrolla utilizando entornos separados de desarrollo, pruebas y staging.
Cada actualización se entrega por etapas e incluye:
- Control de versiones.
- Backups antes de las operaciones relevantes.
- Posibilidad de rollback.
- Validación en staging.
- Despliegue en producción.
- Comprobación posterior al despliegue.
- Monitorización inicial de la aplicación.
La monitorización posterior puede ampliarse mediante un servicio de mantenimiento continuado.
No sustituyo tu lógica de negocio
Una actualización técnica no debería convertirse en una reescritura innecesaria de la aplicación.
Cuando el código propio necesita cambios, adapto la implementación para que sea compatible con el framework actualizado, respetando:
- Las reglas de negocio existentes.
- Los procesos internos.
- Las integraciones con servicios externos.
- Los permisos y roles.
- Los datos almacenados.
- La experiencia de las personas usuarias.
Si una dependencia ha quedado abandonada, busco una alternativa compatible. Cuando no existe una sustitución razonable, puedo desarrollar una solución específica para conservar la funcionalidad necesaria.
Un caso real: Reconoce
La Asociación Reconoce necesitaba actualizar su herramienta de Laravel 9 a Laravel 12.
El proyecto partía de una situación sin cobertura significativa de tests. Como parte del proceso:
- Se construyó una red de tests unitarios. Alcanzándose un 87% de cobertura de código, con especial atención a funcionalidades core.
- Se añadieron pruebas end-to-end para los caminos críticos con tests automatizados.
- La actualización se realizó de forma progresiva, versión a versión. Dedicando tiempo para crear test, desplegar cada nueva versión en entornos de staging y monitorizando en producción.
El objetivo no fue únicamente cambiar la versión de Laravel, sino conseguir una base más segura para mantener y evolucionar la aplicación.
Cómo trabajo
Soy consultor especializado y trabajo directamente en el proyecto, sin trasladar la responsabilidad a una cadena de interlocutores.
Aporto más de 15 años de experiencia en desarrollo web con PHP, Laravel, Symfony, WordPress, APIs, automatización y sistemas conectados. Utilizo herramientas de IA como apoyo para analizar código, investigar incompatibilidades y acelerar tareas, pero las decisiones técnicas, las revisiones y la responsabilidad del resultado siguen estando bajo supervisión profesional.
El trabajo se realiza de forma cercana y consensuada: primero entiendo el negocio y después tomo decisiones técnicas compatibles con sus prioridades.
Plazos y presupuesto
Como referencia, una subida de versión puede requerir aproximadamente dos semanas de trabajo, siempre después de realizar la auditoría inicial.
El plazo real depende de factores como:
- Número de versiones que hay que atravesar.
- Estado de los tests.
- Complejidad del código propio.
- Cantidad de dependencias.
- Integraciones externas.
- Estado de la infraestructura.
- Necesidad de sustituir o desarrollar paquetes.
El precio orientativo de una subida de versión es de 1.299 €, pero el presupuesto final se prepara después de revisar la aplicación.
Para quién es este servicio
Este servicio puede encajar si eres:
- Una agencia que necesita apoyo especializado para un proyecto heredado (legacy).
- Una empresa que quiere actualizar una aplicación web importante para su actividad pero sin un equipo interno.Una gerencia que necesita reducir el riesgo técnico de un sistema heredado.
- Un equipo que quiere seguir desarrollando funcionalidades, pero está bloqueado por una versión antigua.
No es una solución de “actualización automática” ni una promesa de que cualquier aplicación podrá saltar directamente a la última versión. El primer paso es conocer el estado real del proyecto y definir una ruta técnicamente viable.
Solicita una auditoría
Cuéntame:
- Qué aplicación necesitas actualizar.
- Qué versión de Laravel o Symfony utiliza.
- Qué versión de PHP tiene actualmente.
- Si dispone de tests automatizados.
- Qué problemas te está provocando mantenerla desactualizada.
- Qué plazo tienes para realizar la actualización.
Y si no lo sabes, ya haré el análisis del punto de partida y te propondré una estrategia de actualización por etapas, con sus riesgos, dependencias y presupuesto.
SobrE MÍ
Desarrollo centrado en las personas
Soy Pablo R.M., desarrollador full‑stack y consultor técnico con más de 15 años de experiencia liderando proyectos web en entornos complejos. Además de organizador de los encuentros de la comunidad Betabeers.
Más de 20 años desarrollando en PHP. ¿tienes algún proyecto legacy entre manos? ¿una web WordPress que mantener?