Cómo continuar un proyecto PHP existente sin reescribirlo desde cero

Recibir una aplicación PHP desarrollada por otra persona suele generar dos impulsos: no tocar nada por miedo a romperla o proponer una reescritura completa. Ninguno debería ser el punto de partida. Primero hay que comprobar si el proyecto puede ejecutarse, cómo conserva sus datos y qué recorridos sostienen la operación.

El objetivo inicial no es comprender cada línea. Es construir suficiente contexto para realizar un cambio pequeño de forma controlada y decidir con evidencia qué partes pueden mantenerse, corregirse o modernizarse.

1. Asegurar accesos y una copia recuperable

Antes de modificar producción se necesita inventario de repositorio o archivos, base de datos, servidor, dominio, certificados, tareas programadas, correo y servicios externos. Las credenciales deben transferirse por un medio adecuado y rotarse cuando ya no corresponda mantener accesos anteriores.

La copia de seguridad debe incluir archivos y datos, pero también debe existir una forma comprobable de restaurarlos. Un archivo guardado sin conocer versión, codificación o procedimiento de recuperación no elimina el riesgo.

2. Reproducir el entorno sin modernizar todavía

Conviene intentar ejecutar primero la aplicación con versiones compatibles con su estado actual. Actualizar PHP, sustituir librerías y reorganizar carpetas al mismo tiempo mezcla recuperación con modernización y dificulta saber qué cambio causó cada error.

El entorno reproducible puede comenzar con instrucciones, configuración separada y una copia de datos anonimizada. Docker puede ayudar, pero no es obligatorio: lo importante es que otra persona pueda repetir los pasos y distinguir configuración de código.

3. Dibujar el recorrido antes que la arquitectura completa

En PHP sin framework, una petición puede mezclar HTML, consultas y reglas en un mismo archivo. Intentar documentar todo desde el primer día consume tiempo sin garantizar que se identifique lo crítico. Es mejor seguir recorridos concretos: inicio de sesión, alta, búsqueda, pago, generación de documento o actualización de estado.

Para cada recorrido se registran entrada, archivos ejecutados, tablas, servicios externos, salida y efectos secundarios. El mapa se amplía a medida que aparecen cambios reales y acaba describiendo la arquitectura desde el comportamiento que el negocio reconoce.

4. Observar errores antes de ocultarlos

Logs de servidor, PHP y aplicación ayudan a separar avisos antiguos de fallos actuales. Activar la visualización de errores en una web pública puede exponer rutas o datos; es preferible registrarlos en un entorno controlado y reproducir el caso con entradas conocidas.

También hay que revisar tareas programadas y llamadas externas. Una pantalla puede responder bien mientras un cron falla durante semanas o una API deja operaciones a medias. El inventario de errores debe indicar frecuencia, impacto y posibilidad de reproducción.

5. Entender la base de datos como parte del contrato

En una aplicación heredada, la estructura de datos suele contener reglas que no aparecen documentadas: estados codificados, columnas reutilizadas, relaciones implícitas o procesos que esperan valores concretos. Cambiar una tabla para simplificar código puede afectar reportes, tareas y herramientas externas.

Una reescritura también hereda los datos y las reglas del sistema anterior, aunque utilice un framework moderno.

Antes de tocar esquemas conviene identificar tablas y consultas del recorrido, restricciones reales, volumen y procesos consumidores. Las migraciones necesitan reversión o una ruta de recuperación, además de validaciones que comprueben el resultado.

6. Elegir un primer cambio representativo

El primer cambio debería aportar valor y atravesar una parte relevante sin comprometer todo el sistema. Puede ser corregir una validación, añadir un campo o ajustar un reporte. Debe permitir comprobar el flujo de desarrollo, pruebas, despliegue y rollback.

Una tarea demasiado superficial no demuestra que el equipo pueda trabajar sobre la aplicación. Una modificación central y extensa tampoco es adecuada para aprender. El punto intermedio permite validar supuestos y mejorar la estimación del backlog siguiente.

7. Crear pruebas alrededor del comportamiento crítico

No es necesario detener el proyecto hasta alcanzar una cobertura completa. Se pueden añadir pruebas de caracterización alrededor del recorrido que va a modificarse: dadas ciertas entradas y datos, registrar el resultado actual y decidir conscientemente qué debe cambiar.

Las comprobaciones pueden combinar pruebas automatizadas, consultas de validación y un checklist funcional en staging. Lo importante es detectar efectos laterales en operaciones que comparten código o tablas.

8. Mejorar límites mientras se entregan funciones

Cuando una zona se modifica, puede separarse acceso a datos, validación o presentación sin reorganizar toda la aplicación. Estas mejoras locales reducen el coste del siguiente cambio y permiten que la arquitectura evolucione por trayectorias de uso real.

Actualizar dependencias también puede hacerse por etapas, priorizando versiones sin soporte y componentes expuestos. Cada salto necesita compatibilidad, pruebas y plan de reversión; modernizar no significa actualizar todo en una sola intervención.

9. Cuándo sí plantear una reescritura

Reescribir puede ser razonable si la plataforma no puede ejecutarse en un entorno soportado, el modelo impide funciones esenciales, los cambios cuestan de forma desproporcionada o la tecnología bloquea operación y contratación. La decisión necesita comparar alcance, migración de datos, convivencia temporal y riesgos.

Una reescritura completa no entrega valor hasta sustituir suficientes recorridos. Por eso también conviene evaluar reemplazo por módulos o una capa nueva alrededor del sistema existente. Mantener parte del código no es un fracaso si permite reducir riesgo y avanzar.

Qué debería entregar la fase inicial

Una toma de control útil deja inventario de accesos y dependencias, instrucciones para ejecutar, mapa de recorridos críticos, riesgos priorizados, backlog y un primer cambio validado. Con esa evidencia se puede presupuestar continuidad, estabilización o modernización sin basarse únicamente en la antigüedad del código.