Retail y
Legacy
Migration:

En retail, una caída durante una temporada de alta demanda no afecta solamente a TI. Puede impedir una compra, desordenar el inventario, duplicar pedidos, generar devoluciones y convertir un problema técnico en una pérdida de ingresos y confianza. El calendario hace que el problema sea especialmente sensible: el último trimestre concentra una parte importante de la actividad comercial y eventos como Buen Fin y Navidad elevan simultáneamente el tráfico, las promociones y la presión sobre inventarios.

En México, El Universal reportó que Buen Fin y la temporada navideña pueden representar hasta 40% de la facturación anual de un negocio. En paralelo, Queue-it reporta que 46% de los compradores dejaría de comprar con un retailer después de una caída de su sitio durante Black Friday. Estas cifras no describen a todas las empresas por igual, pero muestran por qué la disponibilidad del canal digital y la consistencia del checkout se convierten en variables de negocio durante una ventana de alta demanda.

El diagnóstico de sobreventa también requiere precisión. No siempre es un problema de latencia. En muchos entornos, la causa es que no existe una fuente única de verdad de inventario y que la reserva del producto no está protegida por una operación transaccional con control de concurrencia. Dos clientes pueden consultar la misma existencia, ambos iniciar el checkout y ambos terminar con una confirmación cuando el inventario real solo permite una venta. Si los sistemas de comercio electrónico, almacén, POS y ERP actualizan el stock con diferentes tiempos y reglas, el problema puede aparecer incluso cuando cada componente, considerado por separado, funciona.

Por eso agregar microservicios no resuelve automáticamente el cuello de botella. Si la ruta crítica de compra continúa pasando por un ERP monolítico que concentra validaciones, precios, disponibilidad y escritura de pedidos, distribuir otras funciones puede aumentar la cantidad de llamadas y dependencias sin eliminar la restricción principal. La arquitectura debe identificar primero qué operación limita el checkout y después desacoplarla con mecanismos adecuados: colas de mensajería, caché donde sea aplicable, separación de lectura y escritura, sincronización por eventos, control de concurrencia e idempotencia de las órdenes.

El riesgo aumenta cuando el stack de e-commerce o los POS dependen de componentes fuera de soporte o de librerías con vulnerabilidades conocidas. En retail, ese problema no es solo técnico. PCI DSS 4.0 exige procesos para identificar y gestionar vulnerabilidades, mantener componentes protegidos frente a vulnerabilidades conocidas y establecer controles sobre software a medida. La documentación del PCI Security Standards Council establece, entre otros puntos, que las vulnerabilidades de seguridad deben identificarse y gestionarse con base en fuentes reconocidas y niveles de riesgo, y que las vulnerabilidades críticas o de alto riesgo deben atenderse mediante los procesos definidos por la organización.

En consecuencia, un POS o componente de pago que no puede actualizarse fácilmente puede convertirse en un problema de cumplimiento y no únicamente en una deuda técnica. El reto es que el sistema que se quiere proteger también es el que mantiene la operación. Un POS no puede desaparecer durante una modernización de semanas; un ERP no puede dejar de registrar pedidos mientras se construye su reemplazo.

El enfoque de Legacy Migration debe considerar esa coexistencia desde el principio. El primer paso es conocer el comportamiento real. La ingeniería inversa con agentes permite generar mapas de dependencias y extraer reglas de negocio que pueden estar dispersas entre programas, procedimientos, integraciones y bases de datos. La clonación de legados permite llevar ese comportamiento a una implementación nueva y establecer una base para comparar antes de modificar la operación.

En retail, la evidencia puede construirse alrededor de flujos concretos: consulta de inventario, reserva de una unidad, aplicación de promoción, creación de orden, cancelación, devolución, actualización del stock y conciliación con el almacén. Los characterization tests fijan el comportamiento existente para esos casos. El replay puede reproducir secuencias representativas de producción contra el clon para identificar diferencias antes de cambiar el tráfico real.

La coexistencia debe ser igualmente concreta. Durante una migración de checkout, una fachada o proxy puede decidir qué porcentaje de solicitudes continúa en el flujo anterior y qué porcentaje llega al nuevo. Si un pedido nuevo modifica inventario, el diseño debe establecer cómo se mantiene la doble escritura o sincronización necesaria durante el periodo definido, cómo se evita que ambos sistemas creen reservas incompatibles y cómo se reconcilian las diferencias. La idempotencia resulta crítica: si un mismo evento o solicitud se procesa dos veces, el sistema debe poder reconocerlo y evitar una segunda afectación sobre inventario u orden.

El control no termina con el enrutamiento. Cada módulo debe tener criterios de corte: cobertura de casos, discrepancias máximas aceptadas, consistencia de inventario, comportamiento de promociones y conciliación de pedidos. Si los criterios no se cumplen, el tráfico puede mantenerse en el sistema anterior o ejecutarse un rollback por módulo. De esta manera, la migración no depende de una sola decisión irreversible en una fecha determinada. Este enfoque también cambia la forma de enfrentar la temporada alta.

El objetivo no es prometer que todos los flujos estarán “completamente estabilizados” para noviembre sin conocer el alcance del proyecto. El objetivo técnico es definir qué módulos deben quedar fuera de la ruta crítica antes del periodo de mayor demanda, qué tráfico puede coexistir y qué criterios deben cumplirse para aumentar el porcentaje del nuevo sistema.

