Migración de sitios PHP heredados sin interrumpir las operaciones comerciales

En DigiForge, hemos visto demasiados proyectos de migración de PHP heredado salir mal, no porque la tecnología fuera difícil, sino porque el negocio seguía funcionando durante el traslado. La palabra "migración" proviene del latín para mudarse de un lugar a otro, y en informática significa específicamente "comenzar a usar un nuevo sistema informático, o mover información de un tipo de sistema a otro" [1]. Eso suena sencillo, pero cuando migras un monolito PHP que maneja pedidos, sesiones de usuario e integraciones de pago, el verdadero desafío es asegurarte de que tus clientes nunca noten nada.

Evalúa antes de tocar una línea de código

Antes siquiera de pensar en escribir nuevos enrutadores o instalar un framework moderno, auditamos la aplicación existente, no solo su código, sino su comportamiento en tiempo de ejecución. Comienza con un inventario exhaustivo de todos los puntos de entrada: cada ruta, cada tarea cron, cada tarea en cola. Las aplicaciones PHP heredadas suelen tener endpoints ocultos, tal vez un cron.php que ejecuta la nómina cada domingo, o un endpoint API personalizado usado por un servicio de envío de terceros. Si te pierdes uno, la migración romperá algo.

Durante la auditoría, documenta también el flujo de datos: ¿cómo se conecta la aplicación antigua a la base de datos? ¿Hay procedimientos almacenados? ¿Hay un sistema de archivos compartido para imágenes subidas o archivos de sesión? Muchas aplicaciones PHP heredadas dependen de sesiones basadas en archivos, que no escalan horizontalmente. Esa es una señal de alerta que abordamos temprano, a menudo migrando las sesiones a Redis o una base de datos.

Elige una estrategia de migración que se ajuste a tu tolerancia al riesgo

En DigiForge, solemos recomendar una de tres estrategias, dependiendo de cuánto riesgo pueda asumir el negocio.

La reescritura Big Bang

Esta es la más drástica: construyes el nuevo sistema desde cero y luego cambias todo de una sola vez. También es la más arriesgada. Hemos visto que funciona solo cuando la aplicación heredada es pequeña (piensa en unas pocas docenas de páginas) o cuando el negocio puede tolerar una ventana de mantenimiento planificada. Para cualquier cosa con transacciones en tiempo real o clientes 24/7, evita este enfoque.

El patrón de la higuera estranguladora

Nombrado en honor a la planta tropical que envuelve lentamente a su huésped, este patrón permite reemplazar piezas de la aplicación heredada de forma incremental. Enruta URL o endpoints de API específicos al nuevo código mientras el resto sigue funcionando con el antiguo PHP. Un balanceador de carga o proxy inverso (como Nginx o HAProxy) puede dirigir el tráfico según la ruta de la solicitud. Cada pieza que reemplazas reduce el riesgo porque solo cambias una pequeña superficie a la vez. Usamos este patrón en casi todas las migraciones grandes.

Feature Flags en Todas Partes

Incluso con un higo estrangulador, los feature flags te dan un interruptor de seguridad. Si el nuevo endpoint de checkout lanza errores, activas una bandera y el tráfico vuelve al código antiguo, todo sin necesidad de un despliegue. Herramientas como LaunchDarkly o un simple interruptor basado en base de datos funcionan bien. Codificamos todo detrás de una bandera, incluso la conexión a la base de datos. De esa forma, podemos probar una nueva consulta en producción con solo unos pocos usuarios antes de lanzarla a todos.

Ejecuta la Migración con Cero Tiempo de Inactividad

Cero tiempo de inactividad no significa cero riesgo: significa que el usuario nunca ve una página de error. La clave es la escritura dual: cuando te mueves a un nuevo esquema de base de datos o a un backend de almacenamiento diferente, escribe datos tanto en el sistema antiguo como en el nuevo simultáneamente. Comienza escribiendo en ambos, leyendo del antiguo. Una vez que el nuevo sistema se ha puesto al día y has verificado la integridad de los datos, cambia las lecturas al nuevo sistema. Finalmente, deja de escribir en el sistema antiguo. Esto funciona para bases de datos, colas, almacenamiento de archivos e incluso integraciones de API.

<?php
// Example: dual-write to old and new databases
$legacyDb = getLegacyConnection();
$newDb = getNewConnection();

