Toda la plataforma que has visto en este curso es nueva. Se diseñó en Azure, se construyó en Azure y no arrastra nada. Pero Contoso Airlines no empezó a existir con este proyecto: lleva veinte años funcionando, y en el centro de datos de Barcelona siguen encendidos los sistemas que sostienen buena parte del negocio. El contrato de alojamiento vence dentro de dieciocho meses y la dirección ha pedido una decisión: renovar o migrar.

Esa decisión no es técnica. Mover un servidor es fácil; lo difícil es que después de moverlo la organización sepa operarlo, que alguien sea dueño de su coste, que el equipo que lo administraba a mano acepte que ahora se despliega por pipeline, y que la migración se planifique en oleadas en lugar de en un fin de semana heroico. La mayor parte de los proyectos de migración que fracasan no fracasan por un problema de red: fracasan por falta de caso de negocio, por inventarios incompletos o por resistencia interna que nadie gestionó.

El Cloud Adoption Framework de Microsoft existe exactamente para eso: es la guía que cubre el ciclo completo —estrategia, plan, preparación, adopción, gobierno y administración— y que trata la nube como un cambio organizativo con parte técnica, y no al revés. Esta lección lo recorre entero aplicándolo a lo que queda en Barcelona: el caso de negocio con el TCO ya calculado, el inventario con Azure Migrate, las seis estrategias de migración con la asignación de cada sistema, las zonas de aterrizaje, las oleadas con su calendario y su ventana de corte, la migración de los datos, la vuelta atrás, la gestión del cambio y la retirada del centro de datos con sus costes ocultos.

Recordatorio: todas las cifras son orientativas y ficticias. El TCO real de un centro de datos depende de contratos, amortizaciones y personal que solo conoce cada organización.

1. Qué queda en Barcelona
2. El Cloud Adoption Framework y sus fases
3. Motivaciones y caso de negocio
4. Inventario y evaluación con Azure Migrate
5. Las seis estrategias de migración
6. Zonas de aterrizaje de Azure
7. Oleadas de migración y calendario
8. Migración de datos
9. La ventana de corte y la vuelta atrás
10. Gestión del cambio
11. Retirada del centro de datos
12. Qué se innova después
13. Errores Comunes y Consejos
14. Ejercicios
15. Conclusión

Ya existe una VPN sitio a sitio con vgw-contoso-pro, de modo que la conectividad no es el problema. El problema es que estos seis elementos tienen dependencias entre sí que nadie ha dibujado nunca, y que cada uno tiene un dueño distinto dentro de la organización.

Dos observaciones sobre el marco. Primero, gobierno y administración son transversales, no fases finales: si se dejan para el final, la migración crea en tres meses el desorden que se tardará dos años en limpiar. Segundo, adoptar no es solo migrar: Contoso ya innovó —construyó la plataforma nueva— antes de migrar lo viejo, y ese orden es más común de lo que sugieren los diagramas.

Las motivaciones determinan el orden y el criterio de éxito de toda la migración, así que conviene ordenarlas explícitamente:

El caso de negocio compara el TCO actual con el coste previsto en Azure más el coste del propio proyecto. El dato de partida ya lo tienes: el TCO real del centro de datos de Barcelona es de 340.000 €/año, cifra que incluye lo que casi nadie cuenta al principio.

Con esos números el retorno llega en torno al segundo año, y ese es exactamente el mensaje que hay que dar a dirección: no es un ahorro inmediato. Prometer ahorro el primer mes es la forma más rápida de perder la credibilidad del proyecto, porque durante la migración se paga las dos cosas a la vez: el centro de datos que aún no se ha apagado y Azure que ya está encendido.

Azure Migrate es el centro desde el que se descubre, evalúa y mueve. Su valor no está en el motor de replicación —eso es lo fácil—, sino en el descubrimiento de dependencias, que es lo que revela las sorpresas.

El resultado del descubrimiento en Contoso, con la sorpresa clásica:

Los cinco servidores sin dueño ilustran por qué el descubrimiento se hace antes de planificar: dos de ellos recibían tráfico, así que apagarlos «porque nadie los reclama» habría roto algo. La regla es apagarlos primero de forma controlada —desconexión temporal con vigilancia—, y solo retirarlos si nadie protesta.

La asignación de Contoso, que es donde se ve el criterio:

