La IA abarató la mitad fácil de migrar un sistema legacy y dejó la mitad cara justo donde estaba. Leer un sistema viejo nunca fue lo que mataba estos proyectos. Cambiarlo mientras la gente dependía de él, sí, y nada de lo que salió en los últimos dos años cambia eso.

El mercado de modernización se reacomodó alrededor de la primera mitad, y el reacomodo es real. Los agentes de código ya leen un repositorio completo, mapean sus dependencias, recuperan reglas de negocio que nadie documentó, revisan cómo vienen los datos viejos, traducen código entre lenguajes y dejan los cambios listos para que alguien los revise. Lo que antes eran meses de arqueología hoy son semanas. El error es cotizar esa compresión como si fuera el plazo de la migración. Es la fase de análisis, que es otra cosa.

El cambio de sistema es donde se decide el proyecto: los días en que el viejo y el nuevo están prendidos al mismo tiempo y la operación va pasando de uno a otro. Migramos RxVantage, una plataforma de datos farmacéuticos que usan profesionales de salud para tomar decisiones sobre pacientes, de un monolito a microservicios dirigidos por eventos. Entender el código viejo nunca fue la restricción. Que nadie perdiera acceso a media jornada, sí. Corrimos los dos sistemas en paralelo detrás de banderas de características, movimos primero los servicios de bajo riesgo en horas de poco tráfico, y pasamos el tráfico despacio para poder revertir al instante. Los resultados publicados fueron "50% de reducción en costos de servidor", "30% más rápido en tiempos de despliegue" y "Cero tiempo de inactividad durante la migración".

Cada una de esas decisiones fue un juicio sobre cuánto se rompe si algo sale mal, y ninguna es una pregunta de código. Cuál servicio va primero. Qué señal demuestra que el camino nuevo está bien y no solo que responde. Quién está despierto cuando se hace el cambio, y quién tiene la autoridad para regresarse. Un agente que traduce el repositorio fielmente te entrega todo ese trabajo intacto, y te lo entrega antes.

Por qué una traducción fiel también rompe cosas

Las migraciones fallan por lo que nadie escribió en ningún lado. Un sistema viejo acumula reglas que solo viven en su código: el descuento que le das a dos clientes desde hace años, la forma en que cancelas una factura, un redondeo que alguien ajustó a medianoche. Un agente reproduce todo eso con fidelidad, incluido el error que la regla estaba tapando, porque el código no distingue entre una decisión y un accidente. Lo más peligroso es la falla silenciosa de datos: un registro que cargó limpio pero significa otra cosa del otro lado, y que nadie ve hasta que lo ve un cliente. Que el sistema nuevo pase sus pruebas no es evidencia de que se comporte como el anterior.

Si tu negocio corre sobre un sistema viejo, esto te importa más que a una empresa grande, que tiene un equipo para absorber una semana mala. Tú tienes el punto de venta, el inventario y la facturación en el mismo lugar, y un día caído es un día de ventas que no vuelve. Antes de firmar, siéntate una tarde y escribe la lista de cosas que tu sistema hace y que nadie documentó. Esa lista es tu verdadero contrato.

Cómo migrar sin parar la operación

Hay dos caminos: cambiar todo de golpe un fin de semana, o mover el sistema por partes mientras el viejo sigue operando. Para un negocio que no puede cerrar, el segundo es el sensato, y tiene un costo: mientras dura la corrida en paralelo pagas dos sistemas, dos licencias y dos soportes, y tu gente revisa lo mismo dos veces. Esto es lo que no recortaríamos:

  • Corre los dos sistemas con operaciones reales y compara los resultados, no solo que el nuevo responda. Cuadra los datos, porque ahí se esconden las fallas silenciosas.
  • Mueve primero lo de menor riesgo, en horas de poco movimiento.
  • Ten ensayado el regreso al sistema viejo, y que tarde minutos, no días.
  • Sostén el traslape un cierre de mes completo, con su facturación y su corte de inventario, no una semana tranquila.
  • Define quién decide regresarse si el lunes los números no cuadran.

Con la plataforma de marcadores en vivo de Sky Sports usamos el mismo método cuando Flash dejó de existir: el sistema viejo y el nuevo en paralelo, probados con usuarios reales durante partidos reales, primero en amistosos, luego en partidos de liga y al final en las finales de la Champions League. El resultado fue "Cero tiempo de inactividad durante eventos principales".

En RxVantage lo que más nos costó no fue técnico. El cuello de botella era la estructura del equipo: todos esperaban permiso de todos para lanzar. Reorganizamos en pods pequeños y autónomos, cada uno dueño de una porción completa de la plataforma. En un negocio chico el mismo problema aparece en otro tamaño: cómo funciona de verdad la operación vive en la cabeza de una o dos personas, y la migración solo avanza cuando esas personas tienen tiempo. Si nadie les liberó esas horas en el plan, el plan no existe.

Cuando un proveedor te cotice una migración acelerada con IA, separa las dos mitades antes de firmar. Pregunta qué cubre el número: leer y traducir el código, o mover la operación de verdad con una vuelta atrás que alguien ya ensayó. Pregunta cuántas semanas van a convivir los dos sistemas, quién contesta el teléfono la semana del cambio, y cuánto tarda regresar al sistema viejo si algo falla a las once de la mañana. Si te contesta con una fecha de entrega y no con un orden, te están cotizando la parte fácil. Lo mismo aplica a con quién lo haces: leer el código ya es trabajo de pocas personas, y el cambio de sistema es donde quieres experiencia.

Una migración no termina cuando el código nuevo está bien. Termina cuando nadie se dio cuenta.