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à.
# Accelerazione delle scoperte e pianificazione iniziale
Questa prima fase della valutazione del portafoglio si concentra sulle fasi iniziali dell'ottenimento e dell'analisi dei dati a livello di portafoglio. L'obiettivo principale è identificare i fattori di business e raccogliere dati generali dalle applicazioni e dall'infrastruttura per ottenere una visione iniziale del portafoglio. Questi dati includono attributi tecnici e commerciali di alto livello come i nomi delle applicazioni, l'ambiente, le versioni dei prodotti, la criticità, i valori delle prestazioni e altri, come descritto nella sezione [sui requisiti dei dati](understanding-initial-assessment-data-requirements.md). Il completamento di questa fase è fondamentale per comprendere l'ambito del progetto, identificare i candidati iniziali alla migrazione e fornire informazioni sul business case.
## Principali risultati di questa fase
+ Driver aziendali, risultati, obiettivi e principi guida tecnici documentati.
+ Un inventario iniziale delle applicazioni e dell'infrastruttura e identificazione delle lacune nei dati. Questa è una visione iniziale del portafoglio che verrà iterata e perfezionata in fasi successive.
+ Un business case direzionale e una stima dei costi di migrazione.
+ Un elenco di candidati alla migrazione iniziale (ad esempio, tre-cinque applicazioni).
+ Fasi successive definite.
# Comprensione dei requisiti relativi ai dati di valutazione iniziale
La raccolta dei dati può richiedere molto tempo e diventare facilmente un ostacolo quando non c'è chiarezza su quali dati sono necessari e quando sono necessari. La chiave è capire l'equilibrio tra i dati insufficienti e quelli che sono troppi per i risultati di questa fase. Per concentrarti sui dati e sul livello di fedeltà richiesti per questa fase iniziale della valutazione del portafoglio, adotta un approccio iterativo alla raccolta dei dati.
## Fonti di dati e requisiti in materia di dati
Il primo passaggio consiste nell'identificare le fonti di dati. Inizia identificando le principali parti interessate all'interno della tua organizzazione in grado di soddisfare i requisiti in materia di dati. Si tratta in genere di membri dei team di gestione dei servizi, operazioni, pianificazione della capacità, monitoraggio e supporto e dei proprietari delle applicazioni. Stabilisci sessioni di lavoro con i membri di questi gruppi. Comunica i requisiti in materia di dati e ottieni un elenco di strumenti e documentazione esistente in grado di fornire i dati.
Per guidare queste conversazioni, usa la seguente serie di domande:
+ Quanto è accurato e aggiornato l'attuale inventario dell'infrastruttura e delle applicazioni? Ad esempio, per quanto riguarda il database di gestione della configurazione aziendale (CMDB), sappiamo già quali sono le lacune?
+ Disponiamo di strumenti e processi attivi che mantengono aggiornato il CMDB (o uno equivalente)? In caso affermativo, con quale frequenza viene aggiornato? Qual è la data di aggiornamento più recente?
+ L'inventario corrente, ad esempio il CMDB, contiene application-to-infrastructure mappature? Ogni risorsa dell'infrastruttura è associata a un'applicazione? Ogni applicazione è mappata sull'infrastruttura?
+ L'inventario contiene un catalogo di licenze e contratti di licenza per ogni prodotto?
+ L'inventario contiene dati sulle dipendenze? Nota l'esistenza di dati di comunicazione come da server a server, da applicazione a applicazione, da applicazione o da server a database.
+ Quali altri strumenti in grado di fornire informazioni sulle applicazioni e sull'infrastruttura sono disponibili nell'ambiente? Nota l'esistenza di strumenti di prestazioni, monitoraggio e gestione che possono essere utilizzati come fonte di dati.
+ Quali sono le diverse sedi, ad esempio i data center, che ospitano le nostre applicazioni e la nostra infrastruttura?
Dopo aver risposto a queste domande, elenca le fonti di dati identificate. Quindi assegna un livello di fedeltà, o un livello di fiducia, a ciascuna di esse. I dati convalidati di recente (entro 30 giorni) da fonti programmatiche attive, come gli strumenti, hanno il massimo livello di fedeltà. I dati statici sono considerati di bassa fedeltà e meno affidabili. Esempi di dati statici sono documenti, cartelle di lavoro aggiornati CMDBs manualmente o qualsiasi altro set di dati non gestito a livello di programmazione o la cui data dell'ultimo aggiornamento è precedente a 60 giorni.
I livelli di fedeltà dei dati riportati nella tabella seguente sono forniti a titolo di esempio. Si consiglia di valutare i requisiti dell'organizzazione in termini di massima tolleranza alle ipotesi e ai rischi associati per determinare quale sia il livello di fedeltà appropriato. Nella tabella, le conoscenze istituzionali si riferiscono a qualsiasi informazione sulle applicazioni e sull'infrastruttura non documentata.
| **Origine dati** | **Livello di fedeltà** | **Copertura del portafoglio** | **Commenti** |
| --- |--- |--- |--- |
| Conoscenza istituzionale | Bassa: fino al 25% dei dati accurati, il 75% dei valori presunti o i dati risalgono a più di 150 giorni. | Bassa | Scarso, focalizzato su applicazioni critiche |
| Knowledge base | Medio-basso: il 35-40% dei dati accurati, il 65-60% dei valori presunti o i dati risalgono a 120-150 giorni fa. | Media | Livelli di dettaglio non coerenti mantenuti manualmente |
| CMDB | Medio: \$1 50% dei dati accurati, \$1 50% dei valori presunti o i dati risalgono a 90-120 giorni fa. | Media | Contiene dati provenienti da fonti miste, diverse lacune di dati |
| VMware Esportazioni vCenter | Medio-alto: 75-80% di dati accurati, 25-20% di valori presunti o i dati risalgono a 60-90 giorni fa. | Elevata | Copre il 90% dello spazio virtualizzato |
| Monitoraggio delle prestazioni delle applicazioni | Alto: dati per lo più accurati, valori presunti pari a circa il 5% o dati risalgono a 0-60 giorni fa. | Bassa | Limitato ai sistemi di produzione critici (copre il 15% del portafoglio di applicazioni) |
Le tabelle seguenti specificano gli attributi dei dati richiesti e facoltativi per ciascuna classe di asset (applicazioni, infrastruttura, reti e migrazione), l'attività specifica (inventario o business case) e la fedeltà dei dati consigliata per questa fase di valutazione. Le tabelle utilizzano le seguenti abbreviazioni:
+ R, per obbligatorio
+ (D), per il business case direzionale, necessario per confrontare il costo totale di proprietà (TCO) e i business case direzionali
+ (F), per un business case completamente direzionale, necessario per il confronto del TCO e per i casi aziendali direzionali che includono i costi di migrazione e modernizzazione
+ O, per opzione
+ N/A, in quanto non applicabile
**Applicazioni**
| **Nome attributo** | **Descrizione** | **Inventario e definizione delle priorità** | **Caso aziendale** | **Livello di fedeltà consigliato (minimo)** |
| --- |--- |--- |--- |--- |
| Identificatore univoco | Ad esempio, l'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 (D) | 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 (D) | Medio-alta |
| È COTS? | Sì o no. Che si tratti di un'applicazione commerciale o di uno sviluppo interno | R | R (D) | Medio-alta |
| Prodotto e versione COTS | Nome e versione del prodotto software commerciale | R | R (D) | Media |
| Description | Funzione e contesto dell'applicazione principali | R | O | Media |
| Criticità | Ad esempio, un'applicazione strategica o che genera entrate o che supporta una funzione critica | R | O | Medio-alta |
| Tipo | Ad esempio, database, gestione delle relazioni con i clienti (CRM), applicazioni Web, contenuti multimediali, servizi IT condivisi | R | O | Media |
| Ambiente | Ad esempio, produzione, pre-produzione, sviluppo, test, sandbox | R | R (D) | Medio-alta |
| Conformità e regolamentazione | Framework applicabili al carico di lavoro (ad es. HIPAA, SOX, PCI-DSS, ISO, SOC, FedRAMP) e requisiti normativi | R | R (D) | Medio-alta |
| 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) | O | O | Medio-Bassa |
| Mappatura dell'infrastruttura | Mappatura su risorse and/or virtuali fisiche che compongono l'applicazione | O | O | Media |
| Licenza | Tipo di licenza software commodity (ad esempio, Microsoft SQL Server Enterprise) | O | R | Medio-alta |
| Costo | Costi per la licenza software, le operazioni software e la manutenzione | N/D | O | Media |
**Infrastruttura**
| | | | | |
| --- |--- |--- |--- |--- |
| **Nome dell'attributo** | **Descrizione** | **Inventario e definizione delle priorità** | **Caso aziendale** | **Livello di fedeltà consigliato (minimo)** |
| Identificatore univoco | Ad esempio, l'ID del server. In genere disponibile su inventari e sistemi di controllo esistenti CMDBs o 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 | O | Medio-alta |
| Nome DNS (nome di dominio completo o FQDN) | Nome DNS | O | O | Media |
| Indirizzo IP e maschera di rete | and/or Indirizzi IP pubblici interni | R | O | Medio-alta |
| Tipo di asset | Server fisico o virtuale, hypervisor, contenitore, dispositivo, istanza di database, ecc. | R | R | Medio-alta |
| Product name (Nome del prodotto) | Nome del fornitore commerciale e del prodotto (ad esempio, IBM Power VMware ESXi Systems, Exadata) | R | R | Media |
| Sistema operativo | Ad esempio, REHL 8, Windows Server 2019, AIX 6.1 | R | R | Medio-alta |
| Configurazione | CPU allocata, numero di core, thread per core, memoria totale, storage, schede di rete | R | R | Medio-alta |
| Utilizzo | Picco e medio di CPU, memoria e storage. Throughput delle istanze di database. | R | O | Medio-alta |
| Licenza | Tipo di licenza commodity (ad esempio, RHEL Standard) | R | R | Media |
| 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 (D) | Media |
| Mappatura delle applicazioni | Applicazioni o componenti applicativi eseguiti in questa infrastruttura | O | O | Media |
| 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 | O | Medio-alta |
**Reti**
| | | | | |
| --- |--- |--- |--- |--- |
| **Nome dell'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) | O | R | Media |
| Utilizzo del collegamento | Utilizzo medio e massimo, trasferimento dati in uscita (GB/mese) | O | R | Media |
| Latenza (ms) | Latenza attuale tra le postazioni connesse. | O | O | Media |
| Costo | Costo mensile attuale | N/D | O | Media |
**Migrazione**
| | | | | |
| --- |--- |--- |--- |--- |
| **Nome dell'attributo** | **Descrizione** | **Inventario e definizione delle priorità** | **Caso aziendale** | **Livello di fedeltà consigliato (minimo)** |
| Riospitare | Impegno dei clienti e dei partner per ogni carico di lavoro (persona/giorno), costi giornalieri per clienti e partner, costo degli strumenti, numero di carichi di lavoro | N/D | R (F) | Medio-alta |
| Conversione piattaforma | Impegno dei clienti e dei partner per ogni carico di lavoro (persona/giorno), costi giornalieri dei clienti e dei partner, numero di carichi di lavoro | N/D | R (F) | Medio-alta |
| Rifattorizzare | Impegno dei clienti e dei partner per ogni carico di lavoro (persona/giorno), costi giornalieri dei clienti e dei partner, numero di carichi di lavoro | N/D | O | Medio-alta |
| Ritiro | Numero di server, costo medio di smantellamento | N/D | O | Medio-alta |
| Zona di atterraggio | Riutilizzo dell'esistente (Y/N), elenco delle AWS regioni necessarie, costo | N/D | R (F) | Medio-alta |
| Le persone e il cambiamento | Numero di personale da formare nelle operazioni e nello sviluppo del cloud, costo della formazione per persona, costo del tempo di formazione per persona | N/D | R (F) | Medio-alta |
| Durata | Durata della migrazione del carico di lavoro prevista (mesi) | O | R (F) | Medio-alta |
| Costo parallelo | Intervallo di tempo e ritmo con cui è possibile rimuovere i costi così come sono durante la migrazione | N/D | O | Medio-alta |
| Tempi e ritmi di introduzione di AWS prodotti e servizi e altri costi infrastrutturali durante la migrazione | N/D | O | Medio-alta |
## Valutazione della necessità di strumenti di scoperta
La tua organizzazione ha bisogno di strumenti di scoperta? La valutazione del portafoglio richiede up-to-date dati altamente affidabili sulle applicazioni e sull'infrastruttura. Le fasi iniziali della valutazione del portafoglio possono utilizzare ipotesi per colmare le lacune nei dati.
Tuttavia, man mano che si fanno progressi, i dati ad alta fedeltà consentono la creazione di piani di migrazione efficaci e la stima corretta dell'infrastruttura di destinazione per ridurre i costi e massimizzare i vantaggi. Riduce inoltre i rischi abilitando implementazioni che tengono conto delle dipendenze ed evitano le insidie della migrazione. Il caso d'uso principale degli strumenti di discovery nei programmi di migrazione al cloud consiste nel ridurre i rischi e aumentare i livelli di fiducia nei dati attraverso quanto segue:
+ Raccolta di dati automatizzata o programmatica, con conseguente ottenimento di dati convalidati e altamente affidabili
+ Accelerazione della velocità di acquisizione dei dati, miglioramento della velocità del progetto e riduzione dei costi
+ Aumento dei livelli di completezza dei dati, compresi i dati di comunicazione e le dipendenze che in genere non sono disponibili in CMDBs
+ Ottenimento di informazioni quali l'identificazione automatizzata delle applicazioni, l'analisi del TCO, i tassi di esecuzione previsti e i consigli di ottimizzazione
+ Pianificazione delle ondate migratorie ad alta sicurezza
In caso di incertezza sull'esistenza di sistemi in una determinata posizione, la maggior parte degli strumenti di rilevamento è in grado di scansionare le sottoreti di rete e individuare i sistemi che rispondono alle richieste ping o SNMP (Simple Network Management Protocol). Tieni presente che non tutte le configurazioni di rete o di sistema consentiranno il traffico ping o SNMP. Discutete queste opzioni con i vostri team tecnici e di rete.
Le fasi successive della valutazione e della migrazione del portafoglio di applicazioni si basano principalmente su informazioni accurate sulla mappatura delle dipendenze. La mappatura delle dipendenze consente di comprendere l'infrastruttura e la configurazione necessarie AWS (ad esempio gruppi di sicurezza, tipi di istanze, posizionamento degli account e routing di rete). Inoltre, consente di raggruppare le applicazioni che devono spostarsi contemporaneamente (ad esempio le applicazioni che devono comunicare su reti a bassa latenza). Inoltre, la mappatura delle dipendenze fornisce informazioni per l'evoluzione del business case.
Quando si sceglie uno strumento di scoperta, è importante considerare tutte le fasi del processo di valutazione e anticipare i requisiti in materia di dati. Le lacune nei dati possono potenzialmente diventare un ostacolo, quindi è fondamentale prevederle analizzando i requisiti e le fonti di dati futuri. L'esperienza sul campo indica che la maggior parte dei progetti di migrazione in fase di stallo dispone di un set di dati limitato in cui le applicazioni interessate, l'infrastruttura associata e le relative dipendenze non sono chiaramente identificate. Questa mancanza di identificazione può portare a metriche, decisioni e ritardi errati. L'acquisizione di up-to-date dati è il primo passo verso il successo dei progetti di migrazione.
*Come selezionare uno strumento di scoperta?*
Diversi strumenti di scoperta disponibili sul mercato offrono caratteristiche e funzionalità diverse. Considerate le vostre esigenze. E decidi l'opzione più appropriata per la tua organizzazione. I fattori più comuni nella scelta di uno strumento di scoperta per le migrazioni sono i seguenti:
*Sicurezza*
+ Qual è il metodo di autenticazione per accedere all'archivio dei dati dello strumento o ai motori di analisi?
+ Chi può accedere ai dati e quali sono i controlli di sicurezza per accedere allo strumento?
+ In che modo lo strumento raccoglie i dati? Ha bisogno di credenziali dedicate?
+ Di quali credenziali e livello di accesso ha bisogno lo strumento per accedere ai miei sistemi e ottenere dati?
+ Come vengono trasferiti i dati tra i componenti dello strumento?
+ Lo strumento supporta la crittografia dei dati inattivi e in transito?
+ I dati sono centralizzati in un unico componente all'interno o all'esterno del mio ambiente?
+ Quali sono i requisiti di rete e firewall?
Assicurati che i team di sicurezza siano coinvolti nelle prime conversazioni sugli strumenti di scoperta.
*Sovranità dei dati*
+ Dove vengono archiviati ed elaborati i dati?
+ Lo strumento utilizza un modello SaaS (Software as a Service)?
+ Ha la possibilità di conservare tutti i dati entro i limiti del mio ambiente?
+ È possibile esaminare i dati prima che escano dai confini della mia organizzazione?
Considerate le esigenze della vostra organizzazione in termini di requisiti di residenza dei dati.
*Architettura*
+ Quale infrastruttura è richiesta e quali sono i diversi componenti?
+ È disponibile più di un'architettura?
+ Lo strumento supporta l'installazione di componenti in zone di sicurezza chiuse dall'aria?
*Prestazioni*
+ Qual è l'impatto della raccolta dei dati sui miei sistemi?
*Compatibilità e ambito*
+ Lo strumento supporta tutti o la maggior parte dei miei prodotti e versioni? Consulta la documentazione dello strumento per verificare le piattaforme supportate rispetto alle informazioni correnti sull'ambito in uso.
+ La maggior parte dei miei sistemi operativi è supportata per la raccolta dei dati? Se non conosci le versioni del tuo sistema operativo, prova a restringere l'elenco degli strumenti di scoperta a quelli con la più ampia gamma di sistemi supportati.
*Metodi di raccolta*
+ Lo strumento richiede l'installazione di un agente su ogni sistema di destinazione?
+ Supporta implementazioni senza agente?
+ Agent e Agent-Less offrono le stesse funzionalità?
+ Qual è il processo di raccolta?
*Funzionalità*
+ Quali sono le funzionalità disponibili?
+ È in grado di calcolare il costo totale di proprietà (TCO) e la frequenza di Cloud AWS esecuzione stimata?
+ Supporta la pianificazione della migrazione?
+ Misura le prestazioni?
+ Può consigliare l' AWS infrastruttura di destinazione?
+ Esegue la mappatura delle dipendenze?
+ Quale livello di mappatura delle dipendenze fornisce?
+ Fornisce l'accesso alle API? (ad esempio, è possibile accedervi programmaticamente per ottenere dati?)
Prendi in considerazione gli strumenti con potenti funzioni di mappatura delle dipendenze delle applicazioni e dell'infrastruttura e quelli in grado di dedurre le applicazioni dai modelli di comunicazione.
*Costo*
+ Qual è il modello di licenza?
+ Quanto costa la licenza?
+ Il prezzo è riferito a ciascun server? Si tratta di prezzi a più livelli?
+ Esistono opzioni con funzionalità limitate che possono essere concesse in licenza su richiesta?
Gli strumenti Discovery vengono in genere utilizzati durante l'intero ciclo di vita dei progetti di migrazione. Se il tuo budget è limitato, prendi in considerazione almeno 6 mesi. Tuttavia, l'assenza di strumenti di rilevamento comporta in genere un aumento del lavoro manuale e dei costi interni.
*Modello Support*
+ Quali livelli di supporto vengono forniti di default?
+ È disponibile un piano di supporto?
+ Quali sono i tempi di risposta agli incidenti?
*Servizi professionali*
+ Il fornitore offre servizi professionali per analizzare i risultati delle scoperte?
+ Possono coprire gli elementi di questa guida?
+ Sono previsti sconti o pacchetti per i servizi Tooling \$1?
**Suggerimento**
Per trovare e valutare gli strumenti di scoperta, utilizza il sito [Discovery, Planning and](https://aws.amazon.com/prescriptive-guidance/migration-tools/migration-discovery-tools/) Recommendation.
*Funzionalità consigliate per lo strumento di scoperta*
Per evitare il provisioning e la combinazione di dati provenienti da più strumenti nel tempo, uno strumento di rilevamento dovrebbe includere le seguenti funzionalità minime:
+ **Software**: lo strumento di rilevamento dovrebbe essere in grado di identificare i processi in esecuzione e il software installato.
+ **Mappatura delle dipendenze**: dovrebbe essere in grado di raccogliere informazioni sulle connessioni di rete e creare mappe delle dipendenze in entrata e in uscita dei server e delle applicazioni in esecuzione. Inoltre, lo strumento di rilevamento dovrebbe essere in grado di dedurre le applicazioni da gruppi di infrastrutture in base a modelli di comunicazione.
+ **Individuazione del profilo e della configurazione**: dovrebbe essere in grado di riportare il profilo dell'infrastruttura, ad esempio la famiglia di CPU (ad esempio, x86, PowerPC), il numero di core della CPU, le dimensioni della memoria, il numero di dischi e le dimensioni e le interfacce di rete.
+ **Rilevamento dello storage di rete**: dovrebbe essere in grado di rilevare e profilare le condivisioni di rete dai sistemi NAS (Network-Attached Storage).
+ **Prestazioni**: dovrebbe essere in grado di segnalare l'utilizzo medio e massimo di CPU, memoria, disco e rete.
+ **Analisi delle lacune**: dovrebbe essere in grado di fornire informazioni sulla quantità e sulla fedeltà dei dati.
+ **Scansione della rete**: dovrebbe essere in grado di scansionare le sottoreti di rete e scoprire risorse infrastrutturali sconosciute.
+ **Rapporti**: dovrebbe essere in grado di fornire lo stato della raccolta e dell'analisi.
+ **Accesso alle API**: dovrebbe essere in grado di fornire strumenti programmatici per accedere ai dati raccolti.
*Funzionalità aggiuntive da considerare*
+ **Analisi del TCO** per fornire un confronto dei costi tra il costo locale corrente e il costo previsto AWS .
+ **Consigli per l'analisi e l'ottimizzazione delle licenze** per i sistemi Microsoft SQL Server e Oracle in scenari di rehosting e ripiattaforma.
+ **Raccomandazione sulla strategia di migrazione** (lo strumento di rilevamento può fornire consigli di migrazione di tipo R predefiniti in base alla tecnologia attuale?)
+ **Esportazione dell'inventario** (in formato CSV o in un formato simile)
+ **Raccomandazione per il corretto dimensionamento** (ad esempio, può mappare un'infrastruttura di destinazione AWS consigliata?)
+ **Visualizzazione delle dipendenze** (ad esempio, la mappatura delle dipendenze può essere visualizzata in modalità grafica?)
+ **Vista architettonica** (ad esempio, è possibile produrre automaticamente diagrammi architettonici?)
+ Assegnazione **delle priorità alle applicazioni** (può assegnare peso o rilevanza agli attributi dell'applicazione e dell'infrastruttura per creare criteri di prioritizzazione per la migrazione?)
+ **Pianificazione delle ondate** (ad esempio, gruppi di applicazioni consigliati e possibilità di creare piani ondeggianti di migrazione)
+ **Stima dei costi di migrazione (stima** dello sforzo di migrazione)
*Considerazioni sulla distribuzione*
Dopo aver selezionato e acquistato uno strumento di scoperta, ponete le seguenti domande per favorire il dialogo con i team responsabili dell'implementazione dello strumento nella vostra organizzazione:
+ I server o le applicazioni sono gestiti da terze parti? Ciò potrebbe imporre il coinvolgimento dei team e i processi da seguire.
+ Qual è il processo di alto livello per ottenere l'approvazione per l'implementazione degli strumenti di scoperta?
+ Qual è il processo di autenticazione principale per accedere a sistemi come server, container, storage e database? Le credenziali del server sono locali o centralizzate? Qual è la procedura per ottenere le credenziali? Saranno necessarie credenziali per raccogliere dati dai sistemi (ad esempio contenitori, server virtuali o fisici, hypervisor e database). Ottenere le credenziali per consentire allo strumento di rilevamento di connettersi a ciascuna risorsa può essere difficile, soprattutto quando tali risorse non sono centralizzate.
+ Qual è la struttura delle zone di sicurezza della rete? Sono disponibili diagrammi di rete?
+ Qual è la procedura per richiedere le regole del firewall nei data center?
+ Quali sono gli attuali accordi sui livelli di servizio di supporto (SLAs) in relazione alle operazioni del data center (installazione di strumenti di rilevamento, richieste di firewall)?
# Motivi aziendali e principi guida tecnici
## I fattori di business
Indipendentemente dal fatto che la tua organizzazione abbia già deciso di passare al cloud o sia vicina a tale decisione, la definizione e la documentazione dei fattori di business per la migrazione al cloud chiariranno i motivi della migrazione. Dopo aver documentato i motivi, puoi definire cosa verrà migrato e come verrà migrato. Questa attività è importante. Consigliamo che si svolga il più presto possibile per informare e guidare le fasi successive.
Identifica le parti interessate che dovrebbero prendere parte alla discussione per documentare i fattori determinanti. In genere CxOs, i dirigenti senior e i principali leader tecnologici dell'organizzazione e i propri clienti. Sebbene sia improbabile che i vostri clienti prendano parte a questa discussione, consigliamo che una o più persone all'interno dell'organizzazione siano designate per rappresentare i punti di vista e gli obiettivi dei clienti.
I fattori di business devono essere collegati a una metrica che possa essere misurata durante il percorso di migrazione per verificare se i risultati sono stati raggiunti. Gli obiettivi strategici e i report annuali dell'azienda possono fungere da punto di partenza.
Concentra la conversazione su dove l'azienda vuole essere, sulla base delle metriche esistenti e previste, a seguito del passaggio al cloud. Considera gli obiettivi e i risultati aziendali. Inoltre, considera come si presenta il successo con l'aumento dell'adozione del cloud.
Successivamente, stabilisci il livello di importanza per ogni driver. Quali sono le priorità? Quali sono i benefici attesi? In che modo i vantaggi supportano gli obiettivi e i risultati aziendali? Nel contesto della valutazione del portafoglio di applicazioni, le risposte aiuteranno a dare priorità ai carichi di lavoro per la migrazione e a stabilire principi guida tecnici. Tuttavia, i driver aziendali definiranno e influiranno sul programma di migrazione nel suo complesso.
## Principi guida tecnici
I principi guida tecnici informano la selezione della strategia di migrazione nelle fasi successive della valutazione del portafoglio. Nella fase attuale, l'obiettivo è identificarli.
I principi guida possono essere stabiliti come decisioni generali relative alla tecnologia e all'approccio derivate dagli obiettivi e dai risultati aziendali.
Ad esempio, un'azienda ha l'obiettivo principale di ridurre i costi e il risultato desiderato è chiudere un data center locale entro una determinata data tra 6 e 12 mesi. Un principio guida che ne deriva è quello di trasferire e spostare tutte le applicazioni sul cloud utilizzando una strategia di migrazione di rehosting o trasferimento, ove possibile. In questo caso, l' lift-and-shiftapproccio accelera i risultati della migrazione a breve termine. Dopo lo spostamento delle applicazioni dal data center locale, l'azienda può concentrarsi sui principali fattori di business per ottimizzare o modernizzare i carichi di lavoro migrati.
Per stabilire i principi guida tecnici, inizia analizzando i driver aziendali. Identifica un elenco di tecnologie e tecniche che consentiranno di raggiungere gli obiettivi e i risultati aziendali. Quindi, affina l'elenco e assegna un ordine di pertinenza in base all'idoneità o alla preferenza per raggiungere il risultato desiderato.
Documenta e comunica i principi guida con le persone coinvolte nella pianificazione e nell'esecuzione della migrazione. Evidenzia le preoccupazioni e i potenziali conflitti tra i principi e l'effettiva implementazione.
La tabella seguente fornisce un esempio di fattori di business e principi guida tecnici.
| **Motore aziendale** | **Risultato** | **Parametri** | **Principio guida tecnico** |
| --- |--- |--- |--- |
| Accelera l'innovazione. | Migliore competitività, maggiore agilità aziendale | Numero di implementazioni al giorno o al mese, nuove funzionalità rilasciate ogni trimestre, punteggi di soddisfazione dei clienti, numero di esperimenti | Rifattorizza le applicazioni differenziando le applicazioni utilizzando i microservizi e il modello DevOps operativo per aumentare l'agilità e la velocità di immissione sul mercato delle nuove funzionalità. |
| Riduci i costi operativi e di infrastruttura. | Base di costi elastica e abbinata a domanda e offerta (paghi in base all'uso) | Variazione della spesa nel tempo | 1. Riorganizza le applicazioni con l'infrastruttura dimensionata correttamente. 2. Ritira le applicazioni che hanno un utilizzo scarso o nullo. |
| Aumenta la resilienza operativa. | Migliore operatività, riduzione del tempo medio di ripristino | SLAs, numero di incidenti | 1. Ripiattaforma le applicazioni alle versioni più recenti e meglio supportate del sistema operativo. 2. Implementa architetture ad alta disponibilità per applicazioni critiche. |
| Esci dal data center. | Chiusura del data center entro una data compresa tra 6 e 12 mesi | Velocità delle migrazioni dei server | Riospita le applicazioni utilizzando la soluzione Cloud Migration Factory. |
| Rimani in locale, ma aumenta l'agilità e la resilienza. | Competitività e operatività migliorate pur rimanendo in sede | Numero di implementazioni al giorno o al mese, rilascio di nuove funzionalità ogni trimestre SLAs, numero di incidenti | 1. Modernizza i sistemi estendendone le funzionalità nel cloud.2. Valuta l'opportunità di rehosting o replatforming to. AWS Outposts |
# Avvio della raccolta dei dati
La raccolta dei dati è il processo di raccolta dei metadati dalle applicazioni e dall'infrastruttura. Il processo è iterativo in tutte le fasi della valutazione. In ogni fase, la quantità e la fedeltà dei dati aumenteranno. In questa fase, l'attenzione si concentra sulla raccolta di dati generali che possano aiutare a stabilire un inventario iniziale. L'inventario verrà utilizzato per creare un business case direzionale e per identificare i candidati iniziali alla migrazione.
Dopo aver identificato le attuali fonti di dati, consigliamo di raccogliere informazioni dal maggior numero possibile di sistemi. Per ulteriori informazioni, consulta i [requisiti in materia di dati](understanding-initial-assessment-data-requirements.md) per questa fase.
Questo approccio ha il vantaggio di contribuire ad aggiornare l'attuale visione del portafoglio e la conoscenza delle applicazioni e dei servizi da parte dell'organizzazione. Inoltre aiuta a determinare cosa si intende spostare. L'approccio consigliato consiste nell'esaminare i dati esistenti, come gli output del database di gestione della configurazione (CMDB) e i sistemi di gestione dei servizi di tecnologia dell'informazione (ITSM). Quindi crea un elenco di risorse destinate alla raccolta dei dati. Se l'organizzazione è completamente chiara su ciò che rientra nell'ambito e ciò che non rientra nell'ambito della migrazione, è possibile limitare la raccolta dei dati ai sistemi che rientrano nell'ambito di applicazione.
Quando create il vostro portafoglio, prendete in considerazione le applicazioni e i relativi ambienti o i cicli di vita delle release del software. Ad esempio, invece di identificare un'applicazione di gestione delle relazioni con i clienti (CRM) e specificare che disponga di ambienti di test, sviluppo e produzione, elenca tre applicazioni (ad esempio CRM-Test, CRM-Dev, CRM-Prod). In alternativa, utilizza il nome CRM ma assegna un ID univoco a ciascun ambiente e presentalo come record separati nel tuo repository di dati. Ciò contribuirà a pianificare e tracciare la migrazione di questi ambienti singolarmente. Ad esempio, potresti voler migrare prima gli ambienti non di produzione. Elencando le istanze dell'applicazione in base all'ambiente, è possibile gestire e governare in modo chiaro la loro transizione.
Durante la raccolta dei dati, potrebbe esserci incertezza su quali applicazioni o server si trovino in un determinato data center o in una determinata posizione di origine. In questi casi, è utile ottenere elenchi bare-metal e di hypervisor dagli strumenti di gestione esistenti. Ad esempio, è possibile connettersi a un hypervisor per ottenere elenchi di macchine virtuali da utilizzare come target per la raccolta dei dati.
Si noti che l'output iniziale, quando si combinano fonti di dati esistenti, potrebbe essere incompleto. La chiave è eseguire un'analisi delle lacune in termini di [requisiti di dati](understanding-initial-assessment-data-requirements.md) per questa fase e di cosa si può ottenere dalle fonti esistenti. È importante confrontare la percentuale di completezza con il livello di fedeltà dei dati. I livelli di completezza più elevati derivanti da fonti a bassa fedeltà conterranno diverse ipotesi che potrebbero portare a analisi errate. Sebbene questa fase di valutazione non richieda la massima fedeltà dei dati, consigliamo che le fonti di dati abbiano una fedeltà almeno medio-medio-alta. Confrontate questi numeri con la tolleranza al rischio della vostra organizzazione, incluso l'uso di ipotesi per colmare le lacune nei dati.
L'analisi delle lacune ti aiuta a comprendere la quantità e la qualità dei dati con cui stai lavorando. L'analisi aiuta anche a stabilire il livello di ipotesi da formulare per creare un business case direzionale e dare priorità alle applicazioni da migrare. Gli strumenti Discovery possono aiutare a colmare le lacune e raccogliere dati ad alta fedeltà. Per aumentare i livelli di fiducia nei dati e accelerare i risultati della migrazione, consigliamo di implementare gli strumenti di rilevamento il prima possibile. Un'azione tempestiva è importante anche perché i processi interni di approvvigionamento, sicurezza e implementazione di nuovi strumenti potrebbero richiedere diverse settimane o mesi per essere completati.
In questa fase consigliamo di stabilire un piano o una cadenza di comunicazione e un meccanismo di controllo del cambio di ambito. Questo ti aiuta a tenere informate le parti interessate in modo che possano pianificare in anticipo e mitigare i rischi. Un elemento chiave per comunicazioni chiare è definire un'unica fonte di verità per il portafoglio di applicazioni e l'infrastruttura associata. Evita di tenere più sistemi di registrazione ed elenchi di applicazioni e infrastrutture. Conserva i dati in un unico posto (ad esempio un database, uno strumento o un foglio di calcolo) che supporti il controllo delle versioni e la collaborazione online e assegna loro un proprietario.
# Strategia di prioritizzazione e migrazione
Un elemento chiave della pianificazione della migrazione consiste nello stabilire criteri di prioritizzazione. Lo scopo di questo esercizio è comprendere l'ordine in cui le applicazioni verranno migrate. La strategia consiste nell'adottare un approccio iterativo e progressivo per far evolvere il modello di prioritizzazione.
## Assegnazione di priorità alle applicazioni
Questa fase di valutazione si concentra sulla definizione di criteri iniziali per dare priorità ai carichi di lavoro a basso rischio e bassa complessità. Questi carichi di lavoro sono ottimi candidati per applicazioni pilota. L'utilizzo di carichi di lavoro a basso rischio e bassa complessità nelle migrazioni iniziali riduce il rischio e offre ai team l'opportunità di acquisire esperienza. Questi criteri verranno evoluti in ulteriori fasi di valutazione per allineare la prioritizzazione ai fattori di business durante la creazione del piano di migrazione.
I criteri iniziali dovrebbero dare la priorità alle applicazioni con un numero limitato di dipendenze, eseguite in un'infrastruttura supportata dal cloud e da ambienti non di produzione. Un esempio potrebbero essere le applicazioni con 0—3 dipendenze pronte per il rehosting così come sono in un ambiente di sviluppo o di test. Questi criteri sono validi per definire le applicazioni pilota e potenzialmente la prima e la seconda ondata di migrazione, a seconda del livello di maturità e dei livelli di confidenza nell'adozione del cloud.
*Decidere quali criteri iniziali utilizzare*
Seleziona da 2 a 10 punti dati da utilizzare per dare priorità ai primi carichi di lavoro. [Questi punti dati provengono dall'inventario iniziale delle applicazioni e dell'infrastruttura (consulta la sezione sulla raccolta dei dati).](initiating-data-collection.md)
Successivamente, definisci un punteggio, o peso, per ogni valore possibile di ogni punto dati. Ad esempio, se è selezionato l'attributo environment e i valori possibili sono production, development e test, a ogni valore viene assegnato un punteggio, un numero maggiore che rappresenta una priorità più alta. Sebbene sia facoltativo, consigliamo di assegnare un fattore moltiplicatore per l'importanza o la pertinenza a ciascun punto dati. Questo passaggio facoltativo fornisce un elemento di differenziazione di livello superiore per enfatizzare ciò che è più importante, il che aiuta a mantenere allineati i criteri mentre si procede nell'assegnazione dei punteggi ai valori.
In base alla strategia di dare priorità alle applicazioni semplici e a basso rischio per le prime ondate di migrazione, la tabella seguente mostra esempi di selezione degli attributi e le relative assegnazioni di valore.
| **Attributo (punto dati)** | **Valori possibili** | **Punteggio (0-99)** | **Fattore moltiplicatore di importanza o pertinenza** |
| --- |--- |--- |--- |
| Ambiente | Test | 60 | Alto (1x) |
| Sviluppo | 40 |
| Produzione | 20 |
| Criticità aziendale | Bassa | 60 | Alto (1x) |
| Media | 40 |
| Elevata | 20 |
| Quadro normativo o di conformità | Nessuno | 60 | Alto (1x) |
| FedRAMP | 10 |
| Supporto del sistema operativo | Pronto per il cloud | 60 | Medio-alto (0,8x) |
| Non supportato nel cloud | 10 |
| Numero di istanze di elaborazione | 1-3 | 60 | Medio-alto (0,8x) |
| 4-10 | 40 |
| 11 o più | 20 |
| Strategia di migrazione | Riospitare | 70 | Medio (0,6 x) |
| Conversione piattaforma | 30 |
| Rifattorizza o riprogetta | 10 |
Assicurati di selezionare attributi che possano fungere da fattori chiave di differenziazione tra le applicazioni. In caso contrario, i criteri faranno sì che molti carichi di lavoro condividano la stessa priorità. Dopo aver applicato il modello, ti consigliamo di esaminare la parte superiore e inferiore della classifica risultante per vedere se sei d'accordo. Se in generale non sei d'accordo, puoi rivedere i criteri utilizzati per assegnare un punteggio ai carichi di lavoro.
Dopo aver ottenuto una classifica, esamina la distribuzione dei punteggi nell'intero portafoglio. I punteggi in sé non contano. È la differenza tra i punteggi che conta. Ad esempio, potresti scoprire che il punteggio totale più alto è 8.000 e il punteggio più basso è 800. Prendi in considerazione la possibilità di tracciare i punteggi risultanti sotto forma di istogramma, in modo da verificare di avere una buona distribuzione. La distribuzione ideale assomiglia a una curva a campana standard, con pochi carichi di lavoro ad altissima priorità e alcuni carichi di lavoro a priorità molto bassa. La maggior parte delle applicazioni si troverà da qualche parte nel mezzo.
Un altro aspetto fondamentale della prioritizzazione iniziale consiste nell'includere team interni o unità aziendali che mostrano interesse a diventare i primi ad adottare il cloud. Queste potrebbero essere una leva importante per ottenere supporto aziendale per la migrazione di una determinata applicazione, soprattutto nei primi giorni. Se questo è il caso della vostra organizzazione, includete l'attributo dell'unità di business nella tabella precedente. Assegnate un punteggio elevato alle unità aziendali disposte a presentare le proprie candidature. L'utilizzo dell'attributo business unit contribuirà a portare tali applicazioni in cima all'elenco.
Dopo aver accettato la classifica risultante, seleziona le prime 5-10 applicazioni. Questi saranno i candidati iniziali per la migrazione delle candidature. Perfeziona l'elenco in modo da confermare 3-5 candidature. Ciò consente di adottare un approccio mirato durante l'esecuzione di una valutazione dettagliata delle applicazioni. Per ulteriori informazioni, consulta Valutazione [prioritaria delle applicazioni](prioritized-applications-assessment.md).
## Determinazione del tipo R per la migrazione
La scelta di una strategia di migrazione per ogni applicazione e infrastruttura associata avrà implicazioni sulla velocità, sui costi e sul livello di vantaggi della migrazione. È fondamentale determinare la strategia sulla base di una combinazione equilibrata di fattori, tra cui fattori di business, principi guida tecnici, criteri di prioritizzazione e strategia aziendale.
A volte questi fattori creano opinioni contrastanti. Ad esempio, il motore principale della migrazione potrebbe essere l'innovazione e l'agilità. Allo stesso tempo, potrebbe essere necessario ridurre rapidamente i costi. La modernizzazione mirata di tutte le applicazioni ridurrà i costi a lungo termine, ma richiederà un investimento iniziale maggiore. In tal caso, un approccio consiste nel migrare le applicazioni utilizzando strategie che richiedano meno sforzi, come il rehosting o la ripiattaforma. Ciò può garantire una rapida efficienza e una riduzione dei costi a breve termine. Quindi reinvestite i risparmi nella modernizzazione dell'applicazione in una fase successiva e ottenete un'ulteriore riduzione dei costi.
Tuttavia, iniziare con un rehosting completo di tutte le applicazioni ritarda i maggiori vantaggi della modernizzazione. La chiave è trovare un equilibrio tra le strategie di migrazione in modo che le applicazioni strategiche aziendali abbiano la priorità per la modernizzazione, mentre le altre applicazioni possano essere riospitate o riorganizzate prima sulla piattaforma e poi modernizzate.
*Come determinare una strategia di migrazione per le applicazioni?*
In questa fase di valutazione, l'obiettivo è incorporare un modello iniziale per guidare la selezione della strategia di migrazione. Per convalidare la strategia di migrazione per le applicazioni iniziali, utilizzate il modello insieme ai fattori di business e ai criteri di prioritizzazione. La logica predefinita dell'albero decisionale vi aiuterà a determinare il trattamento iniziale per l'ambito. Nell'albero, gli approcci più complessi, come refactor o re-architect, sono riservati ai carichi di lavoro strategici.
![\[Il processo decisionale 6 R discusso in questa guida.\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/application-portfolio-assessment-guide/images/6Rs-DecisionTree-baseModel.png)
*[Una versione [draw.io](https://github.com/jgraph/drawio-desktop/releases) personalizzabile di questo diagramma è disponibile nella sezione Allegati.](#attachments)*
Il primo passaggio verso un modello iniziale consiste nell'aggiornare i driver aziendali nella parte superiore dell'albero con quelli definiti dall'organizzazione. Successivamente, applica l'albero ai componenti dell'applicazione anziché alle applicazioni nel loro insieme. Ad esempio, nel caso di un'applicazione a tre livelli con tre componenti (front-end, livello applicativo e database), ogni componente deve transitare nell'albero in modo indipendente e ricevere una strategia e un modello specifici. Questo perché in alcuni casi potresti voler riospitare o ripiattaforma un determinato livello e rifattorizzare (riprogettare) altri livelli.
L'assegnazione indipendente dei componenti vi porterà a definire una strategia di migrazione per l'infrastruttura associata. La strategia di infrastruttura potrebbe essere la stessa strategia del componente applicativo supportato o potrebbe essere diversa. Ad esempio, un componente applicativo che verrà riorganizzato in una nuova macchina virtuale con un sistema operativo più recente seguirà la strategia di ripiattaforma mentre la macchina virtuale corrente che lo ospita verrà ritirata. La strategia di migrazione per l'infrastruttura viene calcolata in base alla strategia scelta per i componenti dell'applicazione.
Prima di utilizzare l'albero decisionale per stabilire le strategie di migrazione, verifica la logica con alcune applicazioni e verifica se generalmente sei d'accordo con il risultato. L'albero decisionale delle 6 R è una guida che non sostituisce l'analisi necessaria per determinarne la correttezza. La logica ad albero potrebbe non essere applicabile a casi particolari. Tratta questi casi come eccezioni e procedi a sovrascrivere la decisione guidata dall'albero documentando la logica alla base dell'override anziché modificando la logica dell'albero. In questo modo si evitano versioni multiple dell'albero decisionale, che potrebbero diventare difficili da gestire. Le indicazioni generali indicano che l'albero deve essere valido per almeno il 70-80 percento dei carichi di lavoro. Per il resto ci saranno delle eccezioni. Qualsiasi modifica alla logica dell'albero, in questa fase della valutazione, dovrebbe concentrarsi sulla definizione di un modello iniziale. Ulteriori iterazioni e perfezionamenti avverranno nelle fasi successive, come l'[analisi del portafoglio e](portfolio-analysis-migration-planning.md) la pianificazione della migrazione.
## Allegati
[attachment.zip](samples/attachment.zip)
# Creazione di un business case direzionale
Le parti interessate di tutta l'azienda dovrebbero comprendere e accettare il business case per la trasformazione in ogni fase del percorso.
Nelle fasi iniziali, è importante mostrare rapidamente un valore potenziale sufficiente di un programma di migrazione, in modo da poter disporre delle risorse necessarie per pianificare e stabilire il programma. Il business case direzionale è progettato per fornire una ragionevole certezza nel raggiungimento di un valore aziendale convincente con i dati limitati che possono essere raccolti in anticipo.
Una volta stabilito il programma, il business case viene ulteriormente sviluppato. Il caso dettagliato fornisce una maggiore precisione, un quadro più completo del valore del programma e informazioni sulle priorità di pianificazione. Definisce e quantifica i risultati aziendali pianificati a cui l'organizzazione partecipa e stabilisce la linea di base rispetto alla quale l'ufficio di governance del programma può quindi indirizzare il programma e misurarne i risultati.
## Definizione dell'ambito del business case direzionale
Un business case direzionale viene in genere assemblato rapidamente, entro 2-4 settimane. Deve generare sufficiente fiducia in modo da poter garantire le risorse necessarie per costituire il team principale, coinvolgere AWS i partner se necessario e, come minimo, completare le fasi [prioritarie di valutazione delle applicazioni, [analisi del portafoglio](portfolio-analysis-migration-planning.md) e pianificazione della](prioritized-applications-assessment.md) migrazione.
In genere, i business case direzionali che supportano le migrazioni del portafoglio vengono creati in uno dei seguenti modi:
+ Un semplice**** confronto *del costo totale di proprietà (TCO)* tra il panorama dell'infrastruttura as-is e l'architettura post-migrazione. Servizio AWS Il confronto mostra la differenza nelle frequenze di esecuzione previste per determinati volumi di carico di lavoro.
+ Un business case**** che mostra il valore attuale netto (NPV), l'utile sul capitale investito (ROI), il periodo di ammortamento, il tasso di rendimento interno modificato (MIRR) e le analisi del flusso di cassa a 3-5 anni per la migrazione, comprensivi dei costi di migrazione rispetto al mantenimento dello stato attuale. AWS
L'ambito direzionale del business case è in genere limitato a uno dei seguenti:
+ Un confronto tra i costi della tecnologia dell'infrastruttura
+ Un confronto tra la tecnologia dell'infrastruttura e i costi operativi
In generale, quanto più ampio è il portafoglio, tanto meno sviluppato deve essere il caso. Questo perché è possibile formulare ipotesi più ampie senza influire in modo significativo sul risultato. Per un portafoglio più piccolo, qualsiasi modifica avrà un impatto maggiore, quindi sono necessari maggiori dettagli.
Inizia costruendo il confronto dei costi dell'infrastruttura di base. Quindi decidi se il confronto è sufficientemente convincente prima di continuare. In genere, i portafogli con più di 400 server mostrano un business case promettente solo per quanto riguarda la riduzione dei costi dell'infrastruttura entro 3 anni dall'operatività AWS, oppure 250 server entro 5 anni, anche se questo dato può variare. Per portafogli più piccoli, potrebbero essere necessari maggiori dettagli.
Al contrario, in questa fase è raramente utile esaminare altre componenti del valore aziendale, ad esempio il valore derivante da una maggiore resilienza o agilità aziendale, a meno che l'ambito di migrazione totale non sia inferiore a circa 5 carichi di lavoro o 50 server.
## Concentrarsi sui fattori di valore
Il confronto del TCO relativo alla tecnologia dell'infrastruttura confronta un modello dei costi dell'infrastruttura così com'è con un modello base della Servizio AWS distinta base necessaria per eseguire i carichi di lavoro con prestazioni e disponibilità equivalenti. È possibile eseguire molte ottimizzazioni. In questa fase, tuttavia, l'attenzione si concentra sull'elenco seguente perché sono più facili da valutare e in genere consentono di risparmiare circa il 30% sul TCO, il che è sufficiente per andare avanti:
+ **Elasticità di calcolo**: mappa i server il cui utilizzo non è al 100%, come i server di sviluppo o UAT che eseguono 8x5 (24% di utilizzo), 10x5 (30%) o 10x6 (36%) e i server di disaster recovery (DR) che funzionano al 2%, ai servizi on demand che vengono fatturati solo quando utilizzati.
+ **Approvvigionamento con un piano di risparmio**: pianifica l'acquisto di server di produzione e altri server con un utilizzo elevato (superiore al 36 percento) con un piano di risparmio adeguato per ridurre i costi fino al 75 percento. Le opzioni includono impegni di 1 o 3 anni, con diversi livelli di pagamenti anticipati per garantire sconti maggiori.
+ **Rimuovi gli zombi**: identifica i server con un utilizzo della CPU inferiore al 2% che puoi confermare non sono più necessari e rimuovili dall'analisi dei costi.
+ **Calcolo del giusto dimensionamento**: utilizza i dati delle serie temporali di utilizzo della CPU e della memoria per valutare, per ciascun server, la potenza di elaborazione e la memoria necessarie. Quindi seleziona l'istanza Amazon Elastic Compute Cloud (Amazon EC2) adatta.
+ **Dimensionamento corretto della licenza del sistema di gestione di database relazionali (RDBMS): rivaluta le tue esigenze di licenza** RDBMS dopo aver calcolato il corretto dimensionamento sui tuoi server di database, confronta la licenza Bring Your Own License (BYOL) e la licenza Procuring di ed esplora il AWS potenziale di Amazon Relational Database Service (Amazon RDS) per aumentare i risparmi.
+ **Storage**: dimensiona correttamente il volume di storage totale necessario e identifica le esigenze di input/output operazioni al secondo (IOPS) in tutto il portafoglio. Determina quanto può essere spostato nello storage a oggetti con diversi costi SLAs .
## Esigenze relative
La tabella in [Comprensione dei requisiti relativi ai dati di valutazione iniziale](understanding-initial-assessment-data-requirements.md) mostra i dati necessari per creare ogni parte di un business case direzionale e se sono obbligatori o facoltativi.
Per creare il caso, è necessario il sottoinsieme infrastrutturale dei dati di pianificazione iniziale più i dati sui costi. Determinare come identificare l'infrastruttura da includere dipende dall'obiettivo aziendale:
+ Se l'obiettivo del programma è migrare e modernizzare applicazioni specifiche, create il portafoglio di infrastrutture in base alle esigenze delle applicazioni, prendendo in considerazione l'infrastruttura condivisa.
+ Se l'obiettivo del programma è incentrato sull'infrastruttura, ad esempio la migrazione da un data center il cui contratto di locazione sta per scadere, la mappatura delle applicazioni non è necessaria per confrontare il TCO dell'infrastruttura.
I dati contrassegnati come opzionali (come l'utilizzo massimo della CPU e della memoria per i server) in genere possono essere sostituiti con valori di benchmark standard. Puoi discuterne con un AWS partner o con un servizio AWS professionale. Oppure puoi estrapolare i valori dai punti dati disponibili in una parte del tuo portafoglio (come i dati raccolti da un hypervisor). Più grande è il portafoglio, più accurato è.
## Confronti del TCO dell'infrastruttura degli edifici
Gli strumenti sono fondamentali per creare confronti tra il TCO dell'infrastruttura. [AWS Professional Services](https://aws.amazon.com/professional-services/) o un [AWS partner](https://aws.amazon.com/migration/partner-solutions/) possono fornire assistenza per tutti i tipi di casi direzionali, soprattutto se si prevede di coinvolgerli per fornire assistenza nel più ampio processo di migrazione.
Sono disponibili strumenti per eseguire le seguenti operazioni:
+ Raccogli dati di inventario.
+ Raccogli dati di utilizzo.
+ Fornisci dati accurati di benchmarking dei costi dell'infrastruttura così come sono.
+ Identifica e rimuovi gli zombi.
+ Effettua valutazioni delle dimensioni corrette.
+ Consiglia le opzioni di acquisto.
+ Confronta le opzioni di licenza software.
+ Produci semplici analisi grafiche del flusso di cassa.
[Migration Evaluator from](https://aws.amazon.com/migration-evaluator/) è un'opzione. AWS Fornisce tutte queste funzionalità come **servizio gestito gratuito. Puoi** richiedere Migration Evaluator tramite il tuo AWS account manager o AWS Migration Competency Partner o inviando [una](https://pages.awscloud.com/Migration-Evaluator-request.html) richiesta online. Migration Evaluator è stato progettato specificamente come soluzione mirata per confrontare rapidamente il TCO della tecnologia dell'infrastruttura.
Principali vantaggi:
+ Gratuito
+ Rilevamento senza agente o configurazione manuale dei dati di inventario laddove l'individuazione basata su strumenti è limitata
+ Supporto dedicato per facilitare l'implementazione, la configurazione, la raccolta dei dati e la creazione del business case base o direzionale
+ Comodità del funzionamento SaaS, ma può eseguire la raccolta dei dati interamente all'interno della rete del cliente per supportare la pulizia prima del caricamento nel motore di analisi
+ Forte supporto per il corretto dimensionamento delle licenze Microsoft
+ Funzionalità complete di esportazione dei dati
Limitazioni principali:
+ Valuta solo i server con architettura x86 (Windows e Linux)
+ Opzioni limitate per configurare o calibrare i dati di costo del benchmark così come sono
+ Nessun supporto per l'ottimizzazione dei costi delle operazioni di modellazione
+ Nessun supporto per la modellazione dei costi di migrazione
+ Nessun supporto diretto per la creazione di casi aziendali oltre al confronto del TCO
Se si decide di utilizzare uno strumento di scoperta commerciale per le funzionalità di scoperta e analisi del portafoglio, come lo stack di applicazioni e l'individuazione dell'interdipendenza, di solito fornisce anche un confronto del TCO dell'infrastruttura. Per indicazioni sull'uso degli strumenti per l'individuazione e la valutazione del portafoglio, consulta [Evaluating the](understanding-initial-assessment-data-requirements.md#discovery-tooling) need for discovery tooling. Per esaminare e confrontare le funzionalità chiave degli strumenti leader di mercato, consulta gli strumenti di migrazione [Discovery, Planning e](https://aws.amazon.com/prescriptive-guidance/migration-tools/migration-discovery-tools/) Recommendation.
## Integrare l'ottimizzazione dei costi operativi
Il miglioramento della produttività delle operazioni IT è spesso un importante fattore di valore per le migrazioni. In media, dopo la migrazione verso AWS, la produttività del personale operativo IT aumenta del 62% grazie alla migrazione, secondo il white paper di International Data Corporation (IDC) [Fostering Business and Organizational Transformation to Generate Business Value with Amazon Web Services](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770). Tuttavia, ci sono due sfide legate al dimensionamento e all'inclusione di questi vantaggi nel caso direzionale.
[Innanzitutto, la valutazione dell'intera gamma di incrementi di produttività richiede un'ampia raccolta di dati ed è più appropriata per un business case dettagliato.](detailed-business-case.md) Questa sfida può essere risolta concentrandosi su alcuni elementi che possono essere valutati e dimensionati più facilmente con semplici dati di benchmark, ma che mostrano comunque vantaggi significativi.
In secondo luogo, concentrarsi sulla produttività come fonte di riduzione dei costi può generare preoccupazioni e negatività tra i principali stakeholder dei clienti e i membri del programma. Assicuratevi di fornire informazioni chiare su come verrà realizzato il vantaggio e su cosa ciò significhi per le persone coinvolte. Tali problemi possono essere evitati chiarendo che ciò non farà che migliorare i ruoli del team:
+ Il programma di migrazione include un percorso per sviluppare e trasferire il personale operativo interno verso nuovi ruoli, ad esempio unirsi DevSecOps ai team per la creazione di infrastrutture come l'automazione del codice e le automazioni di test che favoriranno la crescita del team.
+ Il vantaggio può essere realizzato ridefinendo e ridimensionando i contratti di outsourcing delle operazioni, in modo che il personale interno possa concentrarsi maggiormente su attività di maggior valore
Approcciatevi alla costruzione di questo elemento del business case sulla base delle trasformazioni operative da prendere in considerazione:
+ Se disponi già di un team operativo interno, migliora le competenze dei membri del team e mostra il miglioramento della produttività previsto.
+ In alternativa, passa dalla tua attuale soluzione operativa a AWS Managed Services (AMS) o a un'offerta alternativa di servizi gestiti di un partner. AWS
Per la prima trasformazione, per ottenere una stima finanziaria prudente del miglioramento della produttività che può essere incluso nel caso, consigliamo quanto segue:
1. Concentratevi in particolare sulla produttività delle operazioni di gestione dei server. Tende a rappresentare una parte significativa dello sforzo operativo, può essere valutata più facilmente e può essere verificata più facilmente in un secondo momento.
1. Calcola il personale necessario in base ai benchmark relativi al numero di server che possono essere gestiti da ogni dipendente equivalente a tempo pieno (FTE). In sede, tale numero è di circa 150 server. No AWS, si tratta di circa 400 server.
1. Applica queste metriche al numero di server locali rispetto al numero di istanze EC2.
1. Moltiplica il tempo risparmiato con un tasso di costo misto per l'intero team operativo.
Puoi quindi verificare i risultati con entrambi gli approcci verificando che il risultato non superi di molto gli incrementi di produttività medi per ruolo forniti nella tabella seguente (dati tratti dal white paper IDC [Fostering Business and Organizational Transformation to Generate Business Value](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770) with Amazon Web Services).
| **Ruolo** | **Aumento di efficienza** |
| --- |--- |
| Gestione dell'infrastruttura IT | 62% |
| Supporto IT | 59% |
| Gestione delle applicazioni | 43% |
| Gestione del database | 19% |
| Sviluppo di applicazioni | 25% |
Per la seconda trasformazione, è possibile aggiungere i risparmi sui costi operativi confrontando direttamente gli attuali costi totali di operazioni e supporto per il portafoglio in questione con il costo del servizio gestito considerato.
Per ottenere il costo del servizio gestito, fornite al vostro AWS account manager o a qualsiasi [AWS Managed Services partner](https://aws.amazon.com/managed-services/partners/) la AWS distinta base proposta, la scelta del livello di servizio (Plus o Premium) e il pacchetto AMS (AMS Accelerate o AMS Advanced). Ciò vi fornirà un costo totale dei servizi gestiti per i:Servizio AWS componenti della soluzione trasformata. Analogamente, è possibile ottenere i prezzi da un AWS partner che offre il proprio pacchetto di servizi gestiti basato su parametri propri.
## Espansione verso un business case completamente direzionale
In generale, per creare un business case completo, è necessario creare il confronto del TCO, con o senza l'elemento relativo alla produttività IT, e stimare tutti i costi di migrazione e modernizzazione. Quindi crea un flusso di cassa che copra due scenari diversi. migrate-and-modernize t-migrate-and-modernize
Il caso più semplice è la preparazione di una singola coppia di scenari, in cui lo t-migrate-and-modernize scenario da non fare è la situazione attuale e migrate-and-modernize lo scenario presenta le seguenti caratteristiche:
+ Nessuna crescita o riduzione del volume transazionale, della capacità di calcolo o della capacità di rete
+ Crescita costante a basso volume dei requisiti di storage
+ Quality-of-service funzionalità (quali disponibilità, durata, velocità effettiva e prestazioni) corrispondenti alle funzionalità del sistema esistente
Per tutti i portafogli tranne quelli molto piccoli, ciò si adatta bene all'obiettivo di creare un case direzionale. Dimostra un valore sufficiente in tempi rapidi per ottenere il mandato di andare avanti.
Per i portafogli più piccoli, può essere utile aggiungere coppie di t-migrate-and-modernize scenari migrate-and-modernize e non, che dimostrino altri aspetti del maggiore valore della migrazione al cloud, come ad esempio:
+ Una combinazione di requisiti di crescita moderati e ad alta capacità per tutti i carichi di lavoro in cui è prevista tale crescita
+ Inclusione di una maggiore resilienza, come l'alta disponibilità, il DR e la tolleranza agli errori
+ Prestazioni globali migliorate con edge computing, rete per la distribuzione dei contenuti (CDN) e replica di database in più regioni.
+ Qualsiasi altro miglioramento specifico della qualità del servizio che hai considerato prioritario per il programma
Per questi scenari, assicurati che i costi e le implicazioni sul flusso di cassa dell'aggiornamento dell'attuale architettura dell'infrastruttura non cloud per soddisfare le nuove specifiche siano stimati con precisione. Il modo più diretto per ottenere questa stima può essere richiedere un preventivo a un integratore di sistemi, soprattutto se è anche un partner di AWS consulenza con Migration Competency, che può supportarti in entrambi gli scenari. migrate-and-modernize t-migrate-and-modernize
Per ogni coppia di scenari, assemblate una custodia contenente quanto segue:
+ I costi dello scenario da non fare. t-migrate-and-modernize Nel caso più semplice, ciò include:
+ Il costo totale di proprietà nel periodo di validità del business case per l'attuale configurazione dell'infrastruttura
+ Aumenti periodici del consumo di elaborazione, storage e traffico di rete
+ I costi dello scenario migrate-and-modernize, tra cui:
+ Impostazione del programma, che include l'individuazione dettagliata, la pianificazione della migrazione, lo sviluppo dettagliato dei business case, la creazione del core team e il suo miglioramento delle competenze, l'istituzione di una landing zone se non è già presente e la definizione della gestione della sicurezza e dell'integrazione delle operazioni per i carichi di lavoro migrati
+ Costi di migrazione e modernizzazione dei carichi di lavoro
+ I costi dell'infrastruttura di migrazione, comprese le connessioni di rete, i servizi di migrazione dei dati come [AWS Snowball Edge](https://aws.amazon.com/snowball/)e [AWS DataSync](https://aws.amazon.com/datasync/)e i costi delle AWS utenze per l'architettura necessaria durante il processo di migrazione stesso (ad esempio, per i test)
+ L'aumento dei costi delle AWS utenze nel corso della migrazione man mano che le ondate si fanno sentire e la riduzione dei costi dell'infrastruttura esistente man mano che questa viene sostituita da servizi basati su servizi AWS basati e dismessa
+ I costi di smantellamento e le cancellazioni di eventuali asset non recuperati
## Stima della configurazione del programma di migrazione e modernizzazione
Per impostare con successo un programma, potrebbe essere necessario eseguire una serie di attività di base per sviluppare le funzionalità di base e il piano dettagliato, se ciò non è mai stato fatto prima. Queste attività fondamentali includono quanto segue:
1. Esecuzione dell'individuazione dettagliata del portafoglio, della pianificazione della migrazione e dello sviluppo dettagliato dei business case, come descritto nella sezione [Analisi del portafoglio e pianificazione della migrazione](portfolio-analysis-migration-planning.md), oltre alla documentazione del costo degli strumenti di scoperta utilizzati.
1. Creazione di un core team tecnico e aziendale basato sul cloud e sviluppo di competenze interne attraverso la formazione e l'assunzione. Identifica i membri dell'organizzazione IT che avranno bisogno di formazione e assegna un budget di formazione per ogni persona.
1. Stabilire una [landing zone](https://aws.amazon.com/solutions/implementations/aws-landing-zone/) e configurarla per supportare le funzionalità di governance dei costi, operative e della sicurezza necessarie.
AWS I partner di consulenza possono contribuire a fornire stime per gli articoli 1 e 3.
*Stima dei costi di migrazione e modernizzazione*
Per raggiungere gli obiettivi di un business case direzionale e dimostrare il potenziale commerciale *sufficiente* per passare alla fase successiva, fate in modo che la stima dei costi di migrazione e modernizzazione sia quanto più semplice possibile.
A tal fine, si consiglia di preparare il business case direzionale concentrandosi sulle applicazioni che rientrano nelle seguenti strategie di migrazione:
+ Ritiro
+ Mantenimento
+ Trasferisci
+ Riospitare
+ Conversione piattaforma
+ Riacquisto
In genere, circa il 70 percento dei carichi di lavoro può essere riospitato, trasferito o riorganizzato e un altro 5 percento può essere ritirato. La valutazione delle applicazioni in base alla strategia di migrazione di solito affronta la questione centrale della riduzione dei costi.
**La stima dei costi per il refactoring, o la riprogettazione, può essere complessa.** Non è pratico tentare di farlo entro il lasso di tempo previsto per la preparazione di un business case direzionale. Come discusso in precedenza in [Determinazione del tipo R per la migrazione](prioritization-and-migration-strategy.md#migration-r-type), prendi in considerazione l'utilizzo di strategie di rehosting, trasferimento o ripiattaforma per la prima fase di migrazione e modernizzazione. Queste strategie R probabilmente accelereranno il recupero iniziale, ridurranno il rischio di implementazione e miglioreranno il business case a breve termine. Inoltre, è sostanzialmente più semplice per i team addetti alle applicazioni modernizzare le applicazioni in esecuzione nell' AWS ambiente rispetto a quelle che non lo sono. [È preferibile aggiungere stime per il refactoring (riprogettazione) di applicazioni specifiche al momento della preparazione del business case dettagliato.](detailed-business-case.md)
*Stima degli sforzi per la migrazione in base alla strategia*
Ogni migrazione è diversa. Prima di impegnare budget o piani, preparate le stime del carico di lavoro per le attività di migrazione dal team responsabile del progetto, che si tratti dei team addetti alle applicazioni interni, dei Servizi AWS professionali o di un'organizzazione partner. AWS
Per contribuire a definire la situazione direzionale, la tabella seguente fornisce gli intervalli di sforzo indicativi per i diversi trattamenti. Questi intervalli presuppongono che sia in corso la migrazione di un medium-to-large portafoglio e che il team addetto alla migrazione sia formato ed esperto. Per i portafogli di piccole dimensioni, è meglio che il team responsabile della migrazione prepari la stima anche per un caso direzionale.
| Strategia di migrazione | Processo di stima | Elementi | Ore della persona | Ore della persona |
| --- |--- |--- |--- |--- |
| Mantenimento | Non fate nulla, senza costi, senza vantaggi e senza ridurre il debito tecnologico. | – | – | – |
| Ritiro | Stima dello smantellamento delle apparecchiature hardware utilizzate, se presenti. | – | – | – |
| Trasferire | Stima la copia del carico di lavoro nell'ambito degli strumenti di utilizzo. VMware VMware Ciò include la copia dei dati, i test sul fumo per verificarli e l'eventuale smantellamento dell'hardware. Lo sforzo di trasferimento VMs è in genere inferiore rispetto ai modelli di rehosting a bassa complessità. | – | – | – |
| Riospitare | Prevedi la possibilità di copiare il carico di lavoro e i dati con una copia dell'immagine, test di fumo, test di alta disponibilità (HA) e disaster recovery (DR), se del caso, per i server di produzione e l'eventuale smantellamento dell'hardware. La migliore pratica consiste nell'utilizzare strumenti come. [AWS Application Migration Service](https://aws.amazon.com/application-migration-service/) Suddividi i carichi di lavoro in bassa, media e alta complessità, in base a fattori quali l'esecuzione di un database o di un altro software di infrastruttura, la complessità del database (se in cluster), la complessità dell'integrazione e i volumi di dati. | Impegno per app per server | Migrazione | Test HA/DR |
| Bassa | 10-14 | 3—5 |
| Media | 16—24 | 4—6 |
| Elevata | 26—38 | 8—12 |
| Conversione piattaforma | Per le migrazioni su più piattaforme che includono aggiornamenti al sistema operativo o alla versione RDBMS, calcola una stima del rehost e aggiungi il tempo necessario per eseguire una ricostruzione e uno smoke test sulla nuova piattaforma. Se la ripiattaforma prevede la modifica della tecnologia della piattaforma, calcola il tempo aggiuntivo per l'uso degli strumenti di conversione, come and, e un test dell'applicazione più completo. [AWS Schema Conversion Tool[AWS Database Migration Service](https://aws.amazon.com/dms/)](https://aws.amazon.com/dms/schema-conversion-tool/) Un esempio di cambiamento della tecnologia è la migrazione da un database commerciale proprietario a un sostituto open source. | Impegno per app per server | Versione aggiornata | Cambiamento tecnologico |
| Bassa | Aggiungi 1—3 | Aggiungere 10—15 |
| Media | Aggiungi 2—5 | Aggiungi 20-30 |
| Elevata | Aggiungi 4—8 | Aggiungi 40—60 |
| Riacquisto | Stima l'estrazione, la trasformazione e il caricamento dei dati nel servizio SaaS appena acquistato, la sostituzione e l'eventuale disattivazione dell'hardware. | – | – | – |
*Stima dei costi dell'infrastruttura di migrazione*
Includi le stime per l'infrastruttura che utilizzerai nel corso della migrazione. In genere, queste stime comprendono:
+ Un budget per i servizi di connettività e scambio di dati per il carico di lavoro e la migrazione dei dati dall'ambiente corrente a AWS
+ Un budget per Servizi AWS (in particolare l'elaborazione e lo storage) necessario per ospitare i carichi di lavoro migrati durante i processi di migrazione, test e cutover
+ L'aumento dei costi delle AWS utenze man mano che ogni ondata di migrazione viene completata
+ I costi di smantellamento dell'infrastruttura esistente che non eseguirà più i carichi di lavoro migrati
Per lo scambio di dati, esamina i volumi totali di dati e valuta la fattibilità dell'utilizzo della rete. Se avete predisposto in anticipo un [AWS Direct Connect](https://aws.amazon.com/directconnect/)collegamento o [Site-to-Site VPN](https://aws.amazon.com/vpn/)un collegamento diretto AWS a un punto della rete WAN per l'utilizzo operativo dopo la migrazione, potete utilizzare tale risorsa fino alla quota di servizio corrispondente.
Se la capacità di rete è insufficiente, un aumento a breve termine della larghezza di banda Internet con una rete privata virtuale (VPN) è spesso una soluzione molto conveniente. In caso contrario, AWS i dispositivi di scambio multimediale come [AWS Snowball Edge](https://aws.amazon.com/snowball/)e [AWS Snowball Edge](https://aws.amazon.com/snowcone/)offrono soluzioni nella maggior parte dei casi. Regioni AWS Inoltre, per la migrazione di grandi volumi di dati, è consigliabile includere il budget for [AWS DataSync](https://aws.amazon.com/datasync/), che migliora l'affidabilità e può accelerare i trasferimenti indipendentemente dal supporto utilizzato.
La modellizzazione del potenziamento dei AWS servizi e dello smantellamento dell'infrastruttura esistente è importante per l'analisi del flusso di cassa del business case. In questa fase, è improbabile che si disponga di un piano onnicomprensivo per determinare esattamente quando verranno sostenuti i costi. Consigliamo quanto segue:
+ Incremento dei costi AWS a un ritmo costante durante la migrazione.
+ Riduzione dei costi dell'infrastruttura esistente che si prevede di smantellare a un ritmo costante per la stessa durata.
Iniziare ad aumentare i AWS costi 1-2 mesi prima che l'infrastruttura esistente diminuisca. Ciò fornisce 1 mese di utilizzo delle AWS utenze per effettuare la migrazione per ogni ondata. Include il tempo necessario per i test e il tempo aggiuntivo per completare i lavori di smantellamento necessari per evitare di incorrere in costi sull'infrastruttura sostituita.
*Stima dei costi di smantellamento*
Lo smantellamento delle apparecchiature che non possono essere riutilizzate e lo smaltimento delle stesse in modo legale e rispettoso dell'ambiente può comportare alcuni piccoli costi. Tuttavia, per un business case direzionale, in genere l'unica somma potenzialmente rilevante è il costo della cancellazione dell'eventuale valore contabile residuo degli asset sostituiti.
Per il business case direzionale, ti consigliamo di fare quanto segue:
+ Controlla l'elenco delle tue risorse.
+ Identifica quelli che verrebbero smantellati.
+ Per ridurre le perdite, esaminate le opportunità di cambiare dispositivo, in modo che i dispositivi più recenti presenti nell'elenco possano essere utilizzati per sostituire gli asset più vecchi e più completamente ammortizzati.
+ Effettua una valutazione del valore contabile futuro degli asset che verrebbero smantellati a quel punto.
+ Includetelo come costo di migrazione della disattivazione.
*Assemblaggio e regolazione dell'intero business case direzionale*
Dopo aver preparato la serie completa di costi per ogni coppia di scenari, create un rendiconto finanziario scontato per ciascuno e rappresentatelo graficamente. Consigliamo di creare casi aziendali direzionali nello stesso periodo del ciclo di aggiornamento dell'hardware. In genere si tratta di 5 anni per server, storage e dispositivi di rete. Se si utilizza lo stesso periodo del ciclo di aggiornamento dell'hardware, i costi di un solo aggiornamento sono inclusi nei costi così come sono per ogni scenario.
Quindi calcola le metriche finanziarie chiave necessarie per ottenere l'approvazione per passare alla fase successiva del programma. Di solito includiamo quanto segue:
+ Il valore attuale netto (NPV) per misurare il valore assoluto delle riduzioni dei costi e degli aumenti di produttività valutati
+ Il periodo di ammortamento, espresso in mesi, necessario per verificare che i resi siano sufficientemente rapidi
+ Il confronto finale del tasso di esecuzione per verificare se il processo sta riducendo i costi in misura sufficiente nel corso del periodo
+ Il ritorno sull'investimento (ROI) e il tasso di rendimento dell'investimento modificato (MIRR) per valutare la performance finanziaria relativa del programma rispetto ad altre esigenze di capitale a cui l'organizzazione potrebbe dare priorità
Utilizzate la prima iterazione del caso per determinare se la performance finanziaria prevista richieda dei perfezionamenti, come illustrato negli esempi seguenti:
+ Se il recupero dell'investimento è troppo lento, prendi in considerazione le opzioni per accelerare e ridurre i costi della migrazione, come le seguenti:
+ Utilizza AWS Partner o AWS Professional Services per espandere le risorse disponibili e parallelizzare ulteriormente la migrazione dei carichi di lavoro con modelli più semplici.
+ Per i carichi di lavoro in esecuzione VMware, confronta la strategia di trasferimento con la strategia di rehosting o replatform, almeno per la fase iniziale. L'utilizzo della strategia di trasferimento può ridurre i costi di migrazione e aumentare la velocità di migrazione.
+ Laddove tecnicamente fattibile, trasferisci i carichi di lavoro che richiedono strategie più complesse di ripiattaforma o rifattorizzazione (riprogettazione) in una fase futura, al di fuori dell'ambito del business case iniziale.
+ Se il ROI e il MIRR sono troppo bassi, considera quanto segue:
+ Gli scenari che state considerando sono troppo conservativi? Avete uno scenario che riflette le esigenze più probabili di crescita della capacità e di elasticità? Disponete di scenari che confrontano i costi, comprensivi degli aumenti della qualità del servizio, entro i vostri obiettivi?
+ Potete affinare l'ambito del portafoglio di applicazioni da migrare nella prima fase per concentrarvi sui carichi di lavoro che produrranno rendimenti più elevati, come quelli con un utilizzo corrente inferiore o costose esigenze di disaster recovery (DR)?
+ È possibile affinare l'ambito del portafoglio di applicazioni per escludere inizialmente carichi di lavoro specifici che ottengono risultati inferiori dal punto di vista commerciale? Ad esempio, è possibile posticipare i carichi di lavoro per i quali le licenze software di terze parti diventano più costose a causa delle diverse condizioni di implementazione nell'infrastruttura cloud pubblica?
+ Se il confronto finale della frequenza di esecuzione non soddisfa l'obiettivo previsto, esplora quanto segue:
+ Innanzitutto, conferma che le altre metriche soddisfino le aspettative. L'argomentazione aziendale direzionale consiste principalmente nel dimostrare che esistono sufficienti opportunità finanziarie per giustificare l'avvio della fase successiva di preparazione alla migrazione.
+ Identificate un elenco delle opportunità per continuare a migliorare la performance in termini di costi AWS dopo la fase iniziale della migrazione.
Includi una valutazione dell'elenco di opportunità nella preparazione del business case dettagliato. Inoltre, includi una valutazione delle opportunità nella manutenzione continua del caso e il processo di month-to-month ottimizzazione dei costi dopo il completamento della migrazione.