Nótese la fila más importante: no todo se migra. Un plan de migración honesto tiene una columna de «se queda» y una de «se retira», y ambas mejoran el resultado.

Una zona de aterrizaje es el entorno preparado antes de que llegue la primera carga: identidad, red, gobierno, seguridad, observabilidad y organización de suscripciones ya resueltos, de modo que cada aplicación que aterriza herede todo eso en lugar de improvisarlo.

Lo que resuelve, y que de otro modo se resuelve mal treinta veces:

Contoso ya tiene una zona de aterrizaje incipiente y esa es la buena noticia del proyecto: mg-contoso con mg-contoso-plataforma y mg-contoso-cargas, la iniciativa «Base de gobernanza de Contoso», el hub con firewall y VPN, el área de registros única y los grupos de Entra ID son exactamente los componentes de plataforma de una zona de aterrizaje. Lo que falta para las cargas de Barcelona es una suscripción nueva para las cargas migradas, ampliar el plan de direccionamiento y añadir la resolución de nombres híbrida.

Opciones de implementación, de menor a mayor formalidad: empezar con una zona inicial y madurar después; desplegar el acelerador de zona de aterrizaje empresarial, que crea la jerarquía completa con sus directivas; o construirla a medida con Bicep, que es lo natural cuando ya existen plantillas propias como contoso-infra. Contoso elige la tercera: extender lo que ya tiene.

Migrar todo a la vez es la forma más segura de fracasar. Se agrupan las cargas en oleadas, cada una con su ventana, sus criterios de éxito y su plan de vuelta atrás.

Criterios para agrupar: por dependencia —lo que se habla entre sí va junto—, por riesgo creciente —lo fácil primero, para aprender—, por calendario de negocio —nunca en cierre fiscal ni en temporada alta— y por capacidad del equipo, que es el límite real.

El piloto de la oleada 1 no se elige por importancia sino por capacidad de enseñar: el servidor de archivos toca red, identidad, permisos y usuarios reales, con un impacto bajo si algo sale mal. Un piloto que no enseña nada es un piloto desperdiciado; uno que puede tumbar el negocio no es un piloto.

Y la facturación va la última deliberadamente, pese a ser la que más urge por licencias: es la de mayor riesgo, y para cuando llegue el equipo habrá ejecutado cuatro migraciones. Además su ventana evita el cierre trimestral.

Los datos son la parte que no admite improvisación, porque es la única que no se puede repetir sin consecuencias.

Regla de decisión sobre el volumen: calcula el tiempo de transferencia real con el ancho de banda disponible descontando el tráfico productivo. Doce terabytes por un enlace de 200 Mbps compartido no son «unas horas»; con suerte son varios días de transferencia continua, y por eso existe Data Box.

Para bases de datos, el patrón que minimiza el riesgo es siempre el mismo: carga inicial, replicación continua, validación en paralelo, corte corto. La validación en paralelo —comparar recuentos, sumas de control y algunos informes de negocio entre origen y destino antes de cortar— es lo que convierte el corte en un trámite.

Los dos elementos que hacen que esto funcione son el punto de decisión con hora fija y el origen intacto. Sin hora fija, un corte problemático se alarga «un poco más» hasta que ya no hay tiempo de volver; y la vuelta atrás solo es posible si el sistema original no se ha tocado y se sabe qué datos se han escrito en el destino desde el corte. Por eso los criterios de éxito y de vuelta atrás se escriben antes, cuando nadie está cansado ni bajo presión.

Aquí es donde fracasan las migraciones que técnicamente iban bien. Después de migrar, el trabajo de las personas cambia:

Nuevos papeles que aparecen, y que conviene nombrar explícitamente para que alguien los ocupe: equipo de plataforma —dueño de la zona de aterrizaje, las plantillas y las barreras—, FinOps —Nuria, con dedicación real y no como tarea residual—, y SRE u operación de servicio —dueño de alertas, guardias y fiabilidad—.

La resistencia interna es un riesgo de proyecto tan real como una incompatibilidad técnica, y casi siempre está justificada: quien lleva quince años administrando servidores oye «migramos a la nube» como «tu trabajo desaparece». Lo que funciona, por orden: formar antes de migrar, no después; dar a esas personas la propiedad del nuevo entorno en lugar de traer a alguien de fuera a hacerlo; hacer explícito que el conocimiento de las aplicaciones y del negocio es insustituible; y comunicar con honestidad qué cambia. Lo que no funciona: prometer que nada cambiará.

