Cuando un cliente nos llama con un PHP de hace quince años, la tentación del desarrollador medio es abrir el código y empezar a refactorizar. Nosotras hemos aprendido —a base de proyectos que casi se tuercen— que tocar el código es lo último. Antes toca entender qué sostiene ese código, para quién y por qué.

Por qué "lo viejo funciona" suele ser mentira parcial

El cliente suele decir la frase típica: "funciona, solo queremos modernizarlo un poco". Casi nunca es verdad del todo. Lo que en realidad está pasando suele ser:

• Funciona para el 80% de los casos frecuentes. El 20% raro lo resuelve un humano a mano, haciendo cosas que no están en ningún manual.
• Hay dos o tres empleados que saben dónde están las minas. Si uno se va, el sistema se convierte en un misterio.
• Cosas que "siempre se han hecho así" están desactualizadas respecto a la normativa, pero nadie ha ido a comprobarlo en años.
• La base de datos acumula décadas de datos sin limpiar: registros duplicados, campos con significados que cambiaron, foreign keys inventadas a posteriori.

Si tú llegas y haces un rewrite fiel al código existente, replicas esos 20% de casos raros mal entendidos y rompes el flujo humano que los estaba sosteniendo. Es la receta para un proyecto que "técnicamente funciona" pero que el cliente odia.

Nuestras dos primeras semanas: auditar antes de prometer

Ningún proyecto de modernización nuestro arranca sin una auditoría previa de entre una y dos semanas. Es un bloque acotado, con precio cerrado, y al final entregamos un informe que el cliente puede usar incluso si decide no trabajar con nosotras. Esto es lo que miramos:

1. El código, pero no para juzgarlo

Lo que nos interesa del código no es si está "bien escrito" —casi nunca lo está, y no es el punto—, sino:

• Qué versión de PHP necesita y qué pasa si intentas actualizarla (normalmente, todo explota).
• Qué frameworks, librerías y dependencias usa y cuáles siguen mantenidas. CodeIgniter 2, un Symfony 1 perdido o jQuery 1.8 son banderas rojas que marcan prioridades.
• Dónde vive la lógica de negocio. Si está en stored procedures de MySQL o en cronjobs olvidados en el servidor, más trabajo y más riesgo.
• Cómo se despliega. "Por FTP" también es una respuesta, y una que cambia la planificación entera.

2. La base de datos, con calma

Exportamos el esquema y miramos con ojos de forense: qué tablas están vivas, cuáles son basura que nadie se atreve a borrar, qué relaciones existen de verdad y cuáles son ficción documentada en un Google Doc. Una base de datos de 15 años tiene mucho que contar si sabes escucharla.

3. La infraestructura y la seguridad

Versiones del sistema operativo, servidor web, PHP, librerías con CVEs conocidos, credenciales en repositorios, permisos de archivos, certificados caducando. En esta fase aparecen los quick wins: cosas críticas que se pueden cerrar en una semana sin tocar el código funcional y que reducen el riesgo inmediato.

4. Las personas

Esta es la parte que más diferencia. Hablamos con:

• Quien usa el sistema todos los días: qué odia, qué trucos tiene, qué pasos hace "a mano" porque el sistema no los cubre bien.
• Quien lo mantiene (si queda alguien): qué le da miedo tocar, qué ha prometido arreglar y nunca arregla.
• Quien responde por él a la dirección: qué métricas de negocio dependen de que ese sistema no se caiga.

En esta parte es clave la mirada funcional de Vanina. No es lo mismo programar lo que el código hace que programar lo que tiene que hacer: la norma cambia, los procesos evolucionan, y lo que era correcto hace diez años puede ser incumplimiento hoy.

Qué entregamos al final de la auditoría

Un informe corto, en lenguaje claro, con cuatro bloques:

1. Riesgos reales ordenados por probabilidad e impacto. No "tu código es feo", sino "si la versión X de esta librería deja de mantenerse en marzo, tenéis un problema de seguridad".
2. Quick wins: cosas que se pueden hacer en una o dos semanas con poco riesgo y mucho beneficio. Casi siempre son de seguridad o de despliegue.
3. Fases de modernización posibles, con órdenes de magnitud de tiempo y coste. No presupuestos cerrados —no se pueden hacer bien a ese nivel de conocimiento—, sino rangos realistas.
4. Recomendación: qué haríamos nosotras si fuera nuestro sistema, y qué ruta tendría más sentido desde el negocio, no desde el código.

A partir de ahí: reescribir NO es la opción por defecto

Muchos proyectos de legacy acaban sin rewrite. A veces la mejor inversión es:

• Actualizar PHP y librerías, blindar la seguridad y automatizar despliegues. Punto.
• Extraer un único módulo problemático y reescribirlo en Laravel como servicio separado, manteniendo el resto.
• Meter una capa de API por delante del sistema viejo, para que las nuevas integraciones no tengan que entrar "por dentro".
• Documentar lo existente y formar al equipo. Sí, esto también es un proyecto válido.

Cuando sí reescribimos —a Laravel 11/12 con PHP 8.3, normalmente—, lo hacemos por fases y módulo a módulo. Nunca un "big bang" de seis meses a puerta cerrada. El sistema viejo y el nuevo conviven hasta que el último módulo está migrado.

Lo que no vas a oírnos decir

• "Esto hay que tirarlo entero y empezar de cero." Es la frase más fácil de decir y la más cara de ejecutar.
• "Lo pasamos a Node porque es más moderno." Si tu PHP funciona y tu equipo sabe PHP, no hay razón de negocio para cambiar de lenguaje.
• "En tres meses lo tienes nuevo." No es verdad cuando hay 15 años dentro.