function saveOrder($orderData) {
    global $legacyDb, $newDb;
    // Write to both
    $legacyDb->insert('orders', $orderData);
    $newDb->insert('orders', $orderData);
}

// Read from legacy until we verify new data
function getOrder($orderId) {
    global $legacyDb;
    return $legacyDb->fetchOne('SELECT * FROM orders WHERE id = ?', [$orderId]);
}

Durante la fase de escritura dual, ejecutas scripts de reconciliación cada pocos minutos para comparar los dos almacenes. Cualquier divergencia se detecta rápidamente. Una vez que el nuevo sistema coincide durante un ciclo completo de negocio (normalmente 48 horas), cambias las lecturas. Supervisa de cerca los registros de errores durante la siguiente hora; si algo parece incorrecto, revierte el cambio.

Manejo del Estado de Sesión

El PHP heredado a menudo usa $_SESSION almacenado en archivos. Una nueva aplicación Laravel o Symfony probablemente espera sesiones en base de datos o Redis. Para mantener a los usuarios conectados durante la migración, implementamos un puente de sesión: la aplicación antigua escribe las sesiones tanto en archivos como en un almacén Redis compartido; la nueva aplicación lee desde Redis. Una vez completada la migración, desactivas el escritor de archivos y eliminas el manejador de sesiones antiguo.

Validación Posterior a la Migración y Planificación de Reversión

Incluso con una planificación cuidadosa, algo saldrá mal. No es pesimismo, es realismo de ingeniería. Antes de activar el interruptor final, redacta un plan de reversión que incluya restaurar los registros DNS, revertir los cambios en el esquema de la base de datos y poner en marcha la aplicación anterior desde una instantánea. Practica la reversión en el entorno de staging al menos una vez.

En DigiForge, siempre mantenemos el entorno de producción anterior funcionando durante al menos dos semanas después de una migración importante. El costo de unos pocos servidores adicionales es trivial comparado con el costo de una reversión fallida que lleva horas.

La validación va más allá de comprobar que las páginas cargan. Ejecutamos pruebas automatizadas de transacciones comerciales: realizar un pedido, actualizar un perfil, procesar un reembolso. Comparamos la salida de los endpoints críticos de la API entre el sistema antiguo y el nuevo. Si usas una herramienta de monitoreo como New Relic o Sentry, configura alertas personalizadas para cualquier error 5xx o consultas lentas. Finalmente, involucra al equipo de negocio: pídeles que ejecuten sus flujos de trabajo diarios en el nuevo sistema en un entorno de staging antes de la puesta en producción.

Errores comunes y cómo los evitamos

• Asumir que el código antiguo es correcto. El PHP heredado a menudo tiene errores silenciosos que se convirtieron en 'funcionalidades'. ¿Replicar cada comportamiento? A veces es más seguro corregir el error en la nueva versión si el negocio está de acuerdo.
• Olvidar los cron jobs y las tareas programadas. ¿Esas antiguas llamadas curl a un script personalizado? Necesitan un lugar en el nuevo sistema. Migramos las tareas cron a un programador de tareas como el scheduler de Laravel o un worker dedicado.
• Descuidar las integraciones de terceros. Las pasarelas de pago, las APIs de envío y los webhooks de socios envían datos en formatos específicos. Prueba los endpoints de integración temprano; no querrás descubrir una discrepancia de formato el Black Friday.

Otra lección que hemos aprendido: no confíes en la documentación antigua. El código es la fuente de la verdad. Siempre realizamos una inmersión profunda en el código con el desarrollador que escribió el original (si está disponible) o con un miembro del equipo que lo ha mantenido durante años. Su modelo mental de las peculiaridades de la aplicación es invaluable.

Conclusión

Migrar un sitio PHP heredado es como realizar una cirugía a corazón abierto a un paciente que está corriendo un maratón. El riesgo es real, pero la recompensa — rendimiento moderno, seguridad y productividad del desarrollador — es enorme. En DigiForge, hemos guiado a docenas de empresas a través de este proceso. La clave es avanzar en pasos pequeños y reversibles, mantener siempre el sistema antiguo funcionando y nunca dejar de monitorear hasta estar seguros de que el nuevo sistema es estable.

Recuerda: la migración no se trata solo de la tecnología, sino de mantener tu negocio operativo mientras cambias el motor en pleno vuelo. Planifica cuidadosamente, prueba sin descanso y ten siempre una reversión lista. Tus usuarios nunca sabrán que algo cambió.