Las migraciones siempre se ven bastante ordenadas en el planning. Hay una plataforma actual, una plataforma nueva, una fecha y una serie de actividades que deberían llevarnos desde un punto hasta el otro.
Después empiezas a trabajar realmente en la migración y aparecen las dependencias, los equipos, las ventanas de cambio, las validaciones, los rollbacks y todas esas pequeñas cosas que no cabían en la primera línea del roadmap.
Y con los años hay algo que he visto repetirse bastante: los problemas suelen aparecer en los detalles. No necesariamente porque alguien haya hecho mal su trabajo, sino porque cuanto más crítica y más antigua es una plataforma, más cosas existen alrededor de ella. Y muchas solamente se hacen visibles cuando empiezas a moverlas.
La escala cambia. Algunas reglas no tanto.
Una de mis primeras experiencias con migraciones fue en Chile, trabajando en infraestructura de red para centros médicos. Había que renovar redes bastante antiguas. Eso significaba preparar previamente switches y routers, crear VLANs, dejar las configuraciones listas y después ir físicamente al centro médico para hacer el cambio.
Las ventanas eran normalmente de madrugada. Recuerdo estar ahí, desmontando infraestructura antigua, levantando la nueva red y coordinando con el proveedor para activar la conectividad hacia la MPLS corporativa. Hasta que todo volvía a funcionar, el trabajo no estaba terminado.
Hoy los proyectos tienen otra escala, pero varias reglas siguen siendo las mismas: preparar antes, saber qué tiene que pasar, tener a las personas correctas disponibles, ejecutar en un orden claro y validar antes de seguir.
Una migración casi nunca afecta solamente a la plataforma que estás cambiando
Con el tiempo los proyectos fueron creciendo bastante en tamaño y complejidad. En una migración de plataforma de video en Suiza, por ejemplo, el cambio no se limitaba al hardware. También había que mover componentes locales, actualizar software de los packagers, revisar perfiles, adaptar configuraciones y asegurar que la distribución de los servicios siguiera funcionando correctamente.
Cada una de esas piezas tenía sus propias dependencias. Y cada una tenía que cambiar en el momento correcto. Ese tipo de proyecto deja bastante claro algo que desde fuera no siempre se ve: una plataforma casi nunca vive sola.
Puedes cambiar correctamente el hardware y aun así tener un problema más adelante. Puedes tener el software funcionando y fallar en distribución. Puedes tener los servicios disponibles y descubrir una configuración local que nadie había considerado. Por eso entender dependencias antes de producción termina siendo una de las partes más importantes del trabajo.
Antes de producción ya debería haber ocurrido mucho
Mi trabajo normalmente está bastante cerca del deployment y de la llegada a producción. Pero cuando empieza la ventana de cambio, gran parte del trabajo importante ya debería estar hecho.
Primero intentamos reproducir todo lo posible en preproducción. Validamos funcionalidad, ejecutamos los pasos, revisamos integraciones y confirmamos qué debería ocurrir después de cada actividad. De ahí sale el runbook.
Y un buen runbook no debería ser solamente una lista de comandos. Tiene que dejar claro qué hacemos, en qué orden, quién lo hace, quién valida, qué esperamos ver, qué hacemos si algo no ocurre como esperamos y cómo volvemos atrás.
En una ventana grande puedes tener muchas personas conectadas al mismo tiempo. Eso no garantiza coordinación. Si las responsabilidades no están claras antes, tener veinte personas en una llamada no resuelve demasiado.
Producción siempre es otro animal
Puedes probar muchísimo. Y debes hacerlo. Pero preproducción nunca es exactamente producción. En producción aparecen usuarios reales, carga real, más servicios, configuraciones que llevan años existiendo y combinaciones que no siempre puedes reproducir completamente antes.
Además, ahí está el negocio: los clientes, los KPIs, la operación y el impacto económico de un problema.
Por eso pasar todas las pruebas no significa que podamos asumir que todo va a comportarse exactamente igual. Significa que hemos reducido bastante el riesgo. Todavía queda producción.
Por eso intento empezar pequeño
Una de las cosas que más sentido me ha hecho en migraciones grandes es evitar mover demasiado de una sola vez. Si podemos empezar con diez canales, empezamos con diez. Si podemos empezar con un package, empezamos con un package.
Migramos, validamos, medimos, escuchamos a las operaciones y observamos. Si aparece un problema, el impacto está contenido. Si todo funciona, el siguiente batch parte con mucha más información.
Eso puede parecer más lento en el planning. Pero encontrar un problema después de mover diez servicios es muy diferente a encontrarlo después de mover cinco países.
Migrar por batches también significa dejar tiempo para aprender
En uno de los proyectos en los que estoy trabajando actualmente estamos migrando una plataforma DRM. El cambio afecta contenido lineal y no lineal, replay, VOD, integraciones de back office y componentes locales.
No existe un botón que diga “migrar DRM”. Hay varios cambios. Primero preparar. Después mover una parte, mantener durante un tiempo la capacidad de volver atrás, observar y solamente después continuar.
Por eso después de ciertos cambios dejamos periodos de estabilidad. Hay problemas que aparecen inmediatamente. Otros necesitan tráfico. Otros aparecen un fin de semana o con una función específica.
Las semanas en las que aparentemente no pasa nada también forman parte de la migración. No estamos esperando porque sí. Estamos esperando evidencia.
El rollback tiene que existir de verdad
Mientras todavía estamos aprendiendo, es importante mantener una forma clara de volver atrás siempre que sea técnicamente posible. Operaciones tiene que saber qué cambió, qué debe revertirse, en qué orden y quién valida después.
No basta con poner una línea en el plan que diga “Rollback available”. Tiene que seguir siendo posible ejecutarlo. Porque a medida que la migración avanza puede llegar un punto donde volver atrás deja de ser sencillo.
Ese momento debería ser una decisión consciente. No algo que descubrimos cuando ya necesitamos hacerlo.
Y mientras migras, el resto del trabajo sigue
Una migración importante rara vez es lo único que está haciendo el equipo. Siguen existiendo upgrades, mantenimiento, otros deliveries, problemas de producción y requerimientos de diferentes operaciones.
Entonces la planificación empieza a ser crítica. No solamente necesitas saber si puedes ejecutar técnicamente un cambio. También tienes que saber si las personas están disponibles, si otra actividad depende de la misma plataforma, si existe una ventana operacional y qué pasa con el resto del plan cuando una fecha se mueve. En proyectos grandes, una desviación pequeña al principio puede terminar desplazando muchas cosas al final.
Y ahí hay una parte importante del project management. No hacer que el proyecto parezca siempre bajo control, sino hacer visible qué está confirmado, qué todavía tiene incertidumbre y qué podría moverse si alguno de los supuestos cambia.
Los deadlines importan. Muchísimo. Pero acelerar una fecha no siempre significa acelerar una migración. A veces simplemente significa asumir más riesgo.
Hoy también tenemos mejores herramientas
Estamos empezando a utilizar herramientas basadas en IA para ayudarnos con timelines, dependencias, diagramas y planes que empiezan a tener demasiadas piezas. No para tomar decisiones por nosotros. Simplemente para tener mejor visibilidad y reducir parte del trabajo manual alrededor de la planificación.
Al final, sigo volviendo a los detalles
Las cosas grandes normalmente reciben mucha atención. Todo el mundo sabe que estamos cambiando una plataforma. Todo el mundo sabe que existe una fecha importante.
Lo que termina preocupándome más son las cosas pequeñas alrededor: una configuración diferente en un país, una llamada de backend que cambia, un paso del runbook que tiene que ocurrir antes que otro, una validación que todos pensaban que hacía otro equipo, una dependencia antigua que no estaba documentada. Ahí aparecen muchas de las sorpresas.
Por eso una migración necesita arquitectura, conocimiento técnico y planificación. Pero también necesita bastante atención a los detalles. No porque podamos anticipar absolutamente todo, eso es imposible, sino porque cuantos más supuestos consigamos confirmar antes de producción, menos sorpresas dejamos para la ventana de cambio.
Una migración no es una noche de cambio
Quizás esta sea la forma más simple en que hoy veo estos proyectos. La migración no empieza cuando abrimos la ventana. Y tampoco termina cuando cerramos el change request.
Empieza mucho antes: entendiendo dependencias, probando, preparando, coordinando equipos y construyendo el runbook. Después llega producción. Movemos una parte, medimos, esperamos, aprendemos, corregimos y aumentamos la escala.
El objetivo no es conseguir que nunca aparezca un problema. En sistemas grandes eso sería poco realista. El objetivo es que, cuando aparezca, el impacto sea manejable, tengamos suficiente información para entenderlo y todavía conservemos una forma de volver atrás.
Para mí, ahí está gran parte del trabajo real detrás de una migración compleja.
Lecturas relacionadas:
✍️ Claudio from ViaMind
“Atrévete a imaginar, crear y transformar.”
POST DESTACADOS
SOBRE MI
Ecosistema ViaMind
- ViaMind — El núcleo de ideas, tecnología y estrategia.
- NeuraPRO — Software práctico para gestionar operaciones reales.
- ViaMind Radar — Menos ruido, más señal. Historias de tecnología curadas con IA.