Al inicio de una migración legacy, el cronograma siempre parece plausible. El sistema antiguo se entiende, al menos por las personas que lo construyeron. El nuevo sistema está diseñado. El alcance está definido. Seis meses es una estimación optimista, pero no absurda. Doce meses es conservador. Dieciocho sería vergonzoso admitirlo ante los líderes.
Tres años después, la migración todavía está en marcha, se ha cancelado discretamente o ha terminado de una manera que requirió tantos compromisos que algunos de los problemas originales simplemente se reprodujeron en el nuevo codebase. Este no es un resultado inusual. Es el más común.
La explicación a la que recurre la mayoría de los equipos es técnica: el sistema antiguo era más complejo de lo previsto, la nueva plataforma tenía restricciones inesperadas, el modelo de datos no se mapeaba de forma limpia. Estas cosas son ciertas y contribuyen al cronograma. Pero no son la razón por la que las migraciones toman tres años. Las razones son casi completamente organizacionales.
El sistema que estás reemplazando nunca se entiende por completo
Los sistemas legacy acumulan lógica de negocio de la misma manera que los edificios antiguos acumulan muros de carga. Se agregó algo para manejar un edge case en 2009. Se parcheó otra cosa para lidiar con una excepción de un cliente en 2013. Un cálculo se ajustó ligeramente en 2017 porque alguien notó que los números estaban equivocados de una manera que nadie podía articular por completo. La persona que hizo cada cambio puede que ya no esté en la empresa. La razón por la que funciona como lo hace, a menudo, no está escrita en ninguna parte.
La fase de descubrimiento de una migración — la parte en la que averiguas qué hace realmente el sistema antiguo — casi siempre se subestima. Los equipos pasan dos semanas en el descubrimiento antes de comenzar el diseño, no encuentran sorpresas obvias y concluyen que el sistema se entiende bien. Luego pasan los siguientes dieciocho meses encontrando sorpresas.
Un enfoque más honesto es asumir que el sistema legacy contiene aproximadamente tres veces más lógica de negocio no documentada de lo que cualquiera cree actualmente, y planificar el descubrimiento en consecuencia. En la práctica, esto significa ejecutar el sistema antiguo y el nuevo en paralelo durante más tiempo del que resulta cómodo, aceptar que algunos edge cases solo surgirán cuando los usuarios reales los encuentren en producción, y tratar el comportamiento del sistema legacy como la especificación en lugar del documento de requerimientos.
Las personas que conocen el sistema antiguo nunca están completamente disponibles
Los expertos en la materia para una migración legacy — las personas que entienden por qué el sistema se comporta como lo hace — son casi siempre las mismas personas responsables del día a día del negocio. No se les puede asignar de tiempo completo a un proyecto de migración sin que las operaciones que financian el proyecto se degraden.
Lo que típicamente ocurre es un compromiso: los expertos en la materia participan en talleres, responden preguntas a pedido, revisan entregables cuando tienen tiempo. Esto funciona bastante bien durante las primeras etapas, cuando las preguntas son estratégicas. Se convierte en un cuello de botella durante la implementación, cuando las preguntas son específicas: ¿qué debería pasar cuando este campo es null? ¿Es este comportamiento intencional o un bug? ¿Qué significa este código de estado en el contexto de este flujo de trabajo en particular?
Estas preguntas no son difíciles. Cada una toma diez minutos en responderse. Pero hay miles de ellas, surgen de manera impredecible y cada una puede bloquear un sprint si la persona adecuada no está disponible. La migración acumula tiempo de espera en incrementos que nunca aparecen como bloqueos individuales en un reporte de estado, pero que en conjunto representan meses de tiempo calendario transcurrido.
La alineación de los stakeholders se erosiona
El ejecutivo que patrocinó la migración tenía una justificación clara: reducir costos operativos, eliminar deuda técnica, habilitar capacidades que el sistema antiguo no podía soportar. Esa justificación fue lo suficientemente persuasiva como para asegurar un presupuesto y un cronograma. Dieciocho meses después de iniciado el proyecto, ese ejecutivo se ha movido a un rol diferente. Su sucesor heredó el proyecto sin heredar la convicción que lo motivó.
Esta no es una falla de individuos. Es una característica estructural de cuánto tardan las migraciones en relación con la frecuencia con la que cambian las organizaciones. Un proyecto de tres años, en promedio, durará más que la gestión de la persona que lo encargó. Cuando eso sucede, el proyecto pierde su patrocinador organizacional exactamente en el momento en que es más probable que necesite uno: durante la difícil fase intermedia, cuando el sistema antiguo todavía está funcionando, el nuevo sistema aún no está listo y el equipo está pidiendo más tiempo y dinero para cerrar la brecha.
Las migraciones que sobreviven a esta transición son aquellas que tienen un patrocinio distribuido, donde suficientes personas en suficientes niveles entienden por qué existe el proyecto para que pueda sobrevivir a la partida de cualquier defensor individual. Esto es más difícil de crear que un solo patrocinador ejecutivo y rara vez surge de forma natural. Tiene que construirse deliberadamente, por lo general a través de una comunicación regular a una audiencia más amplia que el equipo principal del proyecto.
El ochenta por ciento completado es una trampa
El hito más peligroso en una migración es estar al ochenta por ciento completado. En ese punto, el nuevo sistema maneja todos los casos comunes. Los flujos de trabajo principales funcionan. Se puede hacer una demostración razonable. El veinte por ciento restante es una lista de edge cases, excepciones y escenarios inusuales que se han pospuesto para mantener avanzando el camino principal.
Ese veinte por ciento representa la complejidad acumulada de años de uso en producción. Cada elemento de la lista está ahí porque un usuario real se encontró con una situación real que el flujo de trabajo estándar no manejaba. En conjunto, codifican la mayor parte del conocimiento institucional sobre cómo opera realmente el negocio, a diferencia de cómo se supone que debe operar.
Avanzar a través de ellos es lento, porque cada elemento requiere el mismo ciclo: comprender el escenario original, diseñar cómo se manejará, implementarlo, validarlo con las personas que conocen el dominio. No hay economías de escala. El edge case número cien no es más rápido de manejar que el primero. Y la lista no se reduce de manera constante: tiende a crecer a medida que el nuevo sistema se utiliza más ampliamente y saca a la luz escenarios que antes no se sabía que existían.
Los equipos que alcanzan el ochenta por ciento a tiempo frecuentemente descubren que el veinte por ciento restante toma tanto tiempo como el primer ochenta. Esto no es un error de planificación. Es una propiedad matemática de dónde reside la complejidad en estos sistemas.
Lo que tienen en común las migraciones que sí terminan
Las migraciones legacy que realmente se completan comparten algunas características que no son obvias desde el principio.
Tratan el cutover como un evento que debe diseñarse, no como un umbral que debe cruzarse. El momento en que se apaga el sistema antiguo y el nuevo sistema se convierte en el system of record es el punto de mayor riesgo en todo el proyecto. Las organizaciones que planifican este evento explícitamente —quién puede hacer rollback, bajo qué condiciones, quién toma la decisión, qué constituye una primera semana exitosa— tienen más probabilidades de superarlo sin una crisis que reinicie el cronograma por otros seis meses.
Ejecutan el sistema antiguo y el nuevo en paralelo durante más tiempo del que habían planeado. Esto es costoso y operativamente incómodo. También saca a la luz los edge cases que las pruebas automatizadas no detectan, antes de que se conviertan en incidentes de producción en un sistema que ya no tiene un fallback.
Definen el alcance de la migración para entregar valor de manera incremental en lugar de completarla en un solo cutover. Las peores migraciones son aquellas en las que no se puede desmantelar nada hasta que todo esté terminado. Las mejores identifican qué partes del sistema antiguo pueden retirarse de forma independiente y secuencian el trabajo para entregar victorias visibles antes de que el proyecto cumpla tres años.
Y son honestos, desde el principio, sobre cuál es realmente el cronograma. No para bajar las expectativas artificialmente, sino porque una organización que sabe que un proyecto tomará tres años puede estructurarse para sostenerlo. Una organización que cree que un proyecto tomará seis meses, y a la que se le dice repetidamente que está casi terminado, pierde la paciencia a un ritmo que el proyecto no puede sobrevivir.