Toda migración empresarial que hemos visto presentar comienza con la misma visión: un fin de semana dramático de corte, el sistema antiguo apagándose, el nuevo encendiéndose, champán el lunes por la mañana, un comunicado de prensa para el almuerzo.
Toda migración empresarial que hemos visto tener éxito se ve completamente diferente.
Las mejores migraciones son aburridas. Se despliegan gradualmente, módulo por módulo, durante semanas. Los usuarios no reciben un memo. Reciben un enlace a una nueva URL que hace lo mismo, solo que más rápido y en un navegador.
Por qué lo gradual supera al big-bang
Los cortes big-bang comprimen todo el riesgo en un solo momento. Una regla de validación omitida, un formato de datos inesperado, un problema de carga bajo tráfico real — cualquiera de ellos afecta a toda la organización a la vez. El rollback significa volver a Oracle Forms, lo que significa admitir que el proyecto fracasó, lo que significa consecuencias políticas que nadie quiere absorber.
La migración gradual distribuye el riesgo en el tiempo. El módulo 1 se entrega a 20 usuarios. Lo usan durante dos semanas. Los problemas salen a la superficie y se corrigen. El módulo 2 se entrega. Se repite. Para cuando el último módulo se cambia, el proceso es rutinario y el equipo está calibrado.
En 2010 observé a un distribuidor europeo intentar un corte big-bang clásico un sábado por la noche. El antiguo sistema Forms se apagó a las 10 PM, el nuevo cliente Java arrancó a las 2 AM, y a las 9 AM del lunes el CEO estaba en una llamada exigiendo que revirtiéramos todo porque los operarios de almacén no podían escanear las recepciones. El defecto real era trivial — un campo de código de barras truncado en 12 caracteres en lugar de 14 — pero para entonces el daño político ya estaba hecho y el proyecto perdió otros nueve meses en una “fase de estabilización” que en realidad era una replanificación. Esa mañana de lunes es la razón por la que me niego a cotizar un corte en un solo fin de semana, nunca.
La operación en paralelo es el requisito arquitectónico
Este patrón solo funciona si ambos sistemas pueden ejecutarse simultáneamente. La aplicación Oracle Forms y la nueva aplicación web tienen que coexistir contra la misma base de datos durante todo el tiempo que dure la migración.
Suena complicado. No lo es, cuando la arquitectura lo soporta. El nuevo sistema lee y escribe a través de una capa de REST API. El sistema antiguo lee y escribe a través del acceso nativo a Oracle. Ambos apuntan a las mismas tablas. Ambos ven los mismos datos. Un usuario puede ingresar una factura en Forms y verla inmediatamente en la nueva web UI, o viceversa. La base de datos sigue siendo la fuente de verdad. La interfaz es solo una ventana hacia ella.
Cómo luce realmente la experiencia del usuario
El despliegue ideal para un usuario final funciona así:
- Llega un correo electrónico: “Su nuevo módulo de Contratistas está listo en app.company.com/contractors.”
- Lo abren. Se ve moderno pero familiar. Los mismos datos están ahí. Los mismos botones hacen las mismas cosas.
- Ingresan algunos registros. La validación se comporta de la misma manera. La búsqueda es más rápida. Las columnas se ordenan. Funciona en una tablet.
- Una semana después, se han olvidado por completo de Oracle Forms.
Sin sesiones de capacitación. Sin manual de usuario de 50 páginas. Sin iniciativa de gestión del cambio. Solo una mejor herramienta que se comporta de la misma manera que la anterior. Esa es la migración que nadie nota, y en nuestra experiencia es la única que realmente tiene éxito a escala empresarial.