Informazioni sulla gestione di una migrazione di grandi dimensioni

Per gestire e governare in modo efficace un progetto di migrazione di grandi dimensioni, il project manager deve avere una conoscenza approfondita del portafoglio, delle fasi di una migrazione di grandi dimensioni e delle responsabilità di ogni flusso di lavoro.

Flussi di lavoro in una migrazione di grandi dimensioni

Nella fase di migrazione, in qualsiasi momento, sono operativi contemporaneamente almeno quattro flussi di lavoro: la base, la governance del progetto, il portfolio e i flussi di lavoro di migrazione. Questi sono i flussi di lavoro principali di qualsiasi progetto di migrazione di grandi dimensioni e il tuo progetto potrebbe avere flussi di lavoro aggiuntivi di supporto. Per ulteriori informazioni, consulta Workstreams in una migrazione di grandi dimensioni nel playbook di Foundation per migrazioni diAWS grandi dimensioni.

Alimentazione della pipeline di migrazione

Nella fabbrica di migrazione, la pianificazione delle ondate e la migrazione avvengono contemporaneamente e funzionano in modo continuo. Il team del portfolio alimenta la pipeline di migrazione pianificando le ondate e il team di migrazione completa la pipeline eseguendo la migrazione e riducendo i carichi di lavoro. Il team del portfolio prepara cinque ondate alla fine della fase di inizializzazione e la fase di implementazione inizia quando il team di migrazione inizia a migrare una o più delle onde preparate.

Per ogni ondata, il flusso di lavoro del portfolio dura da 1 a 2 settimane e il flusso di lavoro di migrazione in genere dura 3-4 settimane. Il flusso di lavoro del portfolio è in anticipo di cinque ondate rispetto al flusso di lavoro di migrazione, quindi c'è sempre un buffer a cinque onde tra il portafoglio e i flussi di lavoro di migrazione. Durante tutta la fase di implementazione, sia il team del portfolio che il team di migrazione continuano a elaborare le ondate e il buffer impedisce al flusso di lavoro di migrazione di esaurire i server da migrare. Per un esempio di pianificazione delle ondate, vedere Fase 2: Implementazione di una migrazione di grandi dimensioni nella Guida per le migrazioni diAWS grandi dimensioni.

Il team del portfolio dà priorità alle applicazioni e poi le assegna alle onde in gruppi di movimenti logici. Nella pianificazione delle ondate, il team del portafoglio considera la complessità della migrazione, le somiglianze delle applicazioni e le dipendenze tra applicazioni e infrastrutture. Questo aiuta a garantire che le applicazioni e le relative dipendenze vengano migrate nella loro interezza. Per ulteriori informazioni sulla pianificazione delle ondate, consulta il manuale Portfolio per migrazioni diAWS grandi dimensioni. Per la governance del progetto, gestisci e tieni traccia delle informazioni sulle onde e sugli sprint, inclusi le applicazioni, i server e i proprietari delle applicazioni. Potresti utilizzare una dashboard su un sito Confluence, un elenco in Microsoft Excel o una combinazione di strumenti.

Periodo di valutazione

Una volta completato il cutover, le applicazioni e i server migrati entrano nel periodo di hypercare. Nel periodo dell'hypercare, il team di migrazione gestisce e monitora le applicazioni migrate nel cloud per risolvere eventuali problemi. In genere, questo periodo dura da 1 a 4 giorni. Al termine del periodo di hypercare, il team di migrazione trasferisce la responsabilità delle applicazioni al team delle operazioni cloud (Cloud Ops). In questo momento, l'onda è considerata completa.

Stabilire un approccio agile

Stabilendo un approccio agile, il team di progetto può rimanere flessibile e adattarsi rapidamente ai cambiamenti durante la migrazione. Consigliamo di adottare un framework Scrum per una migrazione di grandi dimensioni. Nel playbook sulla migrazione per le migrazioni diAWS grandi dimensioni, si assegnano le ondate agli sprint, ovvero un periodo di tempo fisso in cui il team di migrazione lavora su tutte le onde all'interno di quello sprint. Se ogni sprint dura 2 settimane, ogni ondata copre almeno due sprint. Uno sprint consiste in eventi standard, come la pianificazione dello sprint e lo svolgimento di riunioni giornaliere di stand-up, una revisione e una retrospettiva.

Per gestire le attività si utilizza un backlog di sprint, composto dalle attività correnti e in sospeso dello sprint. In questo playbook, si seleziona uno strumento di gestione del progetto per tenere traccia dei progressi. Potresti selezionare un progetto o un'applicazione per il monitoraggio dei problemi, come Jira o Confluence, e potresti anche selezionare un approccio visivo per rappresentare le attività, come una bacheca Kanban o un diagramma di Gantt. Monitorando il backlog degli sprint in uno o più di questi strumenti, garantisci la trasparenza del progetto, assegni i responsabili a ciascuna attività e stabilisci scadenze chiare.