Migrar no termina cuando arranca la última máquina en Azure: termina cuando el contrato se rescinde, y ahí es donde aparecen los costes que nadie presupuestó.

El último es el que más veces sorprende: se apaga el centro de datos y meses después alguien pide una copia de hace cinco años, y ya no queda ningún lector de cintas. Antes de retirar nada, hay que decidir si el archivo histórico se migra o se conserva legible, y esa decisión afecta al equipo legal.

Migrar no es la meta: es dejar de pagar por mantener lo que no diferencia al negocio para poder gastar en lo que sí. Con Barcelona apagado, lo que se abre para Contoso:

• Facturación modernizada: una vez estabilizada en Managed Instance, refactorizarla hacia App Service y liberar el sistema operativo.
• Analítica sobre datos que antes estaban presos: los datos de mantenimiento y de facturación pueden entrar en stlagocontosopro y cruzarse con reservas.
• Automatización de procesos que hoy dependen de intervención en el centro de datos.
• Elasticidad real en temporada, que era una de las motivaciones originales y hasta ahora solo aplicaba a la plataforma nueva.
• Un segundo emplazamiento sin comprar hierro: la continuidad que nunca existió.

Y una advertencia final sobre el orden: la tentación de rearquitecturar durante la migración es fuerte y casi siempre es un error. Mueve primero, estabiliza, y moderniza después con el sistema ya en Azure y con métricas reales. Quien intenta las dos cosas a la vez suele terminar sin ninguna.

• Empezar por la carga más crítica. El aprendizaje se hace en el piloto, no en la facturación.
• Migrar sin inventario de dependencias. Es lo que provoca el «funcionaba y ahora no» del lunes siguiente.
• Rehospedar todo y llamarlo transformación. Se paga la nube sin ninguna de sus ventajas; si se rehospeda, con fecha de modernización.
• Prometer ahorro inmediato. Durante la migración se paga dos veces; dirección debe saberlo desde el primer día.
• Dejar el gobierno para después. La zona de aterrizaje va antes que la primera carga, siempre.
• No definir criterios de vuelta atrás. Sin ellos, la decisión se toma cansado, de madrugada y mal.
• Olvidar la formación del equipo. Sin ella, la plataforma nueva se opera con hábitos viejos.
• Descuidar el preaviso del contrato. Se puede terminar la migración y seguir pagando un año.
• Consejo: retira lo inútil antes de migrar. Es el trabajo con mejor relación esfuerzo-beneficio del proyecto.
• Consejo: mide y publica el avance en cargas migradas y en coste del centro de datos restante. Un proyecto de 18 meses necesita victorias visibles.
• Consejo: reserva presupuesto para el solapamiento desde el principio; es el sobrecoste más previsible y el que peor sienta cuando aparece por sorpresa.

Ejercicio 1. Asigna una estrategia de migración —rehospedar, refactorizar, rearquitecturar, reconstruir, reemplazar o retirar— a cada uno de estos cinco sistemas de una empresa logística, justificando cada elección y señalando qué información te falta para decidir con seguridad: (a) un ERP comercial con soporte oficial en Azure; (b) una aplicación web propia en .NET Framework con SQL Server; (c) un servidor de correo Exchange local; (d) una aplicación de escritorio que usan 8 personas y que su autor abandonó; (e) un servidor de informes que nadie ha abierto en seis meses.

Ejercicio 2. Diseña las oleadas de migración de esa misma empresa —12 servidores, 4 TB de datos, cierre contable el día 5 de cada mes, temporada alta en noviembre y diciembre, equipo de 3 personas de sistemas— con un plazo de 12 meses. Define el piloto y por qué, el orden de las oleadas, las ventanas que hay que evitar y los criterios de éxito de cada una.

Ejercicio 3. La dirección de una empresa mediana pregunta: «¿migrar a la nube nos ahorrará dinero?». Prepara la respuesta completa: qué elementos incluye un TCO honesto en ambos lados, por qué el ahorro no aparece el primer año, qué beneficios no son ahorro pero sí valor, en qué casos la respuesta correcta es no migrar, y qué compromisos pedirías a dirección antes de aceptar el proyecto.

