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à.
# Analisi del portafoglio e pianificazione della migrazione
Questa fase di valutazione si concentra sul completamento della scoperta e dell'analisi a livello di portafoglio iniziata nella sezione Scoperta e pianificazione iniziale del [portafoglio](portfolio-discovery-initial-planning.md). L'obiettivo è iterare e stabilire una linea di base per il portafoglio iniziale di applicazioni e infrastrutture. Questa linea di base include l'identificazione di tutte le dipendenze, l'iterazione dei modelli di razionalizzazione per la migrazione, la creazione di un business case dettagliato e la definizione di un piano di migrazione. Di conseguenza, la fedeltà dei dati richiesta è maggiore. Questa fase richiederà un investimento di tempo. Per accelerare i risultati della valutazione, consigliamo di utilizzare il maggior numero possibile di fonti di dati programmatiche, come gli strumenti di scoperta.
I risultati principali di questa fase includono quanto segue:
+ Un inventario di applicazioni e infrastrutture ad alta fedeltà
+ Una strategia di migrazione di alto livello per ogni applicazione
+ Un piano di migrazione ad alta affidabilità
+ Un caso aziendale dettagliato
# Comprensione dei requisiti completi relativi ai dati di valutazione
La tabella seguente descrive le informazioni necessarie per ottenere una visione completa del portafoglio delle applicazioni oggetto della migrazione e dell'infrastruttura associata.
Le tabelle utilizzano le seguenti abbreviazioni:
+ R, per obbligatorio
+ O, per opzione
+ N/A, in quanto non applicabile
**Applicazioni**
| **Nome attributo** | **Descrizione** | **Inventario e definizione delle priorità** | **Caso aziendale dettagliato** | **Livello di fedeltà consigliato (minimo)** |
| --- | --- | --- | --- | --- |
| Identificatore univoco | Ad esempio, ID dell'applicazione. In genere disponibile su inventari e sistemi di controllo esistenti CMDBs o altri sistemi di controllo interni. Prendi in considerazione la possibilità di creare IDs elementi unici ogni volta che questi elementi non sono definiti nella tua organizzazione. | R | R | Elevata |
| Application name (Nome applicazione) | Nome con cui l'applicazione è nota all'organizzazione. Includi il nome del fornitore commerciale off-the-shelf (COTS) e del prodotto, se applicabile. | R | R | Elevata |
| È COTS? | Sì o no. Che si tratti di un'applicazione commerciale o di uno sviluppo interno | R | R | Elevata |
| Prodotto e versione COTS | Nome e versione del prodotto software commerciale | R | R | Elevata |
| Description | Funzione e contesto principali dell'applicazione | R | R | Elevata |
| Criticità | Ad esempio, un'applicazione strategica o che genera entrate o che supporta una funzione critica | R | R | Elevata |
| Tipo | Ad esempio, database, gestione delle relazioni con i clienti (CRM), applicazioni Web, contenuti multimediali, servizi IT condivisi | R | R | Elevata |
| Ambiente | Ad esempio, produzione, pre-produzione, sviluppo, test, sandbox | R | R | Elevata |
| Conformità e normative | Framework applicabili al carico di lavoro (ad esempio, HIPAA, SOX, PCI-DSS, ISO, SOC, FedRAMP) e ai requisiti normativi | R | R | Elevata |
| Dipendenze | Dipendenze a monte e a valle da applicazioni o servizi interni ed esterni. Dipendenze non tecniche come elementi operativi (ad esempio, cicli di manutenzione). | R | O | Elevata |
| Mappatura dell'infrastruttura | Mappatura su risorse and/or virtuali fisiche che compongono l'applicazione | R | R | Elevata |
| Licenza | Tipo di licenza software commodity (ad esempio, Microsoft SQL Server Enterprise) | R | R | Medio-alta |
| Costo | Costi per la licenza software, le operazioni software e la manutenzione | N/D | R | Medio-alta |
| Unità aziendale | Ad esempio, marketing, finanza, vendite | R | R | Elevata |
| Dettagli del proprietario | Informazioni di contatto per il proprietario dell'applicazione | R | R | Elevata |
| Informazioni sul DR | Componenti per il disaster recovery | R | R | Elevata |
| Strategia di migrazione | Ad esempio, una delle 6 R per la migrazione verso AWS | R | R | Elevata |
| Ticket di supporto | 12-24 mesi di dati per aiutare a valutare la produttività e l'impatto finanziario di interruzioni, rallentamenti, limitazione delle transazioni e superamento delle finestre dei batch | O | R | Media |
**Infrastruttura**
| **Nome attributo** | **Descrizione** | **Inventario e definizione delle priorità** | **Caso aziendale** | **Livello di fedeltà consigliato (minimo)** |
| --- | --- | --- | --- | --- |
| Identificatore univoco | Ad esempio, ID del server. In genere disponibile su inventari e sistemi di controllo esistenti CMDBs o altri sistemi di controllo interni. Prendi in considerazione la possibilità di crearne di unici IDs ogni volta che questi elementi non sono definiti nella tua organizzazione. | R | R | Elevata |
| Nome della rete | Nome della risorsa nella rete (ad es. nome host) | R | R | Elevata |
| Nome DNS (nome di dominio completo o FQDN) | Nome DNS | R | O | Elevata |
| Indirizzo IP e maschera di rete | and/or Indirizzi IP pubblici interni | R | R | Elevata |
| Tipo di asset | Ad esempio, server fisico o virtuale, hypervisor, contenitore, dispositivo, istanza di database | R | R | Elevata |
| Product name (Nome del prodotto) | Nome del fornitore commerciale e del prodotto (ad esempio, IBM Power VMware ESXi Systems, Exadata) | R | R | Elevata |
| Sistema operativo | Ad esempio, REHL 8, Windows Server 2019, AIX 6.1 | R | R | Elevata |
| Configurazione | CPU allocata, numero di core, thread per core, memoria totale, storage, schede di rete | R | R | Elevata |
| Utilizzo | Picco e medio di CPU, memoria e storage. Throughput delle istanze di database. | R | R | Elevata |
| Licenza | Tipo di licenza commodity (ad esempio, RHEL Standard) | R | R | Elevata |
| L'infrastruttura è condivisa? | Sì o No per indicare i servizi di infrastruttura che forniscono servizi condivisi come provider di autenticazione, sistemi di monitoraggio, servizi di backup e servizi simili | R | R | Elevata |
| Mappatura delle applicazioni | Applicazioni o componenti applicativi eseguiti in questa infrastruttura | R | R | Elevata |
| Costo | Costi completi per i server bare-metal, inclusi hardware, manutenzione, operazioni, storage (SAN, NAS, Object), licenza del sistema operativo, quota dello spazio su rack e spese generali del data center | N/D | R | Medio-alta |
| Volume stimato di trasferimento dei dati (in entrata/uscita) | Ad esempio, per asset infrastrutturale al giorno per un periodo di 30 giorni | O | R | Media |
**Reti**
| **Nome attributo** | **Descrizione** | **Inventario e definizione delle priorità** | **Caso aziendale** | **Livello di fedeltà consigliato (minimo)** |
| --- | --- | --- | --- | --- |
| Dimensioni del tubo () Mb/s), redundancy (Y/N | Specifiche attuali del collegamento WAN (ad esempio, 1000 MB/s ridondanti) | R | R | Medio-alta |
| Utilizzo del collegamento | Utilizzo medio e massimo, trasferimento dati in uscita (GB/mese) | R | R | Medio-alta |
| Latenza (ms) | Latenza attuale tra le postazioni connesse. | R | O | Elevata |
| Costo | Costo mensile attuale | N/D | R | Medio-alta |
**Migrazione**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/application-portfolio-assessment-guide/understanding-complete-assessment-data-requirements.html)
# Stabilire una linea di base per il portafoglio di applicazioni
Per creare piani di migrazione ad alta affidabilità, è necessario stabilire una linea di base per il portafoglio di applicazioni e l'infrastruttura associata. Una linea di base del portafoglio fornisce una visione completa dell'ambito della migrazione, comprese le dipendenze tecniche e la strategia di migrazione. La linea di base del portafoglio fornisce chiarezza su quali applicazioni rientrano nell'ambito della migrazione e sulla raccolta dei dati delineati nella sezione [Comprensione completa dei requisiti relativi ai dati di valutazione](understanding-complete-assessment-data-requirements.md). Allo stesso modo, tutta l'infrastruttura associata (reti di elaborazione e storage) viene compresa e mappata alle applicazioni.
Le dipendenze tecniche possono essere descritte in quattro categorie:
+ **pplication-to-infrastructureLe dipendenze stabiliscono il collegamento tra software e hardware fisico o virtuale.** Ad esempio, esiste una dipendenza tra un'applicazione CRM e le macchine virtuali su cui è installata.
+ Le dipendenze **tra i componenti dell'applicazione** descrivono il modo in cui interagiscono i componenti in esecuzione in diversi asset dell'infrastruttura. Un esempio di dipendenza tra componenti dell'applicazione è un front-end Web in esecuzione su macchine virtuali, con un livello di applicazione in esecuzione su una macchina virtuale diversa e un database in esecuzione su un cluster di database.
+ **pplication-to-applicationLe dipendenze si riferiscono all'interazione tra applicazioni o componenti dell'applicazione con altre applicazioni o i relativi componenti.** Un esempio di application-to-application dipendenza è un'applicazione per l'elaborazione dei pagamenti e un'applicazione per la gestione delle scorte. Queste applicazioni sono indipendenti, ma interagiscono costantemente utilizzando operazioni API definite.
+ Application-to-infrastructure le dipendenze **dei servizi** sono tecnicamente application-to-application dipendenze, dato che il servizio di infrastruttura è esso stesso un'applicazione. Tuttavia, consigliamo di classificarle separatamente. Il motivo principale è che i servizi di infrastruttura sono in genere condivisi da molte applicazioni, quindi hanno una lunga serie di dipendenze. Inoltre, in genere seguono una strategia e uno schema di migrazione diversi. Ad esempio, un load balancer può contenere pool di bilanciamento per diverse applicazioni. Ciò che conta è la dipendenza dal pool, che probabilmente verrà migrato singolarmente, insieme all'applicazione dipendente, mentre il sistema di bilanciamento del carico stesso viene mantenuto o ritirato. Inoltre, l'individualizzazione delle dipendenze dei servizi aiuta a evitare falsi gruppi di dipendenze. application-to-infrastructure Un gruppo di false dipendenze si verifica quando diverse applicazioni aziendali vengono raggruppate insieme, il che implica che quelle che hanno una dipendenza comune da un servizio di infrastruttura devono essere migrate contemporaneamente. Ad esempio, è probabile che i servizi di autenticazione, come Active Directory, siano associati a grandi gruppi di applicazioni. La chiave è affrontare queste applicazioni individualmente e risolvere la dipendenza abilitando il servizio AWS Directory Service for Microsoft Active Directory, ad esempio nell'ambiente cloud.
Quando stabilisci una linea di base per il portafoglio, ti consigliamo di confermare una strategia di migrazione per ogni componente dell'applicazione. La strategia di migrazione sarà una delle 6 R per la migrazione (vedi la sezione [Iterazione della strategia di migrazione delle 6 R](iterating-6-rs-migration-strategy-selection.md)). Nella linea di base del portafoglio, una delle 6 R deve essere associata a ciascuna applicazione. Una strategia 6R dovrebbe inoltre essere associata a ciascuno dei componenti dell'infrastruttura dell'applicazione.
Per stabilire una versione di base del portafoglio, comprese le dipendenze e le strategie di migrazione, utilizza strumenti di rilevamento automatizzato (vedi [Valutazione della necessità](understanding-initial-assessment-data-requirements.md#discovery-tooling) di strumenti di rilevamento). Completa i dati con le informazioni raccolte dalle principali parti interessate, come i proprietari delle applicazioni e i team dell'infrastruttura. Continua a raccogliere dati fino a ottenere un inventario completo del portafoglio che corrisponda agli attributi e al livello di fedeltà descritti nella [sezione relativa ai requisiti in materia di dati per questa fase](understanding-complete-assessment-data-requirements.md). Il set di dati risultante sarà fondamentale per guidare la migrazione.
Considerate che, a seconda dell'estensione dell'ambito di migrazione e degli strumenti disponibili, il completamento di questa attività può richiedere diverse settimane.
# Iterazione dei criteri di assegnazione delle priorità
Prima di creare piani di migrazione, si consiglia di modificare i criteri di prioritizzazione delle applicazioni per passare dalla selezione delle applicazioni pilota alla pianificazione a lungo termine.
[Nelle sezioni precedenti, abbiamo introdotto un criterio di prioritizzazione predefinito che dava priorità alle semplici applicazioni pronte per il cloud (vedi Assegnazione di priorità alle applicazioni).](prioritization-and-migration-strategy.md#prioritizing-applications) Questo perché nelle fasi iniziali consigliamo di iniziare con applicazioni non critiche per affinare i processi di migrazione e incorporare le lezioni apprese. Tuttavia, in questa fase e per creare piani a lungo termine, l'ordine in cui le applicazioni vengono migrate deve essere allineato ai fattori di business. L'applicazione dei nuovi criteri genererà una nuova classifica delle candidature che costituirà un elemento chiave per la pianificazione delle ondate.
Esaminate i dati disponibili dal portafoglio di applicazioni e selezionate gli attributi che determineranno la prioritizzazione delle applicazioni in base ai fattori di business.
Innanzitutto, convalida i tuoi driver aziendali (vedi [Driver aziendali e principi guida tecnici](business-drivers-technical-guiding-principles.md)). Successivamente, in base ai tuoi fattori di business, seleziona gli attributi che ti aiuteranno a dare priorità alle applicazioni per la migrazione.
La tabella seguente mostra esempi di criteri di prioritizzazione allineati ai driver aziendali per l'innovazione.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/application-portfolio-assessment-guide/iterating-prioritization-criteria.html)
La tabella seguente mostra esempi di criteri di prioritizzazione allineati ai driver aziendali per una rapida riduzione dei costi.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/application-portfolio-assessment-guide/iterating-prioritization-criteria.html)
Verifica i criteri di assegnazione delle priorità e ripeti fino a raggiungere un accordo generale con l'output. Sono necessarie almeno tre o quattro iterazioni per ottenere una versione di base.
# Iterazione della selezione della strategia di migrazione a 6 R.
In questa fase, ti consigliamo di iterare ed evolvere l'albero decisionale a 6 R. La sezione [Determinazione del tipo R per la migrazione](prioritization-and-migration-strategy.md#migration-r-type) ha introdotto un albero decisionale predefinito. Consigliamo di rivedere l'albero, di prendere in considerazione quanto appreso durante la migrazione delle applicazioni pilota iniziali e di assicurarci che sia ancora in linea con i fattori di business, i criteri di prioritizzazione e le circostanze specifiche. Convalida l'albero decisionale con applicazioni di esempio e verifica che produca ancora la strategia prevista. Altrimenti, aggiorna la logica di conseguenza. L'albero risultante sarà fondamentale per stabilire le linee di base per il portafoglio di applicazioni e per allocare le strategie di migrazione per ogni componente dell'applicazione.
Come descritto nella precedente [sezione 6 R](prioritization-and-migration-strategy.md#migration-r-type), le 6 R si applicano anche all'infrastruttura ed è altrettanto importante assegnarle di conseguenza. Sebbene un determinato componente applicativo abbia una strategia di migrazione, a livello di infrastruttura, ogni asset dell'infrastruttura seguirà una determinata strategia di migrazione che potrebbe essere diversa dalla strategia stabilita per il componente applicativo che supporta.
Ricorda che l'albero decisionale delle 6 R si applica solo ai componenti dell'applicazione. La strategia di migrazione per l'infrastruttura deriva dalla strategia scelta per l'applicazione. Ad esempio, per un componente applicativo che verrà riorganizzato, l'attuale infrastruttura che lo ospita potrebbe essere ritirata.
Assicuratevi che le strategie di migrazione siano assegnate a ciascun componente dell'applicazione e all'infrastruttura associata. Queste informazioni saranno un fattore chiave per stimare lo sforzo, la capacità e le competenze necessarie e per creare piani per l'ondata di migrazione.
Per ulteriori informazioni sulla determinazione delle 6 R, consulta i [consigli AWS Migration Hub strategici](https://aws.amazon.com/blogs/aws/new-strategy-recommendations-service-helps-streamline-aws-cloud-migration-and-modernization/).
# Pianificazione delle onde
Nella pianificazione delle ondate, un gruppo di dipendenze è un insieme di applicazioni e infrastrutture che hanno dipendenze tecniche e non tecniche che non possono essere risolte. A causa di queste dipendenze, le applicazioni e l'infrastruttura di un gruppo di dipendenze devono essere migrate contemporaneamente o in una data specifica. Ad esempio, è probabile che un'applicazione in esecuzione su una macchina virtuale e un database in esecuzione su una macchina virtuale separata, in cui vi sono requisiti di bassa latenza o volumi di traffico elevati e query complesse, vengano migrati insieme anziché utilizzare un componente nel cloud e l'altro in locale. Allo stesso modo, verranno migrate contemporaneamente anche le applicazioni indipendenti che interagiscono tramite un'API con requisiti di bassa latenza simili.
Le ondate di migrazione durano in genere da 4 a 8 settimane e possono contenere uno o più eventi di migrazione. I gruppi di dipendenze vengono combinati in ondate in modo che un'onda possa contenere uno o più gruppi di dipendenze. L'ondata contiene anche altre attività necessarie per la migrazione. Questi includono la configurazione AWS dell'infrastruttura (come la landing zone, la sicurezza e le operazioni), gli strumenti di migrazione e le attività di migrazione come la replica dei dati, la pianificazione completa, i test e il supporto post-migrazione.
Per misurare il successo e tenere traccia dei progressi, le ondate devono essere allineate ai risultati e ai fattori di business. Ciò influirà anche sulla durata dell'onda e sui gruppi di dipendenza contenuti in un'onda. Il completamento di un'ondata dovrebbe riflettere un risultato misurabile. La pianificazione di un'onda può anche combinare altri fattori, come i principi guida tecnici. Ad esempio, le onde possono essere definite in base all'ambiente (ad esempio, sviluppo, test, produzione) o alla strategia di migrazione (ad esempio, rehost wave, replatform wave).
Per creare piani di migrazione efficaci e altamente affidabili, è necessario ottenere una visione completa del portafoglio di applicazioni, dell'infrastruttura associata (elaborazione, archiviazione, reti), della mappatura delle dipendenze e della strategia di migrazione.
La sezione sulla [definizione di una linea di base per il portafoglio di applicazioni](baseline-application-portfolio.md) descriveva quattro categorie di dipendenze tecniche. Queste dipendenze contribuiscono alla creazione di ondate migratorie e alla definizione dei gruppi di dipendenza. I gruppi di dipendenza saranno determinati dalla criticità della dipendenza. Inoltre, devono essere prese in considerazione le dipendenze non tecniche. Ad esempio, le pianificazioni di rilascio delle applicazioni, le finestre di manutenzione e le date aziendali chiave, come l'elaborazione di fine mese o di fine trimestre, influenzeranno il piano d'ondata.
Determina se la dipendenza è *morbida* o *rigida*. Una dipendenza morbida è una relazione tra due o più asset, o tra una risorsa e un vincolo, che non dipende dalla posizione dei componenti. Ad esempio, due sistemi che operano nella stessa rete locale (o nella stessa infrastruttura) possono essere separati spostando uno di questi sistemi nel cloud mentre l'altro rimane in sede. Un altro esempio è un sistema che può essere migrato durante una finestra di manutenzione senza influire sulle attività di manutenzione.
Una forte dipendenza è una relazione tra due o più risorse, o da una risorsa a un vincolo, che dipende dalla posizione. Ad esempio, due sistemi che operano nella stessa rete locale e che dipendono fortemente dalla bassa latenza per la comunicazione tra il server delle applicazioni e il server del database hanno una forte dipendenza. Lo spostamento di uno solo di questi sistemi nel cloud causerebbe problemi di funzionalità o prestazioni che non possono essere risolti. Allo stesso modo, ragioni non tecniche, come la disponibilità delle risorse (ad esempio, il team che esegue la migrazione) o vincoli operativi, come le finestre di manutenzione in cui è possibile migrare due sistemi solo in una determinata finestra temporale, potrebbero creare una forte dipendenza per queste risorse.
Per creare un piano di migrazione, è necessario determinare i gruppi di dipendenze analizzando le dipendenze, preferibilmente da una fonte di dati altamente affidabile come strumenti di rilevamento specializzati, e combinare queste informazioni con i criteri di prioritizzazione delle applicazioni e le circostanze operative. Le applicazioni in cima alla classifica di priorità devono essere indirizzate alle ondate di migrazione iniziali. Determina la capacità delle onde (il numero di applicazioni che un'ondata può contenere) in base alla disponibilità delle risorse, alla propensione al rischio, ai vincoli aziendali e tecnici, all'esperienza e alle competenze. Prendi in considerazione la possibilità di collaborare con AWS Professional Services o AWS Migration Competency Partners, che possono fornire specialisti in grado di assisterti durante tutto il processo.
I criteri di prioritizzazione sono un'indicazione iniziale dell'ordine in cui sposterai le tue applicazioni sul cloud. Tuttavia, i gruppi di dipendenze saranno il fattore determinante effettivo per le applicazioni che verranno spostate in un determinato momento. Questo perché le applicazioni classificate come priorità alta potrebbero avere forti dipendenze dalle applicazioni che si trovano nella parte centrale o inferiore della classifica.
La strategia di migrazione influirà anche sulla composizione di un'ondata. Ad esempio, un'applicazione ad alta priorità che richiede una strategia di rifattorizzazione che potrebbe richiedere diverse settimane o mesi di analisi, progettazione, test e preparazione verrà probabilmente inserita in un'ondata successiva.
## Creazione di un piano ondulatorio
Un prerequisito per la migrazione di un'ondata di applicazioni è costituito dai dati del portafoglio di applicazioni e dalla valutazione dettagliata delle applicazioni del gruppo di applicazioni che verranno migrate nell'ambito di tale ondata. La valutazione dettagliata dovrebbe includere l'elenco delle applicazioni incluse nell'ondata, i dettagli dell'infrastruttura associata, una progettazione degli obiettivi e una strategia di migrazione per ciascuna applicazione.
Stabilire la titolarità e la governance di Wave è fondamentale per gestire e monitorare l'ondata di lavoro, le dipendenze tra i programmi, la gestione delle modifiche, i problemi e i rischi. Assicurati che sia in atto un quadro di governance per gestire il piano.
Per delineare il piano ondulatorio, inizia con un costrutto d'onda predefinito. Cosa succede all'interno di un'onda? Dopo aver definito l'ingresso iniziale, l'onda può iniziare. In genere, le attività saranno:
1. Perfeziona il piano di cutover. Questa attività dovrebbe delineare i manuali e le misure da adottare al momento della migrazione, compreso il coordinamento con altri team interni ed esterni.
1. Perfeziona il piano di rollback. Cosa si deve fare per ripristinare le applicazioni se le cose vanno male?
1. Prepara l'infrastruttura di destinazione. Ad esempio, è possibile creare o estendere la AWS landing zone (sicurezza Account AWS, rete, servizi di infrastruttura, altre infrastrutture di supporto).
1. Esegui il test dell'infrastruttura di destinazione.
1. Utilizza gli strumenti di migrazione. Ad esempio, installa gli agenti di replica e avvia il trasferimento dei dati.
1. Esegui un piano Cutover ed esegui le esecuzioni a secco. Raggruppa tutti i membri del team partecipanti e rivedi tutti i passaggi in anticipo.
1. Monitora la replica dei dati e le implementazioni dell'infrastruttura.
1. Conferma la disponibilità per il funzionamento dell'infrastruttura e delle applicazioni in. AWS
1. Conferma la disponibilità alla sicurezza.
1. Conferma la conformità e i requisiti normativi (ad esempio, la convalida del carico di lavoro prima e dopo la migrazione), se applicabile.
1. Migra le applicazioni AWS ed esegui i test prima del lancio.
1. Fornisci supporto post-migrazione per un periodo di tempo, ad esempio 3 giorni, in cui i team operativi e i team di migrazione sono completamente disponibili per risolvere i problemi e applicare le ottimizzazioni.
1. Effettua una revisione successiva alla migrazione. Documenta le lezioni apprese e incorporale nelle ondate future.
1. Esegui la chiusura dell'ondata confermando il passaggio di consegne operative e ottenendo le metriche per la rendicontazione.
La durata di ciascuna di queste attività dipenderà dalla complessità dell'ambito, dalla capacità delle onde, dalle persone coinvolte e dalle circostanze specifiche. Ove possibile, sono preferibili onde più piccole perché ciò ridurrà l'impatto di eventuali ritardi o ostacoli alla migrazione. Stabilite, insieme ai vostri team, quale sarà la durata predefinita di un'ondata.
Successivamente, procedi con l'analisi delle date per creare una struttura iniziale di alto livello di onde vuote (senza ancora assegnare alcuna applicazione). Considerate le seguenti domande:
+ Qual è la durata totale del programma di migrazione?
+ Quali sono le scadenze?
+ Esistono date di uscita fisse per i data di uscita dal data center?
+ Esistono date di scadenza del contratto di collocazione?
+ Quali sono i cicli di aggiornamento delle applicazioni e dell'infrastruttura?
+ Quali sono i cicli di manutenzione e rilascio delle applicazioni?
+ Esistono date in cui è necessario evitare le migrazioni (ad esempio, cicli di rilascio e manutenzione, fine anno, festività, elaborazione di fine mese)?
Con queste considerazioni, traccia le onde in un piano. Per accelerare il processo di migrazione, consigliamo di sovrapporre le onde ove possibile. La chiave per la sovrapposizione delle onde è definire e considerare cosa succede all'interno di un'onda. In genere, le attività di implementazione, la convalida dell'infrastruttura di destinazione e la sincronizzazione dei dati avverranno durante la prima metà di un'ondata. La seconda metà si concentrerà sulla migrazione effettiva, sui test e sulla consegna operativa. Ciò significa che team diversi sono coinvolti in ciascuna metà del processo e che è possibile aumentare l'efficienza. Ad esempio, non appena il team coinvolto nella preparazione dell'infrastruttura target ha completato il proprio lavoro, può iniziare a lavorare sui requisiti della fase successiva. In generale, è preferibile che la maggior parte delle onde abbia una lunghezza e una struttura simili per facilitare un approccio di fabbrica alle migrazioni. Tuttavia, durante il processo di pianificazione delle onde, la dimensione di una determinata onda può essere estesa per soddisfare dipendenze o requisiti operativi.
Successivamente, in base ai gruppi di dipendenza che sono stati identificati, determina la dimensione massima di un'onda in termini di numero di gruppi di dipendenza che può contenere. La dimensione delle onde è in genere dettata dalla propensione al rischio (ad esempio, quanto cambiamento parallelo può essere tollerato) e dalla disponibilità delle risorse (ad esempio, quante modifiche parallele possono essere eseguite con le risorse, le competenze e il budget disponibili). Tuttavia, durante la pianificazione precoce, non lasciatevi limitare dai requisiti e dalla disponibilità delle risorse. Le onde che contengono più di un gruppo di dipendenze possono essere scomposte in onde più piccole nelle iterazioni future.
Dopo la conferma dei gruppi di dipendenza per una determinata ondata, esamina i requisiti di risorse per la migrazione dell'ondata. Valuta la possibilità di modificare la dimensione dell'onda (il numero di gruppi di dipendenze che contiene) in base ai requisiti di risorse. Ciò potrebbe portare a onde più piccole o più grandi. Iterate il piano d'onda secondo necessità fino a definire tutte le onde.
## Gestire il cambiamento
Il portafoglio di applicazioni e l'infrastruttura associata cambieranno durante il ciclo di vita dei programmi di migrazione. I programmi di migrazione a lungo termine coesistono con la normale evoluzione e cambiamento aziendale. Le applicazioni continuano a evolversi in attesa di essere migrate. I server vengono aggiunti o rimossi, la nuova infrastruttura viene implementata in locale. Si prevede che l'ambito di un'ondata o di un gruppo di dipendenza richieda modifiche. Le modifiche sono necessarie soprattutto quando, in prossimità della data di migrazione, viene identificata una dipendenza precedentemente sconosciuta o viene incluso un nuovo server nell'inventario. A volte ciò può accadere durante la migrazione stessa.
Le modifiche all'ambito influiscono sui gruppi e sulle ondate di dipendenza. Per gestire il cambiamento e ridurre al minimo l'impatto, è importante stabilire un meccanismo di controllo dell'ambito. Un meccanismo di controllo della modifica dell'ambito richiede la definizione di un'unica fonte di verità per l'ambito. Potrebbe trattarsi di uno strumento per la gestione dell'ambito o di un file.csv, foglio di calcolo o database, come definito dalla governance del programma di migrazione. È necessario identificare le modifiche, analizzare l'impatto e comunicare le modifiche alle parti interessate in modo che possano agire. Di conseguenza, il piano d'ondata verrà iterato.
# Caso aziendale dettagliato
In questa fase, consigliamo di convalidare e ampliare l'ambito del business case per fornire un maggiore livello di dettaglio a supporto del programma di trasformazione. Il business case direzionale iniziale, assemblato rapidamente, è progettato per fornire sufficiente fiducia per investire nelle fasi fondamentali e nel successivo livello di pianificazione dettagliata.
Lo sviluppo di un business case dettagliato supporta questo processo di pianificazione nei seguenti modi:
+ Fornire analisi finanziarie che consentano di prendere decisioni su cosa migrare e modernizzare, quali opzioni selezionare e come strutturare e assegnare priorità al lavoro
+ Convalida, perfezionamento e sviluppo del caso finanziario direzionale originale riesaminando in dettaglio:
+ Il potenziale di riduzione dei costi dell'infrastruttura
+ La produttività IT interna e le eventuali efficienze delle operazioni esternalizzate
+ Le stime degli investimenti necessari per la configurazione, la migrazione e la modernizzazione del programma
+ Identificazione, stima della portata e impostazione del processo per tracciare gli ulteriori fattori di valore derivanti dalla migrazione
Nel business case dettagliato, stabilisci quanto segue:
+ La base oggettiva su cui garantire il mandato e gli investimenti necessari per implementare almeno la prima fase della migrazione
+ L'aspettativa di rendimento finanziario minimo di base per il programma
+ Chiarezza sulla base finanziaria su cui vengono prese le varie decisioni relative alla progettazione e alla definizione delle priorità della migrazione, in modo che, quando le circostanze e le persone cambiano nel corso del programma, la nuova leadership possa fare scelte consapevoli.
+ Informazioni approfondite sulle aree incrementali di ottimizzazione dei costi da esplorare dopo la disponibilità dei dati di utilizzo iniziali man mano che i carichi di lavoro vengono migrati e iniziano a funzionare
+ Stime del valore che la trasformazione del cloud apporta all'azienda grazie a una maggiore resilienza e agilità
+ Le metriche e le ipotesi associate KPIs utilizzate per stimare il ritorno finanziario derivante da una maggiore resilienza e agilità, che poi costituiscono la base per ottenere i principali vantaggi derivanti dal programma
## Determina gli scenari necessari per il caso
Quando si crea un business case dettagliato, in genere è necessario sviluppare più scenari per supportare i vari scopi per cui viene utilizzato il business case.
**Scenario di modifica minima**: per valutare l'aspettativa minima di performance finanziaria, prepara uno scenario che presupponga la modifica minima prevista dello status quo. Questo scenario, nella peggiore delle ipotesi, è un utile supporto per ottenere il mandato di investire nella migrazione. Questo scenario modella il grado minimo previsto di crescita della capacità e le modifiche minime per altre quality-of-service esigenze, come la disponibilità e la resilienza. La minima modifica crea i costi più bassi e le minori inefficienze in termini di risorse per il modello operativo corrente.
**Scenario più probabile**: per orientare le decisioni sulla strategia del programma e sulla definizione delle priorità, prepara lo scenario che rifletta ciò che l'azienda si aspetta che accada. Questo scenario dovrebbe includere la probabile crescita o riduzione del picco di utilizzo e i costi di aggiornamento per soddisfare la domanda di elevati livelli di qualità del servizio (in particolare disponibilità e resilienza) da parte dell'azienda.
**Altri scenari specifici**: laddove sia ancora necessario formulare un'ipotesi che possa avere un forte impatto sul business case, sviluppate scenari sia per i casi in cui l'ipotesi sia vera sia per quelli in cui non lo è. Tuttavia, consigliamo di mantenere il numero di questi scenari alternativi al minimo assoluto. La creazione di più di tre o quattro scenari in totale rallenta i progressi e diventa costosa, confusa e difficile da gestire. Ove possibile, conduci esperimenti e lavora per eliminare ipotesi più ampie.
## Convalida e perfeziona l'infrastruttura e il modello dei costi di migrazione
Dopo aver completato l'analisi del portafoglio e preparato la progettazione e il dimensionamento dell'obiettivo Servizi AWS, perfezionate le stime dei costi di esercizio per il modello operativo corrente (COM) e il modello operativo futuro (FOM) AWS per ogni scenario. In genere è necessario affinare le stime per quanto segue:
+ **costi dell'infrastruttura COM** per gli aggiornamenti, l'installazione e la manutenzione dell'hardware del server host hypervisor, del server bare-metal, dello storage, dei dispositivi di rete, degli aggiornamenti hardware dei dispositivi di sicurezza. Calcola questi valori con prezzi e livelli di sconto effettivi per la capacità necessaria per lo scenario.
+ **Costi dei data center e delle strutture collocate COM**, tra cui spazio, raffreddamento, alimentazione, rack, gruppi di continuità (UPS), cablaggio, sistemi di sicurezza fisica, dimensionati per la crescita e specificati per soddisfare la capacità e livelli di elevata disponibilità e disaster recovery (DR) previsti per lo scenario.
+ **Costi dei servizi di rete COM**, inclusi i costi per i collegamenti WAN, le reti di distribuzione dei contenuti e le reti private virtuali (VPNs), calcolati utilizzando i prezzi contrattuali per le esigenze di connettività, larghezza di banda, velocità effettiva e latenza per lo scenario.
+ **Costi del software per l'infrastruttura e l'applicazione COM** basati su contratti esistenti per garantire la crescita o la riduzione dell'utilizzo in base allo scenario.
+ **I costi delle AWS utenze FOM**, compresi il supporto tecnico e i servizi gestiti in base alle esigenze, si basano sulla raffinata architettura dei servizi, sulle dimensioni delle istanze, sul modello di prezzo preferito, sull'utilizzo previsto e sulla volatilità dell'utilizzo.
+ **Licenze delle applicazioni FOM** basate sulla progettazione finale dell'applicazione, sulla configurazione dell'infrastruttura che esegue le applicazioni, sulla crescita nel tempo e sulle regole di trasferibilità delle licenze.
+ **Stime dei costi di migrazione e modernizzazione del FOM**, rielaborate per riflettere il piano di migrazione di base per lo scenario e dettagliate per indicare i costi per ogni carico di lavoro, in particolare per quelli da riformare, riacquistare o rifattorizzare.
+ **I costi di smantellamento della FOM**, comprese le stime dei costi di cancellazione degli asset e dei costi di risoluzione anticipata del contratto, sono stati rivisti per tenere conto dei tempi di disattivazione indicati nel piano di migrazione di base, della verifica di quali risorse possono essere riutilizzate e quali risorse possono essere sostituite per ridurre al minimo le cancellazioni e del costo di smaltimento delle risorse fisiche e dei supporti.
+ **I costi di esecuzione parallela della migrazione** sono stati perfezionati per riflettere la tempistica di ogni cutover di migrazione e di ogni disattivazione dei servizi esistenti.
## Perfeziona la produttività e le operazioni IT e supporta il modello di valore relativo all'efficienza
Come per il business case direzionale, esistono due approcci principali per perfezionare e sviluppare il modello di valore relativo alle operazioni e al supporto IT. L'approccio scelto dipende dal fatto che la COM sia gestita internamente o con appaltatori o servizi in outsourcing:
*Miglioramento della produttività del team interno*
Laddove le operazioni e il supporto IT sono gestiti internamente, il business case si concentra su quanto segue:
+ Identificazione e quantificazione degli incrementi di produttività derivanti dalla migrazione e da qualsiasi automazione operativa inclusa nell'ambito
+ Convalidare che il tempo liberato per il team interno possa essere applicato prontamente e in modo produttivo ad altre attività tipicamente di maggior valore, offrendo opportunità di progressione e maggiore ricompensa al team e più valore all'organizzazione
Valuta quanto tempo ogni membro di ogni ruolo all'interno del team dedica alle varie attività regolari e fornisci indicazioni sulla riduzione prevista del carico di lavoro per le diverse attività.
La tabella seguente fornisce una guida iniziale per i livelli tipici di riduzione del carico di lavoro in base all'attività per quelle attività che richiedono la maggior parte delle operazioni IT e delle attività di supporto tra i diversi ruoli del team. La tabella include una descrizione di come viene raggiunta la produttività.
**Nota**
Le attività elencate vengono in genere eseguite dai membri del team in diversi ruoli, pertanto è necessario valutare il risparmio di produttività per ciascuna attività nell'insieme dei ruoli del team. Ad esempio, nei team operativi IT organizzati per infrastruttura (ad esempio elaborazione, storage e rete), la pianificazione e la definizione del budget delle spese in conto capitale potrebbero essere comuni ai responsabili di ogni torre.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/application-portfolio-assessment-guide/detailed-business-case.html)
La tabella seguente mostra i risparmi previsti per ogni livello di riduzione del carico di lavoro.
| **Livello** | **Previsto** |
| --- | --- |
| Molto alto | 85% - 100% |
| Elevata | 60% - 90% |
| Media | 30% - 70% |
| Bassa | 10% - 35% |
| Minima | 0% - 10% |
Queste metriche forniscono un punto di partenza per valutare gli aumenti di produttività e includerli nel business case dettagliato. Gli incrementi di produttività effettivi variano in base alla situazione specifica. Può essere utile calcolare i risparmi di produttività sia al limite medio che a quello inferiore degli intervalli per stimare scenari tipici e prudenti.
Man mano che il programma procede, è utile acquisire dati effettivi relativi al tempo dedicato a ciascuna attività per ruolo. Questi dati creano una base migliore per la stima delle operazioni e supportano i costi per nuovi progetti ed espansioni dei servizi.
*Operazioni IT esternalizzate e riduzione dei costi di supporto*
[Laddove le operazioni e il supporto IT sono principalmente esternalizzati o gestiti da appaltatori, l'allocazione dei costi per il futuro modello operativo (FOM) può essere preparata richiedendo preventivi AWS ai partner che offrono soluzioni di servizi gestiti, tra cui Partner-LED (AMS). AWSAWS Managed Services](https://aws.amazon.com/managed-services/partners/) [Puoi anche contattare il tuo AWS account manager e richiedere direttamente un prezzo per AMS, come descritto nella sottosezione Promuovere l'[ottimizzazione dei costi operativi nella sezione Creazione](directional-business-case.md#building-operational-cost-optimization) di un business case direzionale.](directional-business-case.md)
Per il business case dettagliato, sostituisci qualsiasi dato di riferimento con un preventivo basato sulla distinta base dei AWS servizi rivista e sul consumo previsto del servizio, sul pacchetto AMS e sulle eventuali opzioni necessarie e sul livello di servizio richiesto. Il costo includerà un componente di implementazione una tantum e una frequenza di esecuzione basata sul consumo.
Include tutte le operazioni IT rimanenti, il supporto che deve essere mantenuto per qualsiasi servizio a cui non verrà effettuata la migrazione e un costo una tantum in caso di penali contrattuali (ad esempio AWS, in caso di risoluzione anticipata).
## Sviluppa il modello di valore della resilienza
On AWS, puoi costruire un'ampia gamma di architetture ad alta disponibilità, disaster recovery e tolleranti ai guasti. Per prezzi basati sul consumo si intende che i servizi vengono addebitati solo quando vengono utilizzati. Insieme, questi due fattori offrono prestazioni di costo eccezionali in termini di resilienza.
Inoltre, AWS i clienti lo hanno utilizzato per migliorare la resilienza dei loro carichi di lavoro. Il [sondaggio IDC 2018](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770) fornisce esempi di clienti partecipanti che hanno ottenuto il 73% in meno di interruzioni all'anno, una riduzione del 58% del tempo medio di ripristino (MTTR) e una riduzione del 94% della perdita di produttività. La stessa indagine ha mostrato che i vantaggi finanziari derivanti da una maggiore resilienza erano superiori del 50% rispetto alla riduzione dei costi dell'infrastruttura IT.
Inoltre, si ottiene un'ulteriore resilienza attraverso la modernizzazione del ciclo di vita di sviluppo del software per le applicazioni. Laddove vengono CI/CD introdotte pipeline con automazione dei test per supportare una maggiore agilità aziendale, i difetti del software vengono rilevati nelle prime fasi del ciclo di sviluppo, riducendo notevolmente i costi di manutenzione del software.
**Per valutare e includere questo valore nel business case, è innanzitutto necessario collaborare con i titolari delle aziende che si occupano di applicazioni per definire un quadro dei *vantaggi complessivi offerti* da ciascun carico di lavoro da migrare.**Ciò potrebbe includere i seguenti elementi:
+ Il numero, la durata media e la natura delle interruzioni del servizio:
+ Tra gli esempi di interruzioni del servizio vi sono interruzioni, rallentamenti delle prestazioni, sovraccarico pianificato dei batch e degli intervalli di manutenzione, bug nelle funzioni chiave e limitazione degli accessi durante i periodi di punta.
+ Impatto sui ricavi delle interruzioni di servizi generatori di entrate, come i sistemi di e-commerce:
+ Il numero probabile di transazioni che non possono essere completate a causa di interruzioni del servizio, in base al tempo di interruzione e ai tassi di transazione
+ Il valore medio di ogni transazione ha influito
+ Il costo aggiuntivo del tempo impiegato dai tecnici di supporto per risolvere i difetti nei sistemi di produzione rispetto al costo della loro individuazione nelle fasi iniziali del processo di sviluppo
+ Impatto sulla produttività degli utenti interni e sul costo del tempo perso
Effettua quindi una valutazione della riduzione prevista e di una riduzione più prudente del tempo perso a causa delle interruzioni del servizio**** che la maggiore resilienza dovrebbe comportare. Ad esempio, valuta la possibilità di includere i seguenti elementi:
+ Riduzione del numero di interruzioni e dell'MTTR utilizzando architetture ad alta disponibilità e migliorando il Recovery Time Objective (RTO) e il Recovery Point Objective (RPO)
+ Riduzione dei rallentamenti, eliminazione della limitazione della capacità ed evitamento dei sovraccarichi di elaborazione in batch, grazie a funzionalità come la scalabilità automatica
+ Riduzione del numero di bug delle applicazioni rilevati solo in produzione, grazie all'implementazione di CI/CD pipeline e ai test di regressione automatizzati sull'infrastruttura, attivati e riorganizzati per ridurre al minimo i costi
Mettili insieme per creare il portafoglio di applicazioni da migrare e modernizzare e calcola i valori aziendali attesi e quelli più prudenti per ogni anno del caso. I vantaggi dovrebbero aumentare in linea con il programma di migrazione e quindi scalare in termini di volume in linea con le aspettative di crescita dell'utilizzo delle applicazioni partecipanti.
## Sviluppa il modello di valore dell'agilità aziendale
L'agilità aziendale è la ragione principale verso cui AWS i clienti migrano. AWS L'[indagine IDC 2018 sui](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770) AWS clienti ha indicato che, per loro, i vantaggi in termini di agilità aziendale rappresentavano il 47% dei vantaggi totali misurati e oltre cinque volte i vantaggi derivanti dalla riduzione dei costi dell'infrastruttura.
È difficile prevedere con precisione tutti i vantaggi in termini di agilità aziendale derivanti da qualsiasi trasformazione. Tuttavia, concentrandosi su applicazioni che supportano un gran numero di utenti o sono fonti di differenziazione aziendale, è possibile modellare e includere una parte sostanziale di questo vantaggio nel business case dettagliato di base.
Man mano che la migrazione procede, perfezionate ed espandete in modo incrementale il modello di valore dell'agilità aziendale man mano che ulteriori vantaggi diventano quantificabili. Ciò mantiene il business case pertinente, in modo che possa essere utilizzato come principale strumento di supporto decisionale con cui indirizzare il programma.
Per creare il modello di valore dell'agilità aziendale, utilizza le seguenti linee guida:
+ Seleziona i carichi di lavoro che hanno l'opportunità di favorire il massimo miglioramento delle prestazioni aziendali, come:
+ Carichi di lavoro che generano entrate
+ Carichi di lavoro operativi aziendali con possibilità di aumentare l'efficienza e ridurre i costi aziendali
+ Strumenti di produttività aziendale che supportano ampie basi di utenti
+ Per carichi di lavoro che generano entrate ed efficienza, procedi come segue:
+ Effettua una valutazione realistica e più prudente della crescita dei ricavi o dell'efficienza operativa che potrebbero derivare dagli aggiornamenti principali e minori delle applicazioni.
+ Stima l'aumento del numero di release principali e secondarie all'anno, reso possibile dall' AWS aumento della velocità di sviluppo delle applicazioni e dalla riduzione dei tempi di implementazione dell'infrastruttura. Alcune metriche di base al riguardo sono fornite nel rapporto IDC.
+ Calcola le aspettative realistiche e più conservative in termini di benefici. Mappale nel periodo in cui si colloca il business case, tenendo conto della possibilità di raggiungere la piena efficienza qualche tempo dopo la migrazione dei rispettivi carichi di lavoro.
+ Per quanto riguarda gli strumenti di produttività aziendale, procedi come segue:
+ Effettua una valutazione realistica e più prudente dei risparmi di tempo che ci si potrebbe aspettare dagli aggiornamenti principali e minori delle applicazioni.
+ Stima il costo medio del tempo e dell'impegno delle persone in tutta la base di utenti interessata.
+ Utilizza i dati per aumentare la frequenza dei rilasci principali e secondari e calcola i vantaggi nel corso del business case.
Poiché l'aumento della produttività degli sviluppatori e la riduzione dei tempi di lancio non richiedono risorse aggiuntive, aggiungi le linee di benefit nette per ogni carico di lavoro al modello di flusso di cassa del business case per includerle nei calcoli del flusso di cassa scontato, NPV, ROI, MIRR e ammortamento.