Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Informazioni sulla gestione di una migrazione di grandi dimensioni
Per gestire e governare efficacemente un progetto di migrazione di grandi dimensioni, il project manager deve avere una conoscenza di alto livello del portafoglio, delle fasi di una migrazione su larga scala e delle responsabilità di ciascun flusso di lavoro.
**Topics**
+ [Flussi di lavoro in una migrazione di grandi dimensioni](#large-migration-workstreams)
+ [Alimentare la pipeline di migrazione](#migration-pipeline)
+ [Periodo Hypercare](#hypercare-period)
+ [Stabilire un approccio agile](#establish-agile-approach)
## Flussi di lavoro in una migrazione di grandi dimensioni
Nella fase di migrazione, in qualsiasi momento, operano 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 e di supporto. *Per ulteriori informazioni, consulta [Workstreams in a large migration nel playbook Foundation per migrazioni di grandi dimensioni](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-foundation-playbook/workstreams.html). AWS *
## Alimentare la pipeline di migrazione
Nella fabbrica di migrazione, la pianificazione delle onde e la migrazione avvengono contemporaneamente e funzionano continuamente. Il team di portfolio alimenta la pipeline di migrazione pianificando le ondate, mentre il team di migrazione completa la pipeline eseguendo la migrazione e riducendo i carichi di lavoro. Il team del portfolio prepara cinque fasi al termine della fase di inizializzazione e la fase di implementazione inizia quando il team di migrazione inizia a migrare una o più delle ondate preparate.
Per ogni ondata, il flusso di lavoro del portafoglio dura 1—2 settimane e il flusso di lavoro di migrazione dura in genere 3-4 settimane. Il flusso di lavoro del portfolio è in anticipo di cinque fasi rispetto al flusso di lavoro di migrazione, quindi c'è sempre un buffer a cinque fasi tra il portfolio e i flussi di lavoro di migrazione. Durante tutta la fase di implementazione, sia il team di portfolio che il team di migrazione continuano a elaborare le ondate e il buffer impedisce che il flusso di lavoro di migrazione esaurisca i server da migrare. Per un esempio di pianificazione a ondate, consulta la [Fase 2: Implementazione di una migrazione su larga scala nella *Guida per AWS * migrazioni](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/stage2.html) di grandi dimensioni.
Il team del portfolio dà priorità alle applicazioni e poi le assegna a ondate in gruppi di movimenti logici. Nella pianificazione delle ondate, il team del portfolio considera la complessità della migrazione, le somiglianze tra le 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 [playbook Portfolio](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-portfolio-playbook/) per migrazioni di grandi dimensioni. AWS Per quanto riguarda la governance dei progetti, è possibile gestire e tenere traccia delle informazioni relative alle ondate e agli sprint, incluse le applicazioni, i server e i proprietari delle applicazioni. Puoi usare una dashboard su un sito Confluence, un elenco in Microsoft Excel o una combinazione di strumenti.
## Periodo Hypercare
*Dopo aver completato il cutover, le applicazioni e i server migrati entrano nel periodo Hypercare.* Nel periodo di hypercare, il team addetto alla 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'ondata è 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 [manuale di migrazione per migrazioni di AWS grandi dimensioni, assegni le](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-migration-playbook/) ondate agli *sprint*, ovvero un periodo di tempo fisso in cui il team addetto alla migrazione lavora su tutte le ondate all'interno di quello sprint. Se ogni sprint dura 2 settimane, ogni ondata si estende su almeno due sprint. Uno sprint consiste in eventi standard, come la pianificazione dello sprint e lo svolgimento di riunioni quotidiane di stand-up, una revisione e una retrospettiva.
Per gestire le attività, si utilizza uno *sprint backlog*, che consiste nelle attività correnti e in sospeso nello sprint. In questo playbook, selezioni uno strumento di gestione del progetto per tenere traccia dei progressi. Puoi selezionare un progetto o un'applicazione per il monitoraggio dei problemi, come Jira o Confluence, e puoi anche selezionare un approccio visivo per rappresentare le attività, come una lavagna Kanban o un diagramma di Gantt. Monitorando il backlog degli sprint con uno o più di questi strumenti, garantisci la trasparenza del progetto, assegni i proprietari a ciascuna attività e stabilisci scadenze chiare.