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à.
# Attività 1: Esecuzione dell'individuazione iniziale e convalida della strategia di migrazione
La prima fase della valutazione del portafoglio in un grande progetto di migrazione consiste nel comprendere le informazioni di cui disponiamo oggi, i fattori aziendali e tecnici e le eventuali decisioni sulla strategia di migrazione già prese. Il risultato della valutazione del portafoglio consiste nell'inserire continuamente i metadati di migrazione, il piano d'ondata e le strategie di migrazione nel flusso di lavoro di migrazione. Sulla base delle informazioni raccolte, si analizzano le lacune e si decidono i passaggi successivi. Puoi saltare alcune sezioni di questo manuale se hai già completato l'analisi e le attività. Questa attività prevede i seguenti passaggi:
+ [Fase 1: Convalida dei dati di rilevamento](#discovery-1)
+ [Fase 2: Identifica i fattori aziendali e tecnici](#discovery-2)
+ [Fase 3: Convalida delle strategie di migrazione](#discovery-3)
+ [Fase 4: Convalida dei modelli di migrazione](#discovery-4)
## Fase 1: Convalida dei dati di rilevamento
Nella fase di mobilitazione, potresti aver completato la valutazione iniziale del portafoglio e, in tal caso, puoi riutilizzare i dati di scoperta nella fase di migrazione. In caso contrario, non preoccuparti. Questo playbook ti illustrerà ciò che è necessario per supportare una migrazione su larga scala.
Le migrazioni di grandi dimensioni di solito contengono molti dati. Ad esempio, hai:
+ Metadati relativi ai server, alle applicazioni e ai database di origine
+ Informazioni sul portafoglio IT contenute nel database di gestione della configurazione (CMDB)
+ Dati provenienti da strumenti di rilevamento che consentono di comprendere meglio lo stato attuale e le dipendenze
+ Metadati per le risorse target AWS
### Informazioni sui tipi di metadati
Di seguito sono riportati i tre tipi principali di metadati necessari per supportare una migrazione su larga scala:
+ **Metadati del portfolio** di origine: i metadati del portfolio di origine sono i metadati relativi ai server, alle applicazioni e ai database di origine. È possibile ottenere i metadati da un CMDB esistente, da strumenti di rilevamento o persino dal proprietario dell'applicazione. È possibile trovare un elenco completo di questo tipo di metadati qui e di seguito sono riportati alcuni esempi:
+ Server name (Nome del server)
+ Indirizzo IP del server
+ Sistema operativo del server (OS)
+ Storage del server, CPU, memoria e input/output operazioni al secondo (IOPS)
+ Application name (Nome applicazione)
+ Proprietario dell'applicazione
+ Application-to-application dipendenze
+ unità aziendale
+ Application-to-server mappatura
+ Application-to-database mappatura
+ Tipo e dimensione del database
+ Tipo e dimensione di archiviazione
+ Metadati sulle dipendenze
+ Dati sulle prestazioni e sull'utilizzo
+ **Metadati dell'ambiente di destinazione**: si tratta di un tipo di metadati che consente di migrare i server nell'ambiente di destinazione. È necessario prendere decisioni sull'ambiente di destinazione. È possibile ottenere alcuni di questi metadati dagli strumenti di scoperta. Di seguito sono riportati alcuni esempi di questo tipo di metadati:
+ Subnet di destinazione
+ Gruppo di sicurezza target
+ Tipo di istanza di destinazione
+ Ruolo Target AWS Identity and Access Management (IAM)
+ Indirizzo IP di destinazione
+ ID AWS dell'account Target
+ AWS Regione di destinazione
+ AWS Servizio Target
+ Progettazione dell'architettura dell'applicazione target
+ **Metadati di pianificazione** delle ondate: i metadati di pianificazione delle ondate sono il tipo di metadati che consente di gestire la migrazione. Di seguito sono riportati alcuni esempi di questo tipo di metadati:
+ Wave ID
+ Ora di inizio di Wave
+ Tempo di interruzione delle onde
+ Titolare di Wave
+ Mappatura da onda a application/server/database/move gruppo
### Convalida i tuoi dati di scoperta
È importante comprendere i dati di scoperta correnti prima di prendere qualsiasi decisione. Probabilmente non disponi di tutte le informazioni in questa fase della migrazione. Questo playbook ti aiuta a definire i requisiti dei metadati e a raccogliere i metadati in modo efficiente. Ponetevi le seguenti domande per identificare quali metadati sono attualmente disponibili e dove potrebbero essere collocati:
+ Avete utilizzato strumenti per condurre una valutazione della migrazione, come Migration Evaluator?
+ Hai implementato strumenti di discovery nel tuo ambiente, come Flexera One Cloud Migration and Modernization?
+ Disponi di un CMDB con il maggior numero di up-to-date informazioni per il tuo portafoglio IT?
+ Avete completato la valutazione iniziale del portafoglio nella fase di mobilitazione?
+ Avete completato la pianificazione iniziale dell'ondata?
+ Hai completato la progettazione iniziale dell'ambiente di destinazione?
+ Qual è l'origine di ogni tipo di metadati?
+ Hai accesso a tutti i metadati?
+ Come si accede a tutti i metadati?
+ Hai documentato il processo di accesso ai metadati?
## Fase 2: Identifica i fattori aziendali e tecnici
I fattori aziendali e tecnologici sono fondamentali quando si considerano le strategie e i modelli di migrazione di alto livello per ciascuna applicazione. È necessario comprendere i fattori che determinano esclusivamente la migrazione. Utilizzate questi driver aziendali e tecnici per convalidare le strategie di migrazione e definire le regole di mappatura delle applicazioni.
### I fattori di business più comuni
I *driver aziendali* sono fattori legati agli obiettivi o ai limiti aziendali che è necessario considerare quando si pianifica una migrazione di grandi dimensioni, come la scadenza dei contratti, la rapida crescita o il budget. I fattori di business più comuni sono i seguenti:
+ **Uscire da un data center**: è necessario migrare il più rapidamente possibile verso il cloud. Ad esempio, un contratto di data center sta per scadere.
+ **Riduzione dei costi e dei rischi operativi**: si desidera ridurre i costi o i rischi associati alla gestione di un ambiente locale.
+ **Flessibilità**: è necessario passare al cloud come direzione strategica per prepararsi ai cambiamenti futuri dell'azienda.
+ **Far crescere il business**: è necessario essere in grado di accelerare rapidamente lo sviluppo e l'innovazione o di far fronte a una crescita rapida.
+ **Utilizzo intelligente dei dati**: desideri sfruttare l'intelligenza artificiale, l'apprendimento automatico e l'Internet of Things (IoT) basati su cloud in grado di prevedere la crescita della tua azienda e fornire informazioni sul comportamento dei clienti.
+ **Miglioramento della sicurezza e della conformità**: devi sfruttare i programmi di conformità già integrati nell'infrastruttura AWS cloud oppure vuoi sfruttare gli strumenti di sicurezza basati su software in grado di avvisarti di una possibile minaccia ai tuoi dati.
+ **Disponibilità delle risorse**: disporre di risorse limitate o di esperienza interna limitata potrebbe portare a selezionare strategie che spostino l'applicazione senza modifiche.
### Driver tecnici comuni
I *driver tecnici* sono fattori legati agli obiettivi o ai limiti tecnici che è necessario considerare quando si pianifica una migrazione su larga scala, come l'architettura corrente. Di seguito sono riportati i driver tecnici più comuni:
+ **Hardware o software end-of-support**: l'hardware o il software è vicino alla fine del suo ciclo di vita ed è necessario aggiornarlo perché il fornitore non lo supporta più.
+ **Integrazione tecnologica**: ottieni l'accesso a un'infrastruttura globale che ti consente di scalare rapidamente e strategicamente la tua applicazione. Puoi diventare rapidamente globale con servizi e infrastrutture globali pronti a essere sfruttati.
+ **Limiti di storage ed elaborazione**: il tuo data center non dispone di capacità per ulteriori server o storage e devi trovare un altro posto in cui espandersi.
+ **Requisiti di scalabilità e resilienza**: le tue applicazioni hanno subito tempi di inattività in passato e desideri utilizzare il cloud per migliorare il Recovery Point Objective (RPO) e il Recovery Time Objective (RTO).
+ **Modernizzazione dell'architettura delle applicazioni**: desideri sfruttare il cloud e modificare le tue applicazioni in modo che diventino native per il cloud.
+ **Miglioramento delle prestazioni**: le prestazioni delle applicazioni sono scarse durante le stagioni di punta, pertanto è necessario scalare automaticamente verso l'alto e verso il basso per soddisfare la domanda.
### Aggiorna il runbook
1. Nei [modelli di playbook del portfolio](samples/portfolio-playbook-templates.zip), apri il *modello Runbook per la prioritizzazione delle applicazioni (formato* Microsoft Word).
1. Nella sezione *Driver aziendali e tecnici, registra i driver* che hai identificato per il tuo progetto di migrazione di grandi dimensioni.
1. Salva il runbook di prioritizzazione delle applicazioni.
## Fase 3: Convalida delle strategie di migrazione
La selezione delle strategie di migrazione è fondamentale per una migrazione di grandi dimensioni. È necessario verificare che le strategie di migrazione selezionate soddisfino le aspettative, i limiti e i requisiti dell'organizzazione. Per ulteriori informazioni sulle strategie di migrazione disponibili, consulta la [Guida per migrazioni di AWS grandi dimensioni](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/).
Potresti aver selezionato le strategie di migrazione nella fase di mobilitazione o durante la valutazione iniziale del portafoglio. In questa fase, utilizzate i driver aziendali e tecnici per selezionare e convalidare le strategie di migrazione per il vostro portafoglio.
Le vostre strategie di migrazione potrebbero cambiare man mano che continuate a valutare il portafoglio e iniziate la migrazione. In questa fase, l'obiettivo è comprendere la distribuzione generale del portafoglio in ciascuna strategia di migrazione. La selezione delle strategie di migrazione è fondamentale per la fase successiva, vale a dire la convalida dei modelli di migrazione dettagliati.
### Seleziona e convalida le strategie di migrazione
Valuta il portafoglio e seleziona le strategie di migrazione come segue:
1. Esamina tutti i fattori tecnici e aziendali identificati nel passaggio precedente e dai la priorità ai driver in base alle tue esigenze aziendali.
1. Associa ogni fattore tecnico e aziendale a una strategia di migrazione. La tabella seguente è un esempio.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/large-migration-portfolio-playbook/discovery.html)
1. Ponderando ogni fattore tecnico e aziendale e valutando il vostro portafoglio a un livello elevato, stimate come le applicazioni dovrebbero essere distribuite tra ciascuna strategia di migrazione. È comune riscontrare conflitti tra i driver. Le parti interessate al progetto devono lavorare insieme e prendere le decisioni finali per risolvere i conflitti. Di seguito è riportato un esempio di come è possibile distribuire il portafoglio per ciascuna strategia di migrazione:
+ Rehosting: 60%
+ Ripiattaforma: 15%
+ Pensionamento — 10%
+ Conservare — 5%
+ Riacquisto — 5%
+ Rifattorizzazione — 5%
Non procedete con la migrazione prima di aver selezionato strategie di migrazione di alto livello per il vostro portafoglio.
### Aggiorna il runbook
1. Apri il runbook di prioritizzazione delle applicazioni.
1. Nella sezione *Strategie di migrazione*, registrate come il carico di lavoro dell'applicazione viene distribuito tra le sette strategie di migrazione. Esempio:
+ Rehosting: 60%
+ Ripiattaforma: 15%
+ Pensionamento — 10%
+ Conservare — 5%
+ Riacquisto — 5%
+ Rifattorizzazione — 5%
1. Salva il tuo runbook di prioritizzazione delle applicazioni.
## Fase 4: Convalida dei modelli di migrazione
### Informazioni sui modelli di migrazione
Un *modello di migrazione* è un'attività di migrazione ripetibile che descrive in dettaglio la strategia di migrazione, la destinazione della migrazione e l'applicazione o il servizio di migrazione utilizzati. Un esempio è *Rehost to Amazon Elastic Compute Cloud (Amazon EC2) utilizzando*. AWS Application Migration Service I seguenti AWS servizi e soluzioni sono spesso citati nei modelli di migrazione comuni:
+ AWS App2Container
+ AWS Application Migration Service (AWS MGN)
+ AWS CloudFormation
+ AWS Database Migration Service (AWS DMS)
+ AWS DataSync
+ Amazon Elastic Compute Cloud (Amazon EC2)
+ Amazon Elastic Container Service (Amazon ECS)
+ Amazon Elastic File System (Amazon EFS)
+ AWS Soluzione Cloud Migration Factory
+ Amazon Relational Database Service (Amazon RDS)
+ AWS Schema Conversion Tool (AWS SCT)
+ AWS Transfer Family
Analogamente alla selezione delle strategie di migrazione, potresti aver già identificato i tuoi modelli di migrazione in una fase precedente. Tuttavia, è necessario convalidarli e assicurarsi che i modelli siano stati definiti e documentati. La tabella seguente elenca le strategie e i modelli di migrazione comuni.
****
| ID | Strategia | Pattern |
| --- | --- | --- |
| 1 | Riospitare | Rehosting su Amazon EC2 utilizzando Application Migration Service o Cloud Migration Factory |
| 2 | Conversione piattaforma | Ripiattaforma su Amazon RDS utilizzando e AWS DMS AWS SCT |
| 3 | Conversione piattaforma | Ripiattaforma su Amazon EC2 utilizzando CloudFormation CloudFormation i modelli creano una nuova infrastruttura in. Cloud AWS |
| 4 | Conversione piattaforma | Ripiattaforma su Amazon EFS utilizzando AWS DataSync o AWS Transfer Family |
| 5 | Conversione piattaforma | Ripiattaforma su Amazon ECS utilizzando App2Container AWS |
| 6 | Conversione piattaforma | Ripiattaforma i server mainframe o midrange su Amazon EC2 utilizzando un emulatore |
| 7 | Conversione piattaforma | Ripiattaforma da Windows a Linux su Amazon EC2 |
| 8 | Ritiro | Ritira l'applicazione |
| 9 | Mantenimento | Conserva in locale |
| 10 | Riacquisto | Riacquisto e aggiornamento a SaaS |
| 11 | Rifattorizza o riprogetta | Riprogetta l'applicazione |
### Aggiorna il runbook
A questo punto, definisci i modelli a livello di portafoglio. Più avanti in questo playbook, mappate ogni applicazione al modello di migrazione corrispondente.
1. Apri il runbook per la prioritizzazione delle applicazioni.
1. Nella sezione *Modelli di migrazione, registra i modelli* di migrazione che hai identificato e convalidato. Assegna a ogni pattern un ID univoco e annota la strategia di migrazione per il pattern.
1. Salva il runbook di prioritizzazione delle applicazioni.
Tieni presente che i modelli di migrazione potrebbero cambiare man mano che procedi. È possibile modificare le strategie e i modelli di migrazione in un secondo momento, man mano che si trovano nuove informazioni, si modifica l'ambito del carico di lavoro o addirittura si decide di utilizzare nuovi AWS servizi.
## Criteri di uscita dall'attività
Se non avete ancora identificato le strategie e i modelli di migrazione da una prospettiva di portafoglio di alto livello, vi consigliamo vivamente di collaborare con i team tecnici per definirli prima di passare all'attività successiva. La valutazione del portafoglio e la pianificazione delle ondate dipendono dalla comprensione delle strategie e dei modelli di migrazione. Non è necessario disporre di un elenco completo dei modelli di migrazione prima di procedere. Puoi aggiungere nuovi modelli e modificare le tue strategie man mano che procedi.
Passa all'attività successiva dopo aver completato quanto segue:
+ Hai accesso ai dati di scoperta più recenti e li comprendi.
+ Hai identificato i fattori aziendali e tecnici per la tua migrazione.
+ Avete selezionato e convalidato le strategie di migrazione, in base ai vostri fattori aziendali e tecnici.
+ Hai selezionato e convalidato i modelli di migrazione.
+ Nel runbook sulla prioritizzazione delle applicazioni è stato documentato quanto segue:
+ Driver aziendali e tecnici
+ Strategie di migrazione
+ Modelli di migrazione