Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Attività 4: Definizione del processo di approfondimento dell'applicazione
Ora che hai finito di stabilire regole e processi per la prioritizzazione delle applicazioni, esegui un'analisi approfondita delle applicazioni che ti aiuterà a rifinire la priorità di ciascuna applicazione. L'analisi approfondita dell'applicazione viene eseguita su un'applicazione alla volta, in ordine dalla priorità più alta a quella più bassa. Per i progetti con più team di portfolio, ogni team può eseguire un'analisi approfondita dell'applicazione su un'applicazione diversa contemporaneamente.
Durante l'immersione approfondita, potresti riscontrare alcuni problemi imprevisti, come le dipendenze, che influiscono sulla complessità della migrazione dell'applicazione. Quando ciò accade, è necessario modificare i criteri di valutazione della complessità definiti nel passaggio precedente e aggiornare il foglio di valutazione di conseguenza per ottenere punteggi di complessità più accurati per le applicazioni future. È quindi possibile aggiornare le priorità delle applicazioni utilizzando i nuovi punteggi di complessità.
Questa attività prevede i seguenti passaggi:
+ [Fase 1: Definire il processo del workshop di candidatura](#deep-dive-1)
+ [Fase 2: Definizione del processo di mappatura delle applicazioni](#deep-dive-2)
+ [Fase 3: (Facoltativo) Definire lo stato di destinazione dell'applicazione](#deep-dive-3)
+ [Fase 4: Finalizza il processo di approfondimento dell'applicazione](#deep-dive-4)
## Fase 1: Definire il processo del workshop di candidatura
Il processo di workshop è uno degli approcci più efficienti per un'analisi approfondita delle applicazioni. Utilizzando questo processo, collaborate con le parti interessate, i proprietari delle applicazioni e il team del portfolio per valutare e analizzare l'applicazione. L'obiettivo è comprendere chiaramente lo stato attuale dell'applicazione, compresi l'architettura, lo scopo aziendale, le dipendenze e l'ambiente. Queste informazioni dettagliate sulla dimensione e la complessità dell'applicazione vengono quindi utilizzate per progettare lo stato di destinazione dell'applicazione.
Ogni workshop dura in genere da 1 a 8 ore, anche se potrebbe essere necessario più tempo per applicazioni ad alta complessità. È inoltre possibile suddividere il workshop in più riunioni, a seconda della disponibilità delle risorse, delle preferenze e delle dimensioni e della complessità dell'applicazione.
### Identifica i risultati attesi
Prima di condurre un seminario applicativo, è necessario stabilire un programma e definire i risultati attesi del workshop o le informazioni che è necessario raccogliere durante il workshop. Ciò consente ai partecipanti al workshop di prepararsi per il workshop, aiuta a mantenere l'obiettivo della riunione e garantisce che, entro la fine del workshop, siano disponibili tutte le informazioni necessarie per stabilire le priorità, pianificare e migrare l'applicazione.
Si consiglia di definire un set standard di risultati attesi e di documentarli nel runbook di prioritizzazione delle applicazioni. Quando si prepara un workshop, si utilizzano i risultati previsti standard e se ne aggiungono di nuovi per l'applicazione specifica.
Definite la serie standard di risultati attesi per i workshop applicativi come segue:
1. Apri il runbook per la prioritizzazione delle applicazioni.
1. Nella sezione *Risultati attesi del workshop applicativo, stabilisci una serie standard di risultati* attesi per i workshop applicativi. Durante la preparazione di un workshop, è possibile personalizzarlo in base alle esigenze specifiche dell'applicazione.
1. Salvate il runbook per la prioritizzazione delle applicazioni.
1. Mantieni i risultati attesi nel runbook di prioritizzazione delle applicazioni. Man mano che svolgete workshop sulle applicazioni e proseguite con la valutazione del portafoglio e la pianificazione delle ondate, potreste identificare nuovi risultati attesi o perfezionare i risultati esistenti.
Di seguito sono riportati alcuni esempi di risultati attesi per il workshop applicativo.
****
| Priorità | Risultati attesi del seminario applicativo |
| --- | --- |
| 1 | Chiara comprensione dell'architettura attuale dell'applicazione, inclusi i server associati, le dipendenze, l'ambiente e il livello dell'applicazione. |
| 2 | Il team ha raccolto i metadati per supportare la progettazione dell'architettura di destinazione. Sono richiesti i seguenti metadati:[See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| 3 | Il questionario per il proprietario dell'applicazione è completo e tutte le domande chiave hanno una risposta. |
| 4 | Il team ha raccolto tutta la documentazione dell'applicazione, come la guida per l'utente, la documentazione sull'architettura dell'applicazione, la documentazione sui test, la documentazione sulla progettazione e la documentazione sull'interfaccia di programmazione dell'applicazione (API). |
### Definisci le regole del workshop applicativo
Prima di condurre un seminario applicativo, è necessario definire le regole che lo disciplineranno. Le regole comuni includono la durata del workshop, gli strumenti che potrebbero essere necessari durante il workshop e tutte le considerazioni sulla pianificazione o le scadenze che devono essere prese in considerazione. Ciò aiuta a mantenere la riunione puntuale e garantisce che le decisioni prese durante il workshop siano in linea con il programma di migrazione.
Si consiglia di documentare le regole del workshop applicativo nel runbook di prioritizzazione delle applicazioni.
Definite le regole del vostro workshop applicativo come segue:
1. Apri il runbook per la prioritizzazione delle applicazioni.
1. Nella sezione *Regole del workshop applicativo*, definisci le regole che regolano i tuoi workshop.
1. Salva il runbook di prioritizzazione delle applicazioni.
1. Mantieni le regole nel runbook di prioritizzazione delle applicazioni. Man mano che organizzate workshop sulle applicazioni e proseguite con la valutazione del portafoglio e la pianificazione delle ondate, potreste identificare nuove regole o perfezionare quelle esistenti.
Di seguito sono riportati alcuni esempi di regole per il workshop sull'applicazione.
****
| Priorità | Regola del workshop |
| --- | --- |
| 1 | I workshop dovrebbero essere programmati per un massimo di 2 ore per sessione il martedì e il giovedì. |
| 2 | È previsto il congelamento dell'infrastruttura dal 1 dicembre al 15 gennaio. |
| 3 | È previsto un workshop pratico sugli strumenti di migrazione. |
| 4 | Il contratto per il data center scadrà il 31 marzo. I carichi di lavoro devono essere evacuati entro il 31 marzo per evitare sanzioni e costose estensioni contrattuali. |
| 5 | La domanda biometrica e la domanda relativa all'orario e alle presenze verranno mantenute. |
### Definisci il processo del workshop di candidatura
È importante definire un processo standard per lo svolgimento dei workshop applicativi. Ciò garantisce un'esperienza coerente e definisce le aspettative per i partecipanti al workshop, il che può migliorare l'efficienza del workshop.
Il processo di candidatura del workshop prevede tre fasi:
+ **Preparazione per il workshop**: la preparazione per il workshop aiuta a garantire che la sessione si svolga senza intoppi e che i partecipanti sappiano cosa ci si aspetta. Per prepararsi al workshop, si stabilisce un'agenda e si definiscono i risultati attesi, si identificano i partecipanti, gli strumenti e le informazioni necessarie al workshop e si pianifica il workshop. La pianificazione del workshop con almeno una settimana di anticipo dà al team il tempo di bloccare il calendario, prepararsi per il workshop e raccogliere tutte le informazioni utili.
+ **Conduci il seminario**: quando conduci il workshop, limiti la discussione ai punti all'ordine del giorno e ti assicuri di soddisfare i risultati previsti. Prendi nota degli argomenti che ritieni utili ma che non sono inclusi nella tua agenda. Può essere utile registrare il workshop.
+ **Finalizza i risultati del workshop**: dopo il workshop, il tuo team dovrebbe avere una chiara comprensione dello stato attuale dell'applicazione e dei potenziali punti deboli, rischi, sfide e ostacoli che potrebbero influire sulla definizione delle priorità e sulla migrazione. Le attività più comuni dopo il workshop includono: riassegnare le priorità all'applicazione, redigere lo stato futuro dell'applicazione e aggiornare il runbook con eventuali risultati, regole o modifiche ai processi previsti che potrebbero essere utili nel prossimo workshop.
Il *modello Runbook per la prioritizzazione delle applicazioni* include un step-by-step processo standard per la preparazione, lo svolgimento e la conclusione di un workshop sulle applicazioni. Definite il processo del workshop applicativo come segue:
1. Apri il runbook per la prioritizzazione delle applicazioni.
1. Nella sezione *Application Workshop*, modificate il processo standard per soddisfare le esigenze del vostro caso d'uso.
1. Salva il runbook per la prioritizzazione delle applicazioni.
1. Mantieni il processo nel runbook di prioritizzazione delle applicazioni. Durante i workshop sulle applicazioni, potreste identificare le modifiche che desiderate apportare a questo processo.
### Step: criteri di uscita
+ Hai definito l'agenda del workshop e le risorse e gli artefatti necessari per supportare il workshop.
+ Avete definito il risultato previsto del workshop e identificato le informazioni da raccogliere durante il workshop.
+ Avete condotto una prova del processo del workshop e disponete delle informazioni necessarie per supportare la mappatura delle applicazioni e progettare lo stato di destinazione.
+ Nel runbook sulla prioritizzazione delle applicazioni è stato documentato quanto segue:
+ Risultati attesi del workshop applicativo
+ Regole del seminario applicativo
+ Processo del workshop di candidatura
## Fase 2: Definizione del processo di mappatura delle applicazioni
La *mappatura delle applicazioni* è il processo di assegnazione di ogni applicazione a un modello di migrazione, identificato e convalidato dall'utente. [Fase 4: Convalida dei modelli di migrazione](discovery.md#discovery-4) In questo passaggio, si definiscono le regole da utilizzare per valutare l'applicazione. Quindi definisci il processo che utilizzerai per valutare ogni applicazione. La mappatura di ogni applicazione sullo use case del modello di migrazione consente di identificare lo strumento di migrazione, le competenze necessarie per completare la migrazione e la complessità del modello di migrazione.
Non sempre si esegue la migrazione di un'applicazione su un unico pattern. Per ulteriori informazioni su quando potrebbero essere necessari più pattern per la stessa applicazione, consultate [Definite il processo di mappatura dell'applicazione](#deep-dive-2-process) più avanti in questa sezione.
### Regole di mappatura delle applicazioni
Le regole di mappatura delle applicazioni consentono di valutare l'applicazione e identificare il modello di migrazione appropriato. Ogni regola è costituita da tutte le informazioni da utilizzare per valutare l'applicazione e soddisfare i criteri del pattern.
Nei [modelli di playbook del portfolio](samples/portfolio-playbook-templates.zip), il *modello Runbook per la prioritizzazione delle applicazioni include una sezione per* documentare le regole di mappatura delle applicazioni. Definite il processo come segue:
1. Apri il runbook per la prioritizzazione delle applicazioni.
1. Nella sezione *Regole di mappatura delle applicazioni, definisci le regole* di mappatura delle applicazioni.
1. Salva il runbook di prioritizzazione delle applicazioni.
1. Mantieni le regole nel runbook di prioritizzazione delle applicazioni.
La tabella seguente fornisce esempi di regole di mappatura delle applicazioni.
**Nota**
Il modello IDs e i nomi in questa tabella corrispondono ai modelli di esempio in[Fase 4: Convalida dei modelli di migrazione](discovery.md#discovery-4). Utilizzate lo schema IDs e i nomi definiti nel runbook di prioritizzazione delle applicazioni.
****
| Priorità | Regola di mappatura |
| --- | --- |
| 1 | Utilizzando i dati di utilizzo o gli strumenti di monitoraggio, identifica se l'applicazione è un'applicazione zombie o inattiva. Se l'applicazione è un'applicazione zombie o inattiva, scegliete *Pattern 8: Ritira l'applicazione*, quindi chiudete i server nello stack di applicazioni. |
| 2 | Identifica se la migrazione di questa applicazione sul cloud offre valore aziendale. Le applicazioni che vengono utilizzate solo in sede e non sono condivise tra filiali o sedi geografiche, come le applicazioni di rilevazione presenze, in genere non devono essere migrate sul cloud. Se la migrazione di questa applicazione non offre valore aziendale, scegli *Pattern 9: Retain* on-premise. |
| 3 | Identificate se il sistema operativo (OS) dell'applicazione è supportato dai servizi di AWS migrazione AWS, da un fornitore o dallo strumento di migrazione rehost, quindi effettuate le seguenti operazioni:[See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| 4 | Identifica se l'applicazione ha una versione SaaS (Software as a Service) o equivalente, quindi valuta i vantaggi e i costi del passaggio a questa nuova piattaforma. Se questi criteri sono soddisfatti, scegli *Pattern 10: riacquisto e aggiornamento a SaaS*. |
| 5 | Identifica se i database locali dell'applicazione possono essere migrati su un servizio omogeneo nel cloud, ad esempio la migrazione di un database Oracle locale su Amazon RDS for Oracle o la migrazione di un database MySQL locale al database Amazon Aurora MySQL Compatible Edition. Se questi criteri sono soddisfatti, usa *Pattern 2: Replatform to Amazon RDS usando AWS DMS * and. AWS SCT |
| 6 | Identifica se l'applicazione utilizza Microsoft.NET Core (.NET 5 o.NET 6), Java, PHP o un altro linguaggio di programmazione open source e se l'applicazione è ospitata in Microsoft Windows Server. Valuta se il costo della ripiattaforma è giustificabile. Se questi criteri sono soddisfatti, scegli *Pattern 7: Replatform from Windows to Linux su Amazon EC2*. |
| 7 | Identifica lo storage locale e condiviso di file locale da cui dipende l'applicazione, quindi determina se deve essere incluso nella migrazione. Se è necessario migrare lo storage di file locale e condiviso, scegli *Pattern 4: Replatform to Amazon EFS usando AWS DataSync * o. AWS Transfer Family |
| 8 | Identifica se i server dell'applicazione sono server mainframe o midrange, come IBM AS/400 o Apache Spark, e verifica che le applicazioni siano compatibili con gli emulatori. Se questi criteri sono soddisfatti, utilizza *Pattern 6: Replatform mainframe o server midrange su Amazon EC2* utilizzando un emulatore. |
| 9 | Identifica se si tratta di un'applicazione legacy, monolitica o basata su mainframe che non è più in grado di soddisfare la domanda dell'azienda a causa dei suoi limiti. Ad esempio, identifica se l'applicazione è scalabile, si integra con le applicazioni correlate o è costosa e difficile da mantenere. Se l'applicazione soddisfa uno di questi criteri, scegliete *Pattern 11: riprogetta l'applicazione*. |
### Definite il processo di mappatura dell'applicazione
Quando si mappano le applicazioni ai modelli di migrazione, è utile richiedere i dati di rilevamento per l'applicazione al team di rilevamento. Questi dati includono in genere informazioni come un modello di migrazione consigliato (a volte chiamato *modello R* o *punteggio R*), informazioni sull'utilizzo, dipendenze delle applicazioni e altre informazioni che è possibile utilizzare nella valutazione. Mentre esplorate questa applicazione in dettaglio, potreste decidere di modificare il modello di migrazione precedentemente identificato.
Una volta ottenuti i dati, è possibile confrontare l'applicazione con i criteri aziendali e tecnici in base ai quali sono stati identificati[Fase 2: Identifica i fattori aziendali e tecnici](discovery.md#discovery-2). I driver sono stati registrati nel runbook di prioritizzazione delle applicazioni. La valutazione dell'applicazione in base ai criteri potrebbe portare a selezionare più modelli di migrazione per l'applicazione oppure potrebbe portare all'eliminazione dei modelli basati su costi, pianificazione o altre limitazioni.
Di seguito è riportato un esempio di driver aziendale che richiede l'utilizzo di più modelli di migrazione su una singola applicazione. Desideri migrare un database SQL Server locale su Amazon DynamoDB, ma poiché il contratto per il data center è in scadenza, l'azienda vorrebbe migrarlo prima della pianificazione proposta per la ripiattaforma. Per affrontare questo fattore di business, rivedi il piano di migrazione dell'applicazione adottando un approccio a due modelli. Innanzitutto, reospitate l'applicazione sul cloud per rimuoverla dal data center. Successivamente, dopo che l'applicazione è nel cloud, puoi ripiattaforme in base alla pianificazione proposta.
È inoltre necessario considerare se l'applicazione è un'applicazione a livello n, ovvero un'applicazione composta da più livelli. Un *livello di applicazione* è un gruppo di server fisici che ospitano i livelli orizzontali dell'applicazione. Le applicazioni di livello N sono più complesse perché ogni livello potrebbe richiedere una strategia diversa e potresti scegliere di migrare i livelli di applicazione in fasi diverse. Ad esempio, se si dispone di un'applicazione composta da livelli di presentazione, servizio aziendale e database, è possibile mappare un modello diverso per ogni livello.
L'applicazione viene quindi valutata in base alle regole di mappatura delle applicazioni, definite nel runbook di prioritizzazione delle applicazioni. Per ulteriori informazioni, consulta la sezione [Regole di mappatura delle applicazioni](#deep-dive-2-rules) descritta precedentemente in questa sezione.
Dopo aver mappato l'applicazione su uno o più modelli, esaminate e verificate questa decisione con il proprietario dell'applicazione. Il proprietario dell'applicazione deve confermare il modello selezionato e deve aiutarvi a pianificare ed eseguire la migrazione. In questo momento, i proprietari delle applicazioni potrebbero anche fornire informazioni sulla base della loro esperienza o condividere eventuali problemi che prevedono con la migrazione.
Dopo aver mappato l'applicazione su uno o più modelli di migrazione e confermato i modelli con il proprietario dell'applicazione, si registrano l'applicazione, l'ID del pattern, il nome del pattern e i driver pertinenti in una tabella di mappatura delle applicazioni nel runbook di prioritizzazione delle applicazioni.
Nei [modelli di portfolio playbook, il modello Runbook](samples/portfolio-playbook-templates.zip) *per la prioritizzazione delle applicazioni include un processo standard per la mappatura delle applicazioni*. step-by-step Definite il processo come segue:
1. Apri il runbook per la prioritizzazione delle applicazioni.
1. Nella sezione *Application Workshop*, modificate il processo standard per soddisfare le esigenze del vostro caso d'uso.
1. Salva il runbook per la prioritizzazione delle applicazioni.
1. Mantieni il processo nel runbook di prioritizzazione delle applicazioni.
La tabella seguente è un esempio di tabella di mappatura delle applicazioni. Il *modello Runbook fornito per la prioritizzazione delle applicazioni* include una tabella vuota in cui è possibile registrare i risultati del processo di mappatura delle applicazioni.
**Nota**
Il modello IDs e i nomi in questa tabella corrispondono ai modelli di esempio in. [Fase 4: Convalida dei modelli di migrazione](discovery.md#discovery-4) Utilizzate lo schema IDs e i nomi definiti nel runbook di prioritizzazione delle applicazioni.
****
| Application name (Nome applicazione) | ID del modello | Nome del pattern | Fattori aziendali e tecnici risolti |
| --- | --- | --- | --- |
| Sito web aziendale | 1 | Rehosting su Amazon EC2 utilizzando Application Migration Service o Cloud Migration Factory | [See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| Sistema HR | 8 | Ritirare l'applicazione | [See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| Applicazione di orari e presenze | 9 | Retain on-premise | [See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| Sistema PO | 3 | Ripiattaforma su Amazon EC2 utilizzando CloudFormation | [See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| Sistema CRM | 10 | Riacquisto e aggiornamento a SaaS | [See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| Sistema a capitale fisso | 7 | Ripiattaforma da Windows a Linux su Amazon EC2 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| Archiviazione di file ERP | 4 | Ripiattaforma su Amazon EFS utilizzando AWS DataSync o AWS Transfer Family | [See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| Sistema di contabilità | 6 | Rehosting di server mainframe o midrange su Amazon EC2 utilizzando un emulatore | [See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| Contabilità generale | 11 | Riprogetta l'applicazione | [See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
### Step: criteri di uscita
+ Nel runbook sulla prioritizzazione delle applicazioni è stato documentato quanto segue:
+ Regole di mappatura delle applicazioni
+ Processo di mappatura delle applicazioni
+ Le regole e i processi di mappatura sono stati convalidati utilizzando una o più applicazioni proof-of-concept (POC).
## Fase 3: (Facoltativo) Definire lo stato di destinazione dell'applicazione
In questo passaggio, si definiscono gli attributi e il processo utilizzati per documentare lo stato di destinazione, o *lo stato* futuro, dell'applicazione. Lo stato di destinazione è il modo in cui l'applicazione opera nell'ambiente cloud di destinazione dopo la migrazione. L'ambiente di destinazione varia in base alla piattaforma o al servizio di destinazione e ai requisiti aziendali. L'ambiente di destinazione potrebbe essere Cloud AWS o AWS Managed Services (AMS).
La definizione dello stato di destinazione aiuta i project manager, i consulenti in materia di migrazione, gli architetti, i proprietari delle applicazioni e le parti interessate a collaborare in modo efficace. Utilizzando questo processo, il team può identificare e risolvere i problemi in anticipo e implementare in modo più efficiente l'ambiente dello stato di destinazione.
Per alcune applicazioni, questo passaggio è facoltativo. È possibile saltare questo passaggio se l'applicazione da migrare è autonoma o a bassa complessità. Le strategie di migrazione che non modificano l'applicazione, come il rehosting, potrebbero non richiedere questo passaggio. Tuttavia, per strategie di migrazione più complesse, come replatform e re-architect, è necessario definire lo stato di destinazione prima di iniziare la migrazione.
Il workshop fornisce una comprensione approfondita dello stato attuale dell'applicazione, quindi è una buona idea redigere lo stato di destinazione dopo aver completato il workshop. Inoltre, la mappatura dell'applicazione al relativo modello di migrazione fornisce ulteriori informazioni e aiuta a identificare se è necessario definire lo stato di destinazione. Ad esempio, se mappi l'applicazione al pattern *Rehost to Amazon EC2 utilizzando Application Migration Service o Cloud Migration* Factory, hai identificato che la strategia è il rehosting e probabilmente non è necessario definire lo stato di destinazione per questa applicazione.
### Attributi dello stato di destinazione
Quando si definisce lo stato di destinazione e si prendono decisioni sull'applicazione, si consiglia di considerare i seguenti attributi dello stato di destinazione:
+ **AWS Well-Architected Tool**— Esamina lo stato di destinazione dell'applicazione rispetto al AWS Well-Architected Framework per migliorare la sicurezza, le prestazioni e la resilienza dell'applicazione nel cloud.
+ **Zona di atterraggio bersaglio**: in genere, entro la fine della [fase di mobilitazione](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-migration/mobilize-phase.html), è necessario aver costruito una landing zone completa pronta per l'esecuzione di applicazioni pilota. La landing zone dovrebbe già essere configurata con un'architettura multi-account, gestione delle identità e degli accessi, governance, sicurezza dei dati, progettazione della rete e registrazione. Utilizzi un'applicazione pilota per verificare che la landing zone sia completa. Verifica di poter lanciare ed eseguire l'applicazione pilota nella landing zone di destinazione esistente. Se devi modificare la landing zone per l'applicazione, informa il team di landing zone delle tue esigenze. Ad esempio, l'applicazione potrebbe richiedere l'accesso a un servizio ospitato in un account separato oppure l'applicazione potrebbe richiedere un routing speciale verso un cloud privato virtuale (VPC).
+ **Dipendenze**: identifica tutte le applicazioni su cui si basa l'applicazione per funzionare correttamente. Ad esempio, l'applicazione potrebbe dipendere da database, storage o servizi di terze parti, come un gateway di pagamento o un servizio Web esterno, oppure l'applicazione potrebbe dipendere da altre applicazioni all'interno dell'ambiente. Per accedere a queste dipendenze, potrebbe essere necessario un routing o una configurazione speciali, ad esempio la connessione a un servizio di directory per l'autenticazione.
+ **Applicazioni dipendenti**: identifica tutte le applicazioni che si basano sull'applicazione per funzionare correttamente. Potrebbe essere necessario riconfigurare e aggiornare queste applicazioni per evitare tempi di inattività durante la migrazione.
+ **Sicurezza e conformità**: esamina l'ambiente di destinazione con il team di sicurezza e conformità e identifica eventuali lacune. L'applicazione potrebbe essere composta da diversi componenti, livelli logici o più livelli. A seconda dei requisiti di conformità, potresti non essere in grado di migrare alcuni di questi componenti nell'ambiente di destinazione oppure potresti aver bisogno di misure di sicurezza aggiuntive durante la migrazione del carico di lavoro. I requisiti comuni di sicurezza e conformità sono la residenza dei dati, la crittografia in transito e la crittografia a riposo. Questi richiedono una configurazione aggiuntiva nell'ambiente di destinazione. Ad esempio, potrebbe essere necessario configurare i certificati per proteggere le comunicazioni oppure potrebbero essere necessarie chiavi di crittografia per proteggere i dati inattivi. Potrebbe inoltre essere necessario selezionare più modelli di migrazione per l'applicazione in modo che alcuni livelli dell'applicazione rimangano locali e altri livelli vengano migrati nel cloud.
+ **Dipendenze di archiviazione**: esamina le dipendenze dello storage delle applicazioni e determina in che modo la migrazione dell'applicazione nell'ambiente di destinazione influirebbe su queste dipendenze. Ad esempio, se l'applicazione dipende dallo storage di rete, come lo storage collegato alla rete (NAS) o una rete di archiviazione (SAN), è necessario pianificare un servizio di storage nel cloud, come Amazon Simple Storage Service (Amazon S3) o Amazon. FSx È inoltre necessario pianificare il modo in cui migrare i dati nell'ambiente cloud di destinazione per mantenere l'applicazione in esecuzione.
+ **Database**: esamina la strategia di migrazione per tutti i database utilizzati dall'applicazione. Hai intenzione di passare a un nuovo servizio di database, come Amazon Relational Database Service (Amazon RDS), Amazon Aurora o Amazon DynamoDB? Hai intenzione di riospitare il tuo database nell'ambiente di destinazione? In alcuni casi, specialmente per un database monolitico, è necessario rifattorizzare il database per soddisfare requisiti tecnici, come una latenza inferiore al secondo, o per sfruttare le funzionalità di un particolare tipo di database. AWS Come per i requisiti di conformità in materia di residenza dei dati, è necessario identificare quali dati devono essere conservati in locale e quali devono essere migrati nel cloud. Ad esempio, potrebbe essere necessario conservare una tabella di database locale per le informazioni sui clienti e migrare il resto del database sul cloud.
+ **Componenti dell'applicazione**: esamina i componenti da cui dipende l'applicazione. Determina se l'applicazione dipende da un componente non supportato dall'ambiente di destinazione. Se l'ambiente di destinazione non supporta tutti i componenti dell'applicazione, è necessario rifattorizzare l'applicazione per mitigare il problema. Ad esempio, se si dispone di un'applicazione.NET Framework che dipende da componenti solo per Windows come Component Object Model (COM) Interop, COM\+ o il registro di Windows, per ripiattaforma l'applicazione su un sistema operativo Linux, è necessario rifattorizzare l'applicazione in.NET Core.
+ Livelli di **applicazione: identifica il numero di livelli** dell'applicazione. L'applicazione è a livello n, a due livelli o autonoma? Conferma di aver compreso il modello di migrazione per ogni livello. Ad esempio, l'applicazione potrebbe avere un livello di presentazione (o *web*) che ospita l'interfaccia utente, un livello di applicazione che ospita i servizi aziendali e un livello di database che ospita i database, e ogni livello potrebbe richiedere un modello di migrazione diverso.
+ **Disaster recovery: identifica il piano di disaster** recovery (DR) attuale e futuro dell'applicazione, inclusi il Recovery Point Objective (RPO) e il Recovery Time Objective (RTO). Decidi se utilizzare il piano di DR locale esistente o esplorare una nuova strategia di DR nel cloud. Per ulteriori informazioni, consulta le sezioni [Opzioni di disaster recovery nel cloud](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html) e [Obiettivi di ripristino (RTO e RPO)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html#recovery-objectives-rto-and-rpo) nel white paper *Disaster Recovery of Workloads on AWS: Recovery in the* Cloud.
### Definisci il processo dello stato di destinazione
Per definire lo stato di destinazione dell'applicazione, ti consigliamo di utilizzare il modello fornito, *Application target state worksheet* (formato Excel), disponibile nei modelli di [portfolio playbook](samples/portfolio-playbook-templates.zip). Il modello include attributi standard che è possibile utilizzare o modificare. Definite il processo per documentare lo stato di destinazione dell'applicazione come segue:
1. Aprire il foglio di *lavoro sullo stato di destinazione dell'applicazione*.
1. Rivedi gli attributi predefiniti e apporta le modifiche necessarie al tuo caso d'uso.
1. Salva il foglio di lavoro.
1. Apri il runbook per la prioritizzazione delle applicazioni.
1. Nella sezione *Stato dell'applicazione Target*, procedi come segue:
1. Nella sezione *Quando completare questo processo*, stabilite i criteri che consentano al team del portfolio di determinare se è necessario definire lo stato di destinazione dell'applicazione.
1. Aggiorna la sezione degli attributi in base alle esigenze.
1. Aggiorna la sezione del processo in base alle esigenze del tuo caso d'uso.
1. Salva il runbook per la prioritizzazione delle applicazioni.
#### Esempi dello stato di destinazione dell'applicazione
La tabella seguente mostra un esempio di come utilizzare il foglio di lavoro *dello stato di destinazione dell'applicazione* per documentare lo stato di destinazione dell'applicazione.
****
| Applicazione | Esempio |
| --- | --- |
| **Piattaforma di destinazione** | Cloud AWS |
| **Zona di atterraggio** | Richiede l'accesso a un servizio di directory locale
Richiede AWS Control Tower la gestione centralizzata di più account e servizi all'interno dell'organizzazione |
| **Dipendenze** | Active Directory, gateway di pagamento, sistema di inventario |
| **Applicazioni dipendenti** | Nessuno |
| **Sicurezza** | Crittografia dei dati su disco e in transito. |
| **Conformità** | PCI, SOC |
| **Dipendenze di archiviazione** | Unità di avvio collegata, NAS, condivisione di rete |
| **Database** | Attuale: Oracle DB
Cloud: Amazon RDS per Oracle |
| **Componente dell'applicazione** | .NET Framework 4.5 |
| **Livelli di applicazione** | Livello N
Front-end, servizi aziendali, servizi e agenti di dati, database |
| **Ripristino di emergenza** | RPO: 1 minuto, RTO: 5 minuti
L'attuale strategia di ripristino di emergenza prevede lo standby a caldo
DR in tutte le regioni degli Stati Uniti |
### Step: criteri di uscita
+ Nel *foglio di lavoro sullo stato di destinazione dell'applicazione*, sono stati definiti gli attributi che si desidera includere nel processo relativo allo stato di destinazione.
+ Nel runbook di prioritizzazione delle applicazioni, avete fatto quanto segue:
+ Sono stati stabiliti i criteri in base ai quali il team del portfolio deve definire lo stato di destinazione dell'applicazione.
+ Hai aggiornato il processo di definizione dello stato di destinazione in base al tuo caso d'uso.
## Fase 4: Finalizza il processo di approfondimento dell'applicazione
Ora, definisci in che modo il portfolio workstream utilizza il workshop, le regole e i processi stabiliti in questa attività per eseguire un'analisi approfondita dell'applicazione. Questo è il processo a cui fa riferimento il flusso di lavoro del portfolio nella fase di implementazione della migrazione.
Personalizzate questo processo nel runbook di prioritizzazione delle applicazioni come segue:
1. Apri il runbook di prioritizzazione delle applicazioni.
1. Nella sezione *Fase 2: Esegui l'analisi approfondita dell'applicazione*, modifica il processo in base al caso d'uso e all'ambiente.
1. Salvate il runbook per la prioritizzazione delle applicazioni.
1. Condividi il runbook di prioritizzazione delle applicazioni con il team per esaminarlo.