Solución 1: (a) ERP comercial con soporte en Azure: rehospedar, o refactorizar si el fabricante ofrece una versión gestionada; nunca tocar su arquitectura, porque se pierde el soporte. Falta saber si el contrato de licencia permite ejecución en nube pública y si existe una oferta SaaS del mismo fabricante, en cuyo caso reemplazar podría ser mejor. (b) Aplicación .NET Framework con SQL Server: refactorizar es lo razonable —la base de datos a Azure SQL Managed Instance, que admite características que la base de datos aislada no, y la aplicación a máquinas virtuales o App Service con Hybrid Benefit—; rearquitecturar solo si además se necesita elasticidad y hay presupuesto para pruebas. Falta saber si usa componentes locales del servidor, colas MSMQ, tareas programadas o rutas de disco codificadas, que es lo que suele romper el traslado. (c) Exchange local: reemplazar por Exchange Online; migrar servidores de correo a máquinas virtuales es pagar por seguir administrando lo que ya existe como servicio. Falta conocer volumen de buzones, requisitos de retención y si hay integraciones con aplicaciones internas. (d) Aplicación de escritorio abandonada y usada por 8 personas: la respuesta depende del negocio, no de la tecnología —si el proceso es prescindible, retirar; si es imprescindible, reemplazar por una alternativa comercial, y solo como último recurso rehospedar en un escritorio virtual para ganar tiempo—. Falta saber qué proceso soporta y si existe alternativa en el mercado. (e) Servidor de informes sin uso en seis meses: candidato claro a retirar, pero con el procedimiento correcto: apagado controlado con vigilancia durante un mes antes de eliminar, porque un informe trimestral o anual no aparece en una ventana de seis meses. Falta comprobar accesos reales y preguntar a finanzas.

Solución 2: oleada 0, preparación (meses 1-2): zona de aterrizaje, red y VPN, identidad híbrida, formación del equipo de tres personas —que es el cuello de botella real y por eso la formación es parte del plan, no un extra—, e inventario con análisis de dependencias. Piloto (mes 3): un sistema de bajo impacto pero representativo, por ejemplo el servidor de archivos o un entorno de pruebas completo; enseña red, permisos, transferencia de datos y experiencia de usuario sin poner en riesgo la operación, y permite medir cuánto tarda de verdad el equipo. Oleada 1 (meses 4-5): servidores de infraestructura —identidad y servicios comunes—, porque todo lo demás depende de ellos. Oleada 2 (meses 6-7): aplicaciones de soporte no críticas, agrupadas por dependencia. Oleada 3 (meses 8-9): datos y aplicaciones de negocio de riesgo medio; los 4 TB se planifican aquí, evaluando red frente a Data Box según el ancho de banda real. Oleada 4 (mes 10): el sistema contable, evitando siempre los días 1 a 8 de cada mes por el cierre. Oleada 5 (meses 11-12 con la salvedad siguiente): retirada y cierre. Ventanas prohibidas: noviembre y diciembre completos por temporada alta —lo que en la práctica comprime el calendario y obliga a terminar lo crítico en octubre o desplazarlo a enero—, y los primeros días de cada mes. Criterios de éxito por oleada: aplicaciones accesibles y con rendimiento igual o mejor medido, cero pérdidas de datos verificadas por recuento y sumas de control, incidencias por debajo de un umbral acordado durante dos semanas, origen aún disponible durante 30 días y coste real dentro de la estimación. Un apunte de realismo: tres personas no pueden migrar y operar a la vez, así que o se refuerza el equipo temporalmente o el plazo de 12 meses es optimista.

