Cómo planificar oleadas y corte de una migración a la nube en un Gantt

Planifica una migración a la nube en un diagrama de Gantt: mapea dependencias, divide las cargas en oleadas, construye la landing zone en paralelo, ensaya el corte y programa la retirada tras el hipercuidado.

Lo difícil del cronograma de una migración a la nube es decidir qué se mueve junto y qué espera cada oleada. Esta guía muestra cómo convertir un inventario de cargas en oleadas, una landing zone, un corte ensayado y una fecha de retirada.

En resumen

  • Rastrea las dependencias mientras corre el descubrimiento, para conocer las cargas que deben moverse juntas antes de fijar las oleadas.
  • Trata la landing zone como un flujo propio con un hito de listo que la primera oleada espera.
  • Haz primero una oleada piloto y pon una tarea de lecciones aprendidas entre ella y las oleadas mayores.
  • Solapa las oleadas posteriores con un vínculo de inicio a inicio, pero no empieces nunca una oleada antes de que existan sus insumos de ensayo.
  • Retira el origen tras un periodo de hipercuidado y comprueba la fecha de retirada con las fechas de tus contratos.

De una lista de cargas a un plan de oleadas

Un inventario de cargas es una lista. Un plan de migración es un orden. La diferencia son las dependencias: una aplicación no puede moverse antes que la base de datos a la que llama, un trabajo por lotes no puede moverse antes que el recurso compartido en el que escribe, y nada se mueve antes de que exista el lugar al que va. Los equipos que se saltan este paso acaban con oleadas que quedan bien en una diapositiva y fallan el primer fin de semana, porque la mitad de las conexiones de una oleada se quedaron atrás.

El método aquí tiene tres movimientos. Primero, rastrear las dependencias mientras el descubrimiento sigue en marcha, para que los grupos de cargas que deben moverse juntas aparezcan pronto. Segundo, hacer de la landing zone un flujo de trabajo separado, con sus propias tareas y un hito de listo, en lugar de una línea al principio del plan. Tercero, poner la retirada del entorno de origen detrás de un periodo de hipercuidado, para que la pregunta de cuándo puede apagarse tenga una respuesta visible.

Un diagrama de Gantt ayuda con lo que una lista no puede mostrar: qué fecha se mueve cuando se mueve otra. Si la construcción de la red tarda cuatro días más, se mueve la oleada piloto, luego todas las oleadas posteriores y después la fecha de retirada. Si el descubrimiento encuentra una aplicación enmarañada, el plan de oleadas cambia antes que la landing zone. El gráfico no te dice qué estrategia conviene a una carga ni si el destino es seguro. Programa el trabajo que ya has decidido.

El ejemplo construye por etapas la plantilla de migración a la nube. Las duraciones son ilustrativas. Para el proceso y no para el cronograma, consulta el proceso de despliegue en /es/templates/proceso-de-despliegue-de-software y el proceso de recuperación en /es/templates/plan-de-recuperacion-ante-desastres.

Un plan de migración a la nube, construido por etapas

Diecinueve tareas en cuatro fases. Las duraciones son ilustrativas; pon las tuyas. Abre el panel de la hoja de cálculo para ver las filas detrás de cada etapa.

  1. Descubrimiento, dependencias y plan de oleadas

    «Descubrimiento de aplicaciones y servidores» dura 8 días laborables. «Mapa de dependencias» empieza tres días laborables después de su inicio, de modo que el rastreo arranca con los primeros hallazgos. Le siguen «Estrategia de migración por carga» y «Plan de oleadas y ventanas de corte», que terminan en el hito «Plan de migración aprobado».

  2. La landing zone, construida junto al plan

    «Diseño de la landing zone» empieza cuando se conoce la estrategia, no cuando se aprueba el plan. «Construir red y conectividad» dura 10 días laborables e «Identidad, seguridad y registros» dura 8, y empieza dos días laborables después del inicio del diseño. «Landing zone lista» espera a ambas.

  3. Primero el piloto, luego las oleadas mayores

    «Migración piloto de la oleada 1» (8 días laborables) espera a «Plan de migración aprobado» y a «Landing zone lista». «Aplicar lecciones del piloto» la sigue, y luego «Oleada 2: cargas principales» (15). «Oleada 3: cargas restantes» empieza cinco días laborables después del inicio de la oleada 2, y «Pruebas de rendimiento y conmutación» sigue a la oleada 2.

  4. Ensayar, cortar y retirar

    «Ensayo final del corte» espera a la oleada 3 y a las pruebas. La «Ventana de corte» dura 2 días laborables, el «Hipercuidado» 10, y «Retirar servidores de origen» (8) lo sigue, terminando en el hito «Entorno de origen retirado».