El mismo principio aplica al ERP. No se trata de erradicarlo de inmediato, sino de sacar progresivamente el monolito de la ruta crítica de compra. Si el checkout puede consultar disponibilidad mediante una capa desacoplada, registrar la reserva mediante un mecanismo transaccional controlado y sincronizar después con el ERP, el núcleo antiguo deja de determinar por sí solo la velocidad y disponibilidad del canal comercial.

Las devoluciones también forman parte de este diseño. Una devolución iniciada en e-commerce debe actualizar el pedido, inventario, estado logístico y, cuando corresponda, la información financiera. Si cada sistema interpreta el evento de forma diferente, pueden aparecer discrepancias de stock o conciliaciones manuales. Una arquitectura basada en eventos, reglas de idempotencia y reconciliación permite tratar la devolución como parte del mismo flujo transaccional que la venta, en lugar de como una excepción que se corrige posteriormente.

La modernización del retail, por tanto, no consiste en sustituir un ERP o un POS por una plataforma nueva y esperar que el problema desaparezca. Consiste en entender qué hace el sistema actual, fijar ese comportamiento, desacoplar el cuello de botella y trasladar tráfico de manera controlada. Con Legacy Migration, la temporada alta deja de ser una fecha contra la cual correr a ciegas y se convierte en un criterio de arquitectura: qué debe estar migrado, qué puede coexistir, qué puede revertirse y qué evidencia permite avanzar.

Fuentes de respaldo para revisión editorial

• IDC, estimación sobre mantenimiento de sistemas legados superior al 78% del presupuesto de TI, citada en Future of Enterprise / CIO & Leader.
• Samy Khatib, KTH Royal Institute of Technology, “COBOL-skills, Where art Thou? An assessment of future COBOL needs at Handelsbanken”, 2016.
• Fondo Monetario Internacional, Global Financial Stability Report 2024, capítulo sobre riesgo cibernético y Banco de Chile.
• TSB Bank, publicación sobre la revisión independiente de la migración de 2018.
• Ba Bain & Company, caso de modernización bancaria y reducción de time-to-market de 39 a 19 días.

Retail y Legacy Migration: sacar el ERP de la ruta crítica antes de temporada alta

Datos duros, implicaciones arquitectónicas y preguntas de decisión para llevar la conversación de contenido a comité ejecutivo.

Qué cambia para un CTO / CIO

La temporada alta convierte arquitectura en revenue. El objetivo no es reemplazar el ERP antes de noviembre; es sacar de su ruta crítica las capacidades que necesitan respuesta inmediata.

• PCI introduce una presión objetiva de parcheo que el legacy debe poder soportar.
• Inventario y reserva necesitan consistencia e idempotencia; microservicios por sí solos no resuelven sobreventa.
• Un freeze de temporada debe basarse en métricas de estabilidad, no en calendario únicamente.

La ventaja no es únicamente técnica. La modernización de banca tiene un efecto directo sobre el negocio. Bain documentó el caso de una institución italiana que, al modernizar la capa de distribución e integración alrededor de su mainframe, redujo el time-to-market de actualizaciones de productos de 39 a 19 días. Ese tipo de diferencia importa cuando fintechs y bancos digitales lanzan mejoras con ciclos mucho más cortos. La experiencia del cliente también entra en la ecuación: una institución puede tener un core robusto y, al mismo tiempo, perder competitividad si cada cambio digital depende de un ciclo largo y riesgoso sobre sistemas centrales.

Preguntas que deberían estar en el steering committee

Un marco de 90 días para pasar de narrativa a evidencia

Del dato a la decisión: arquitectura de temporada alta

Qué debe mirar el CIO antes del siguiente pico.

HOT SALE 2025 generó 42,725 millones de pesos y 19.2 millones de órdenes. Para una empresa concreta, su exposición dependerá de participación y mix de canales; aun así, el dato muestra la densidad transaccional que puede concentrarse en nueve días. La arquitectura que funciona en semana promedio puede fallar por capacity, lock contention, dependencia síncrona o inconsistencias que solo aparecen bajo pico.

Queue-it reporta que 46% de compradores dejaría de comprar con un retailer después de una caída durante Black Friday. Aunque es una encuesta de un proveedor y no un benchmark universal, convierte disponibilidad en una variable comercial medible.

Para el CIO, una caída ya no es solo tiempo fuera: afecta recurrencia y confianza. PCI DSS 6.3.3 agrega presión objetiva. Las vulnerabilidades críticas deben resolverse dentro de un mes de la liberación del parche/update aplicable. Si un POS o componente de pago no puede actualizarse sin semanas de pruebas manuales o riesgo de regresión, la deuda técnica ya se convirtió en un problema de compliance.

Métricas para el war room de retail

Exactitud de inventario, porcentaje de reservas confirmadas, tasa de duplicidad de orden, reconciliaciones pendientes, latencia del checkout, error rate por dependencia, tasa de rollback, capacidad de degradación controlada y freshness entre ERP/WMS/e-commerce. Estas métricas deben existir antes de la campaña, no inventarse durante el incidente.

Modernizacion erp retail sin downtime no significa prometer cero indisponibilidad universal. Significa diseñar coexistencia, autoridad de datos, idempotencia, rutas de fallback y criterios de tráfico. Antes de temporada alta, el objetivo es sacar del monolito aquello que puede comprometer la compra, no terminar un reemplazo total.

Playbook de decisión

Fuentes de datos

Los datos se incluyen como contexto editorial. No se extrapolan como resultados garantizados para un cliente. Cada business case debe recalcularse con su baseline.