Solución 3: un TCO honesto del lado local incluye alojamiento, energía y climatización, amortización del hardware y su renovación prevista, licencias de virtualización y sistemas, personal dedicado a mantener infraestructura —el más olvidado—, soporte y contratos, conectividad, copias y su custodia, seguros y, si se quiere ser riguroso, el coste de oportunidad del capital inmovilizado y el riesgo de no tener segundo emplazamiento. Del lado de Azure: consumo de cómputo, almacenamiento y red, salida de datos, licencias trasladadas o nuevas, herramientas de migración, formación, horas de proyecto, consultoría, el solapamiento durante la transición y el coste operativo continuo del nuevo modelo. Por qué no hay ahorro el primer año: porque se pagan las dos infraestructuras a la vez, porque el proyecto tiene un coste único importante y porque las cargas recién migradas están sin optimizar —el ahorro real llega con el dimensionamiento, las reservas y la modernización posteriores—. Beneficios que no son ahorro pero sí valor: elasticidad para picos que antes se perdían en ventas, tiempo de aprovisionamiento de semanas a minutos, continuidad de negocio sin comprar un segundo centro de datos, capacidad de experimentar con coste marginal, servicios que no se pueden construir en casa —IA, analítica—, seguridad y cumplimiento con herramientas de nivel empresarial, y liberar al equipo de tareas que no diferencian al negocio. Cuándo la respuesta correcta es no migrar: cuando el hardware está recién comprado y sin amortizar, cuando existe una restricción legal de residencia o soberanía que no se puede satisfacer, cuando la carga es constante y previsible durante años y sale más barata en local, cuando hay una dependencia física insalvable, cuando la organización no tiene ni puede adquirir las competencias, o cuando la aplicación crítica es un binario sin soporte que nadie sabe reconstruir. Compromisos que pediría a dirección: un patrocinador ejecutivo con capacidad de decidir, presupuesto explícito para el solapamiento y la formación, aceptación por escrito de que el retorno llega en el segundo año, dedicación real de las personas del proyecto —no a ratos entre incidencias— y autoridad para retirar sistemas y decir que no a migraciones que no tienen sentido.

Ya sabes que migrar no es mover máquinas: es un cambio organizativo con una parte técnica. Conoces el Cloud Adoption Framework y sus fases —estrategia, plan, preparación, adopción con migración e innovación, gobierno y administración—, con las dos observaciones que más se olvidan: que gobierno y administración son transversales y no fases finales, y que adoptar incluye innovar, no solo mudar lo viejo.

Sabes construir el caso de negocio partiendo de las motivaciones ordenadas —el contrato que vence, la renovación de hardware, los picos de temporada, la agilidad, el soporte que se retira, la continuidad inexistente— y de un TCO completo: los 340.000 €/año de Barcelona frente a los ≈205.000 € en estado estable más ≈120.000 € de proyecto, con el mensaje honesto de que el retorno llega el segundo año porque durante la migración se paga dos veces. Sabes hacer el inventario con Azure Migrate —descubrimiento, evaluación, dependencias y migración— y por qué las dependencias son lo que revela las sorpresas: 34 servidores donde había 26 documentados, cinco sin dueño y dos de ellos con tráfico.

Manejas las seis estrategias con su esfuerzo, riesgo y beneficio, y la asignación razonada de cada sistema de Contoso, incluidas las dos columnas que mejoran cualquier plan: lo que se retira y lo que se queda. Entiendes qué es una zona de aterrizaje, qué resuelve, su arquitectura conceptual y el hecho de que la jerarquía mg-contoso con su iniciativa de gobernanza, el hub y el área de registros única ya son una zona de aterrizaje incipiente. Sabes organizar oleadas con su piloto elegido por capacidad de enseñar, su calendario de 18 meses que respeta cierres y temporada alta, y sus criterios de éxito; elegir la vía de migración de datos —Database Migration Service, copia y restauración, Data Box para los 12 TB, sincronización de archivos o replicación— con el patrón de carga inicial, replicación, validación en paralelo y corte corto; y ejecutar la ventana de corte con su punto de decisión a hora fija y su vuelta atrás preparada por escrito.

Y sabes lo que casi nunca está en los planes: la gestión del cambio —quién opera qué después, los papeles de plataforma, FinOps y SRE, y la resistencia interna como riesgo real que se gestiona formando antes de migrar y dando la propiedad del nuevo entorno a quien administraba el viejo—, la retirada del centro de datos con sus costes ocultos —solapamiento, preaviso, borrado certificado, licencias con permanencia, restauración del local y las cintas que sobreviven al lector— y qué se innova después, con la regla de oro: mover primero, estabilizar, modernizar luego.

Con esto, Contoso Airlines tiene su plataforma nueva construida y el camino trazado para lo que queda en Barcelona. Queda una última lección, que mira hacia delante en lugar de hacia atrás: hacia dónde va Azure —IA integrada en todo, ingeniería de plataforma, sin servidor por defecto, nube distribuida, sostenibilidad, confianza cero y regulación europea—, cómo mantenerse al día sin ahogarse, y el mapa completo de certificaciones con la que corresponde a tu perfil y qué te falta para presentarte tras este curso.