Cómo migrar una aplicación heredada a Laravel sin detener el negocio

Una migración no empieza dibujando pantallas nuevas. Empieza entendiendo qué hace realmente el sistema anterior, qué datos son confiables y qué procesos no pueden detenerse. En proyectos reales, el código cuenta sólo una parte de la historia: las excepciones viven en hojas de cálculo, tareas manuales y conocimiento de los usuarios.

1. Construir un inventario verificable

Documento módulos, roles, tablas, integraciones, tareas programadas, reportes y archivos. Para cada flujo registro entrada, reglas, resultado y responsable. También identifico cuál sistema es la fuente de verdad.

Pedido → validación de stock → pago → comprobante → despacho

Este mapa permite migrar procesos completos. Copiar primero usuarios y después descubrir que los permisos dependían de una tabla oculta suele generar más trabajo que avanzar por capacidades.

2. Diseñar el modelo objetivo

Laravel no debe convertirse en una copia elegante del esquema antiguo. Defino entidades y límites, pero conservo identificadores de origen para reconciliar registros.

Schema::create('customers', function (Blueprint $table) {
    $table->id();
    $table->string('legacy_id')->nullable()->index();
    $table->string('name');
    $table->string('email')->nullable();
    $table->timestamps();
});

Las transformaciones importantes se documentan: zonas horarias, estados equivalentes, monedas, valores nulos y duplicados.

3. Crear una migración repetible

La importación debe poder ejecutarse varias veces sin duplicar información. Uso lotes, claves estables y transacciones pequeñas.

LegacyCustomer::query()->chunkById(500, function ($rows) {
    foreach ($rows as $row) {
        Customer::updateOrCreate(
            ['legacy_id' => $row->id],
            ['name' => trim($row->name), 'email' => $row->email]
        );
    }
});

Después comparo conteos, totales financieros, relaciones huérfanas y muestras elegidas por usuarios. Los datos ambiguos producen un reporte; nunca se “corrigen” silenciosamente.

4. Elegir una estrategia de transición

Para sistemas grandes prefiero migración gradual. Un módulo o flujo pasa al nuevo sistema mientras el resto continúa operando. Durante la convivencia queda explícito quién puede escribir cada dato. La doble escritura sin reglas claras crea divergencias difíciles de reparar.

Cada etapa necesita criterios de entrada, aceptación y reversión. Antes del cambio final ensayo el procedimiento con una copia reciente y mido cuánto tarda.

5. Operar después del corte

Monitorizo errores, colas, rendimiento y diferencias de negocio. Mantengo accesible el sistema anterior en modo consulta durante un periodo acordado y conservo una copia auditable.

La migración termina cuando los usuarios completan sus flujos, los datos cuadran y el equipo puede operar el nuevo sistema con confianza; no cuando aparece por primera vez la pantalla de inicio de Laravel.