El caso

Distribuidora B2B con 240 sucursales en 7 estados, equipo de 1,200 personas, 12 años de operación documentada en una constelación de hojas de Excel vinculadas entre sí, con macros de VBA que nadie en la organización entendía completamente porque el desarrollador original se fue en 2018.

Cuando llegamos, el sistema funcionaba — más o menos. Cinco veces al mes alguien rompía un vínculo accidentalmente y un reporte gerencial salía vacío. Tres veces al año una macro fallaba en silencio y los inventarios se reportaban mal. La empresa quería pasar a un sistema multi-tenant moderno con app móvil para los gerentes de sucursal, pero parar 30 días de operación no era opción.

La estrategia

Optamos por bridge dual-write: durante 6 semanas, ambos sistemas (Excel y nuevo) recibirían toda la operación en paralelo. Un servicio de sincronización aseguraba que cada movimiento en Excel se replicara al nuevo, y viceversa. Después de 6 semanas validados los datos, cortábamos Excel.

Esto fue difícil porque significaba duplicar trabajo en el equipo nuestro: construir la app nueva y construir el bridge. Pero era la única forma de migrar sin paro.

Las fases

  1. Semanas 1–3: Auditoría completa del Excel. Mapeo de cada hoja, cada macro, cada vínculo. Identificamos 14% de data duplicada y 8% de data muerta.
  2. Semanas 4–8: Construcción del nuevo sistema (Postgres multi-tenant + Next.js + app móvil React Native). En paralelo, construcción del bridge.
  3. Semanas 9–10: Bridge en producción con write paralelo. Operación normal en Excel, sistema nuevo recibe sombra.
  4. Semanas 11–12: Bridge bidireccional. Algunos gerentes empezaron a usar la app nueva como primary; el Excel se actualizaba por bridge.
  5. Semana 13: Cutover. Excel se vuelve read-only de archivo histórico. App nueva es primary para todos.
  6. Semana 14: Estabilización + post-mortem.

Qué se rompió

Tres cosas, en orden de gravedad:

Fechas inconsistentes

Excel tenía mezclado dd/mm/yyyy, mm/dd/yyyy, y serial numbers de Excel en la misma columna en diferentes hojas. La normalización tomó dos semanas más de lo planeado y descubrimos que ~3,200 registros tenían fechas imposibles (movimientos en 1900 o en 2086) que nunca nadie había notado.

Reglas de negocio en macros

Una macro calculaba comisiones de gerentes de sucursal con una fórmula que no estaba documentada en ningún lado. Cuando pasamos a la app, las comisiones del primer mes salieron diferentes — ni el cliente sabía cuál era la regla "correcta". Tuvimos que sentarnos con el equipo financiero y reconstruir la regla desde cero.

El usuario que sí estaba usando una funcionalidad rara

En el audit decidimos no migrar una funcionalidad de "reservaciones a 90 días" porque nadie la usaba según las entrevistas. Después del cutover, el gerente de la sucursal de Mérida llamó furioso: él era el único usuario y la usaba todos los días para una operación específica con un cliente clave. Tuvimos que construirla en la siguiente fase.

Cualquier funcionalidad legacy que parezca no usada — alguien la está usando. Audita usage real, no entrevistas.

Resultados

  • Cero días de paro operativo durante migración.
  • Tiempo de generación de reportes mensuales: 3 días → 4 minutos.
  • Errores en reportes financieros: ~5/mes → 0 documentados en los primeros 6 meses post-launch.
  • Adopción de app móvil por gerentes: 92% en 30 días.
  • Costo de infra mensual: $3K MXN (Postgres + hosting), comparado con un licenciamiento ERP cotizado en $140K MXN/año.

Lecciones

Tres que aplicarían a cualquier migración legacy:

  1. Bridge dual-write vale lo que cuesta. Es trabajo extra pero te compra peace of mind y te permite validar antes de cortar.
  2. Audita usage real, no entrevistas. Si tienes acceso a logs o telemetría, úsalos. La gente subestima qué usa y qué no.
  3. Las reglas no documentadas son el riesgo más grande. Más que la data sucia, más que las dependencias raras. Reserva tiempo explícito para reconstruir reglas desde cero con los stakeholders.

Si tienes una situación legacy comparable y no sabes por dónde empezar, platica con nosotros. Hacemos audit técnico de migración como entregable independiente, sin compromiso de implementarlo con nosotros.