El sistema que nadie quiere tocar
Toda empresa con más de 5 años en tecnología tiene uno: el sistema que "funciona de milagro". En este caso era un monolito PHP construido hace 8 años, sin tests, sin documentación, con contraseñas de base de datos escritas directamente en el código, y un proceso de deploy que consistía en copiar archivos al servidor manualmente y rezar.
Nadie del equipo quería tocarlo. Cada cambio era un evento de alto riesgo. Y el negocio dependía completamente de él para la operación logística diaria.
La decisión fue modernizarlo sin reescribirlo. Este artículo documenta el proceso.
Por qué no reescribir desde cero
La reescritura completa es seductora porque parece la solución "limpia". En la práctica, es la decisión que más frecuentemente termina en desastre:
- El sistema original tiene años de casos borde resueltos que nadie documentó
- La reescritura tarda el doble de lo estimado, siempre
- Durante la reescritura el negocio sigue dependiendo del sistema viejo
- La migración de datos entre el sistema viejo y el nuevo es el problema más difícil
La contenedorización incremental permite modernizar la infraestructura sin cambiar el código. El sistema sigue siendo PHP, pero ahora corre en un entorno controlado, tiene despliegue automático, monitoreo y puede revertirse en dos minutos.
Fase 1: Auditoría antes de tocar nada (1 semana)
Antes de hacer cualquier cambio, el primer paso es entender qué existe. Esto incluye:
- Qué versión de PHP necesita el sistema y qué extensiones usa (algunos módulos viejos solo funcionan con versiones específicas)
- Qué servicios externos consume — bases de datos, servicios de correo, APIs de terceros
- Dónde están las contraseñas hardcodeadas — casi siempre están en más lugares de los que el equipo recuerda
- Qué tareas programadas existen en el servidor (los cron jobs olvidados son la fuente más común de sorpresas en producción)
Al final de esta semana hay un inventario completo. Todo lo que no está en el inventario aparece como problema el día del go-live.
Fase 2: Contenedorizar sin cambiar comportamiento (3-5 días)
El objetivo de esta fase es replicar el entorno de producción actual dentro de un contenedor, sin optimizar nada todavía. Si el sistema funciona raro pero funciona, tiene que seguir funcionando igual dentro del contenedor.
El único cambio de código en esta fase es sacar las contraseñas y configuraciones hardcodeadas del código y pasarlas a variables de entorno. No es un cambio de lógica — es mover la IP del servidor a una variable que el entorno inyecta al arrancar. Este cambio también es el que permite manejar múltiples ambientes (desarrollo, staging, producción) sin modificar el código.
Antes de avanzar, el equipo verifica que el sistema dentro del contenedor hace exactamente lo mismo que en el servidor original. Este paso de validación no se puede saltar.
Fase 3: Deploy automático (2-3 días)
Con el sistema corriendo en un contenedor, el siguiente paso es automatizar el deploy. El proceso anterior — copiar archivos manualmente al servidor — tardaba entre 20 y 40 minutos y era propenso a errores. El deploy automatizado tarda menos de 4 minutos y se activa automáticamente cuando alguien aprueba un cambio en el repositorio.
Más importante: el rollback ahora es inmediato. Si algo sale mal en producción, revertir al estado anterior toma dos minutos, no dos horas de intentar recordar qué archivos se cambiaron.
Fase 4: Monitoreo (1 día)
Con el sistema en producción en su nuevo entorno, el último paso es agregar visibilidad básica: un endpoint de health check que verifica que el sistema y la base de datos están respondiendo, y una alerta que notifica por Slack si hay un problema antes de que el usuario lo reporte.
El setup toma menos de un día y elimina la situación más común en sistemas legacy: enterarse de que el sistema cayó porque alguien llamó a preguntar por qué no podía entrar.
Resultados: 6 meses después
El sistema sigue siendo el mismo PHP de siempre. Pero ahora:
- Los deploys son automáticos en 4 minutos — antes tomaban 20-40 minutos y ocurrían con miedo
- Cero incidentes por deploy manual desde la migración
- El equipo puede hacer cambios con confianza porque saben que pueden revertir en 2 minutos
- El monitoreo alerta antes de que el usuario reporte el problema
- Uptime del 99.97% en el primer trimestre post-migración
La siguiente fase, que ya está planificada, es separar gradualmente los módulos más independientes en servicios más pequeños. Pero eso es trabajo para el año que viene. Por ahora, el negocio opera sin sobresaltos y el equipo duerme tranquilo.
Lo que aprendimos
No cambies lo que no tienes que cambiar. El objetivo era modernizar la infraestructura, no reescribir el negocio. Cada cambio de código que no era necesario para contenedorizar se descartó.
La auditoría es la fase más importante. Las sorpresas que aparecen en producción el día del go-live siempre vienen de dependencias que no mapeaste al inicio.
El rollback es tan importante como el deploy. Antes del primer deploy automatizado, hay que tener claro cómo revertir. Si no está definido, no estás listo para desplegar.