Cómo funciona

  1. Empieza el mapa de dependencias antes de que termine el descubrimiento

    Añade «Mapa de dependencias» como tarea propia y vincúlala de inicio a inicio con el descubrimiento, por ejemplo 1SS+3. Los primeros hallazgos bastan para empezar, y los grupos que deben moverse juntos aparecen semanas antes.

  2. Haz de la landing zone un flujo con un hito

    Da al diseño de la landing zone, la red y la identidad sus propias tareas, únelas en un hito de duración 0 y haz que la primera oleada dependa de él además del plan aprobado.

  3. Dimensiona las oleadas por grupos de dependencia

    Pon en la misma oleada las cargas que dependen unas de otras. Da a cada oleada una tarea y usa el campo Grupo para mantener las oleadas, la landing zone y el corte en bandas separadas.

  4. Haz un piloto y planifica lo que cambiarás

    Haz pequeña la oleada 1 y añade tras ella una tarea para los cambios en runbooks y herramientas. Las oleadas posteriores dependen de esa tarea, de modo que el tiempo que lleva aparece en las fechas.

  5. Solapa las oleadas con un desfase

    Donde una oleada posterior pueda empezar mientras una anterior sigue en marcha, usa un vínculo de inicio a inicio con un desfase, como 12SS+5. Comprueba que están las personas y la capacidad del destino, porque el gráfico no lo comprueba.

  6. Pon la retirada detrás del hipercuidado

    Añade el hipercuidado como una tarea con una duración acorde con el tiempo que quieras mantener el origen como respaldo, y haz que la retirada lo siga. Compara la fecha de fin con la fecha que necesitas.

Errores que debes evitar

  • Empezar el piloto cuando el papeleo está listo

    Un plan firmado no es un destino listo. Si la oleada 1 depende solo de la aprobación, una construcción de red tardía sorprende a todos. Haz que la primera oleada espere tanto al plan como a la landing zone.

  • Oleadas divididas por equipo en lugar de por dependencia

    Mover el mismo día todo lo que posee un equipo suele separar una aplicación de su base de datos. Divide según lo que se comunica con qué, y comprueba los grupos con el mapa de dependencias.

  • Apagar el origen en el corte

    Si la retirada empieza en el corte, el respaldo termina antes de que hayan aparecido los problemas. Mantén el hipercuidado entre ambos y dale una duración real.

  • Tratar el plan como un registro de decisiones

    El gráfico muestra cuándo debe hacerse el trabajo. Las elecciones de estrategia, las revisiones de seguridad y los resultados de las pruebas pertenecen a tus propios registros y a tu proceso de cambios, con una referencia en las notas de la tarea.

Abrir el Gantt de migración a la nube

Abre la plantilla de migración a la nube, cambia la duración de las oleadas por la tuya y observa cómo se mueve la fecha de retirada.

Abrir el Gantt de migración a la nube

Guías relacionadas

Preguntas frecuentes

¿Cuántas oleadas debe tener una migración?

Depende del número de cargas y de lo estrechamente que dependan unas de otras. La plantilla usa tres a modo de ilustración. Añade o quita tareas de oleada para ajustarlas a tus grupos.

¿Puedo planificar en torno a la fecha de salida de un centro de datos?

Compara la fecha de fin del hito de retirada con la fecha que necesitas. Si es posterior, cambia una duración o una dependencia. Usa un Inicio fijo solo para fechas realmente fijas, como una congelación; el gráfico señala un inicio fijo que entra en conflicto con una dependencia.

¿Registra el gráfico costes o capacidad?

No. QueryChart programa tareas, dependencias y avance. No registra costes, esfuerzo ni carga de recursos, así que mantenlos en la herramienta que ya uses.

¿Puedo pegar mi lista de cargas en el gráfico?

Sí. Copia filas de Excel, Sheets o un CSV y pégalas en la hoja. Si la primera línea nombra columnas como Tarea (Task), Duración (Duration) y Depende de (Depends on), cada columna se reconoce por su nombre.

¿Dónde veo qué tareas fijan la fecha de fin?

Activa Ver y luego Ruta crítica para iluminar la cadena de tareas que fija la fecha de fin. Consulta /es/guides/ruta-critica-diagrama-de-gantt para saber cómo leerla.

La plantilla detrás de esta guía

Plantilla de Gantt de migración a la nube con oleadas y corte — Diagrama de Gantt editable de migración a la nube: descubrimiento, mapa de dependencias, landing zone en paralelo, oleadas de migración, ensayo del corte, hipercuidado y retirada, con dependencias e hitos.

Diagrama de Gantt de migración a la nube: Descubrir y planificar → Construir la landing zone → Migrar por oleadas → Corte y retirada
Cómo planificar oleadas y corte de una migración a la nube en un Gantt