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.
¿Qué es plantilla de gantt de migración a la nube con oleadas y corte?
Una migración a la nube son varios proyectos que comparten una fecha límite. El descubrimiento y la planificación deciden qué se mueve y en qué orden. La landing zone, la red, la identidad y los registros donde aterrizarán las cargas, puede construirse al mismo tiempo. Las oleadas mueven después las cargas por lotes, y el entorno de origen no puede apagarse hasta que la última oleada haya funcionado un tiempo en producción. Un plan que las enumera como una sola secuencia exagera la duración. Un plan que las trata como independientes oculta los puntos donde una espera a otra.
Esta plantilla tiene cuatro fases: Descubrir y planificar, Construir la landing zone, Migrar por oleadas, y Corte y retirada. «Descubrimiento de aplicaciones y servidores» es la única tarea inicial. «Mapa de dependencias» empieza tres días laborables después de iniciarse el descubrimiento, porque los primeros hallazgos bastan para empezar a rastrear conexiones, y «Estrategia de migración por carga» la sigue. A partir de ahí el plan se divide. «Plan de oleadas y ventanas de corte» lleva al hito «Plan de migración aprobado», mientras «Diseño de la landing zone» empieza en cuanto se conoce la estrategia y corre en paralelo con el plan de oleadas.
Dentro de la landing zone, «Construir red y conectividad» (10 días laborables) e «Identidad, seguridad y registros» (8) siguen ambas al diseño, y la segunda empieza dos días laborables después del inicio del diseño. «Landing zone lista» espera a ambas. «Migración piloto de la oleada 1» no puede empezar hasta que estén hechos «Plan de migración aprobado» y «Landing zone lista», que es donde los planes de este tipo se retrasan con más frecuencia: el papeleo está terminado y el destino no, o al revés. «Aplicar lecciones del piloto» se sitúa entre el piloto y «Oleada 2: cargas principales», y «Oleada 3: cargas restantes» empieza cinco días laborables después del inicio de la oleada 2, de modo que la última oleada se solapa con la principal.
Tras las oleadas, «Pruebas de rendimiento y conmutación» y la oleada 3 deben estar hechas antes del «Ensayo final del corte»; luego vienen la «Ventana de corte», el «Hipercuidado» (10 días laborables) y «Retirar servidores de origen». «Entorno de origen retirado» es el hito de cierre. Todas las duraciones son ilustrativas. Un parque real tiene cargas que no pueden moverse juntas, licencias con sus propias fechas de fin y congelaciones de cambios que este gráfico no conoce, así que sustituye las duraciones y la división en oleadas por las tuyas. Un cronograma planifica el trabajo. No hace que una migración sea segura, protegida o rentable, y no sustituye los runbooks, los resultados de pruebas y las aprobaciones que exige tu proceso de cambios. Para el lado de proceso, consulta el proceso de despliegue en /es/templates/proceso-de-despliegue-de-software, el proceso de recuperación en /es/templates/plan-de-recuperacion-ante-desastres y el proceso de cambios en /es/templates/flujo-de-gestion-de-cambios-de-ti.
Qué cubre este diagrama de flujo
En esta plantilla
- Cuatro fases, Descubrir y planificar, Construir la landing zone, Migrar por oleadas, y Corte y retirada, con 19 tareas y tres hitos: «Plan de migración aprobado», «Landing zone lista» y «Entorno de origen retirado».
- Un solape de inicio a inicio en el descubrimiento: «Mapa de dependencias» empieza tres días laborables después del inicio de «Descubrimiento de aplicaciones y servidores», antes de que termine el descubrimiento.
- Una landing zone construida junto a la planificación: «Diseño de la landing zone» sigue a «Estrategia de migración por carga» y corre en paralelo con «Plan de oleadas y ventanas de corte», con «Identidad, seguridad y registros» empezando dos días laborables después del diseño.
- Una unión que condiciona la primera oleada: «Migración piloto de la oleada 1» espera a «Plan de migración aprobado» y a «Landing zone lista», y «Aplicar lecciones del piloto» va antes de «Oleada 2: cargas principales».
- Oleadas solapadas y una cola segura: «Oleada 3: cargas restantes» empieza cinco días laborables después del inicio de la oleada 2, y «Retirar servidores de origen» espera al «Hipercuidado» de 10 días.
Cuándo usar esta plantilla
- Mueves servidores o aplicaciones a un proveedor de nube y necesitas mostrar cuándo caen la planificación, la landing zone, cada oleada y el corte.
- Necesitas explicar a un comité de dirección o a los responsables de aplicaciones por qué la oleada 1 no puede empezar hasta que la landing zone esté lista, diga lo que diga el plan.
- Te preguntan cuánto tiempo debe seguir encendido el entorno de origen, por ejemplo por la fecha de fin de un contrato de centro de datos o de alojamiento.
- Quieres probar qué ocurre con la fecha de retirada si la red o una oleada tarda más de lo previsto.
El plan, tarea por tarea
Todas las tareas del diagrama con su duración en días laborables y aquello de lo que dependen. Una dependencia es un número de paso; SS es inicio a inicio, FF es fin a fin y +n es un retraso en días laborables.
| # | Tarea | Grupo | Días laborables | Depende de |
|---|---|---|---|---|
| 1 | Descubrimiento de aplicaciones y servidores | Descubrir y planificar | 8 | |
| 2 | Mapa de dependencias | Descubrir y planificar | 6 | 1SS+3 |
| 3 | Estrategia de migración por carga | Descubrir y planificar | 4 | 2 |
| 4 | Plan de oleadas y ventanas de corte | Descubrir y planificar | 4 | 3 |
| 5 | Plan de migración aprobado | Descubrir y planificar | Hito | 4 |
| 6 | Diseño de la landing zone | Construir la landing zone | 6 | 3 |
| 7 | Construir red y conectividad | Construir la landing zone | 10 | 6 |
| 8 | Identidad, seguridad y registros | Construir la landing zone | 8 | 6SS+2 |
| 9 | Landing zone lista | Construir la landing zone | Hito | 7, 8 |
| 10 | Migración piloto de la oleada 1 | Migrar por oleadas | 8 | 5, 9 |
| 11 | Aplicar lecciones del piloto | Migrar por oleadas | 3 | 10 |
| 12 | Oleada 2: cargas principales | Migrar por oleadas | 15 | 11 |
| 13 | Oleada 3: cargas restantes | Migrar por oleadas | 12 | 12SS+5 |
| 14 | Pruebas de rendimiento y conmutación | Migrar por oleadas | 6 | 12 |
| 15 | Ensayo final del corte | Corte y retirada | 2 | 13, 14 |
| 16 | Ventana de corte | Corte y retirada | 2 | 15 |
| 17 | Hipercuidado | Corte y retirada | 10 | 16 |
| 18 | Retirar servidores de origen | Corte y retirada | 8 | 17 |
| 19 | Entorno de origen retirado | Corte y retirada | Hito | 18 |
Cómo funciona
Sustituye las duraciones de descubrimiento y planificación
Fija las duraciones de «Descubrimiento de aplicaciones y servidores», «Mapa de dependencias» y «Estrategia de migración por carga» según el tamaño de tu parque. Conserva el vínculo de inicio a inicio si el rastreo puede empezar antes de que termine el descubrimiento.
Construye la landing zone junto al plan
Mantén «Diseño de la landing zone» y «Plan de oleadas y ventanas de corte» como tareas paralelas. Añade tareas para cualquier otra cosa que necesite el destino, como servicios compartidos, y vincúlalas a «Landing zone lista».
Condiciona la oleada 1 en ambos lados
«Migración piloto de la oleada 1» depende de «Plan de migración aprobado» y de «Landing zone lista». Alarga la construcción de la red y comprueba cuál de las dos fija el inicio del piloto.
Divide las oleadas según tus cargas
Cambia el nombre o duplica las tareas de oleada para tus propios grupos de cargas. Usa un desfase en el vínculo de inicio a inicio donde una oleada posterior pueda empezar mientras una anterior sigue en marcha.
Añade corte, hipercuidado y retirada
Fija «Hipercuidado» según el tiempo que quieras mantener el origen como respaldo. Compara la fecha de «Entorno de origen retirado» con cualquier fecha de fin de contrato o licencia que debas cumplir.
Añade responsables, comparte y exporta
Anota el equipo responsable en Personas y referencias como las de los runbooks en las notas de la tarea, comparte el gráfico con los responsables de aplicaciones y exporta un PDF para el registro de cambios.
Preguntas frecuentes
¿Elige este gráfico una estrategia de migración por mí?
No. Programa el trabajo. La tarea «Estrategia de migración por carga» es donde decides, para cada carga, si se mueve tal cual, se modifica o se sustituye. El gráfico solo muestra qué espera a esa decisión.
¿Puedo planificar en torno a la fecha de fin de un contrato de centro de datos?
Compara la fecha de fin de «Entorno de origen retirado» con la fecha que necesitas. Si es posterior, cambia una duración o una dependencia y observa cómo se mueve la fecha. Un Inicio fijo es para fechas realmente fijas, como una congelación de cambios, y el gráfico señala uno que entre en conflicto con una dependencia.
¿Son los días laborables días de calendario reales?
Son de lunes a viernes. El gráfico no tiene calendario de festivos, así que añade una tarea o alarga una duración donde caiga un festivo o un periodo de congelación.
¿En qué se diferencia del gráfico de migración de datos?
Este mueve cargas y entornos. El gráfico de migración de datos (la plantilla de Gantt de migración de datos) cubre el perfilado, el mapeo, las cargas de prueba y la conciliación de los propios datos. Un programa grande puede usar ambos.
¿Dónde está el diagrama de flujo del mismo trabajo?
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 dibujan las decisiones y los traspasos. Para un plan de programa más amplio, consulta /es/templates/diagrama-de-gantt-plan-de-implantacion.
