Strumenti di valutazione per la migrazione al cloud: perché la scoperta dell'infrastruttura è solo metà del lavoro

La maggior parte dei programmi di migrazione al cloud inizia con una scansione dell'infrastruttura. Azure Migrate individua le macchine virtuali. AWS Application Discovery Service mappa i server. Google Migration Center inventaria i carichi di lavoro. Nel giro di pochi giorni, il team dispone di un foglio di calcolo con tutti i server, il loro utilizzo della CPU, l'ingombro della memoria e un costo stimato per eseguire la stessa configurazione nel cloud di destinazione. La valutazione dell'infrastruttura è completa. Si può iniziare a pianificare.

Solo che non è possibile. Perché l'inventario dell'infrastruttura indica quale hardware esegue le applicazioni, non se queste possono essere eseguite nel cloud, quanto costerà modificarle per renderle compatibili, quali hanno dipendenze che si interromperanno durante la migrazione, quali sono scritte utilizzando API obsolete non supportate dalla piattaforma cloud o quali contengono dieci anni di logica aziendale non documentata che dovrà essere compresa prima che qualsiasi conversione possa essere convalidata. La scoperta dell'infrastruttura è un prerequisito per la valutazione della migrazione al cloud. Non è la valutazione stessa.

Che cos'è una valutazione della migrazione al cloud?

La valutazione della migrazione al cloud è un'analisi strutturata che determina se, come e a quale costo un insieme di carichi di lavoro può essere spostato nel cloud. Fornisce le prove necessarie per prendere tre decisioni: quale strategia di migrazione applicare a ciascun carico di lavoro, quale sarà il costo effettivo della migrazione in termini di impegno e spesa cloud e in quale sequenza i carichi di lavoro dovrebbero essere migrati per gestire il rischio di dipendenza.

Una valutazione completa della migrazione al cloud si articola in cinque dimensioni distinte. Gli strumenti di rilevamento dell'infrastruttura ne affrontano una. Le altre quattro richiedono strumenti, tecniche e competenze differenti.

Dimensione di valutazione	A cosa risponde	Strumenti primari
Infrastruttura	Quali server, macchine virtuali e servizi sono presenti? Quali sono i loro profili di utilizzo?	Azure Migrate, AWS Application Discovery, Google Migrate Center
Codice dell'applicazione	Il codice è compatibile con le piattaforme cloud? Cosa deve essere modificato?	CAST in evidenza, SMART TS XLModernizzazione dell'app CloudPilot e GitHub Copilot
Dati	Quali sono i volumi di dati esistenti? Dove risiedono i dati? Quali sono la complessità della migrazione e i vincoli di conformità?	Servizio di migrazione del database AWS, Servizio di migrazione del database Azure, Striim
Sicurezza e conformità	Quali sono i requisiti normativi applicabili? Quali lacune di sicurezza esistono? Quali modifiche alla gestione delle identità e degli accessi (IAM) e alla crittografia sono necessarie?	AWS Security Hub, Microsoft Defender per il cloud, Prisma Cloud
Costo e TCO	Qual è il costo totale della migrazione e il costo complessivo di proprietà successivo alla migrazione?	Calcolatore dei prezzi AWS, Calcolatore del costo totale di proprietà (TCO) di Azure, Infracost, Apptio Cloudability

Le organizzazioni che gestiscono solo la dimensione infrastrutturale elaborano piani di migrazione con una portata sconosciuta. Scoprono sorprese relative ad applicazioni, dati, sicurezza e costi durante la migrazione, quando il costo per risolverle è massimo.

Le cinque dimensioni della valutazione della migrazione al cloud

Valutazione dell'infrastruttura

La valutazione dell'infrastruttura è il punto di partenza. Essa consiste nell'inventariare l'ambiente di origine: ogni server, macchina virtuale, container e servizio, con la relativa configurazione, i dati di utilizzo e le connessioni di dipendenza con altri componenti dell'infrastruttura.

Strumenti come Azure Migrate o altri prodotti automatizzano il rilevamento dei componenti e delle configurazioni dei carichi di lavoro. Questi strumenti riducono il lavoro manuale e garantiscono una raccolta dati coerente in tutto l'ambiente, sebbene potrebbero non rilevare dipendenze non documentate.

Azure Migrate è lo standard per le organizzazioni che migrano ad Azure. Esegue il rilevamento senza agenti degli ambienti VMware vSphere, Hyper-V e dei server fisici, producendo valutazioni di idoneità, raccomandazioni di dimensionamento basate sulle prestazioni e stime dei costi prima della migrazione di un singolo carico di lavoro.

AWS Application Migration Service (MGN) e AWS Application Discovery Service svolgono la stessa funzione per le destinazioni AWS. Discovery Service raccoglie dati di configurazione e prestazioni on-premise tramite raccolta senza agenti o tramite un agente installato localmente.

Google Migration Center offre una soluzione unificata per la scoperta e la valutazione delle migrazioni a Google Cloud, combinando inventario delle risorse, analisi delle dipendenze e modellazione del costo totale di proprietà (TCO) in un'unica console.

Cosa producono gli strumenti di infrastruttura: inventario dei server, parametri di riferimento per l'utilizzo, mappe delle dipendenze di rete tra i componenti dell'infrastruttura e raccomandazioni per il dimensionamento ottimale del livello cloud di destinazione. Cosa non producono: alcuna informazione sulla compatibilità delle applicazioni in esecuzione su tali server con il cloud, sui costi di modifica del codice o sulle modalità di migrazione dei dati all'interno di tali applicazioni.

Valutazione del codice applicativo

Una valutazione del codice dell'applicazione identifica i problemi di compatibilità e le opportunità di modernizzazione che possono influire sul successo della migrazione. Questa valutazione è essenziale per garantire che le applicazioni vengano eseguite in modo affidabile in Azure e per pianificare efficacemente le fasi di migrazione. È necessario valutare il codice dell'applicazione per individuare tempestivamente i potenziali ostacoli, ridurre il rischio di fallimento della migrazione e prendere decisioni informate sull'architettura di destinazione.

La valutazione del codice applicativo individua quattro categorie di problemi che la scansione dell'infrastruttura non è in grado di rilevare:

Blocchi di compatibilità , API, framework o funzionalità di runtime che non esistono o si comportano in modo diverso nell'ambiente cloud di destinazione. Un'applicazione Java creata per un server di applicazioni Java EE non disponibile nel servizio PaaS di destinazione richiede modifiche al codice prima di poter essere distribuita. Un'applicazione che utilizza una convenzione di percorso file specifica di Windows non può essere eseguita su un'istanza cloud basata su Linux senza modifiche.

Presupposti infrastrutturali hardcoded , indirizzi IP, percorsi del file system, nomi di server o numeri di porta incorporati nel codice non saranno più validi nell'ambiente cloud. Questi rappresentano ostacoli alla migrazione che nessuna scansione dell'infrastruttura rileverà perché si trovano all'interno del codice dell'applicazione e non nella configurazione dell'infrastruttura.

Utilizzo di API obsolete : chiamate ad API, librerie o funzionalità della piattaforma non supportate o superate dall'ambiente cloud di destinazione. I fornitori di piattaforme cloud deprecano regolarmente le versioni obsolete delle API e le applicazioni che le utilizzano non funzioneranno sulla nuova piattaforma, anche se oggi funzionano correttamente.

La complessità delle dipendenze , ovvero la struttura interna dell'applicazione, determina la difficoltà di migrazione e la possibilità di suddividerla in servizi distribuibili in modo indipendente. Un'applicazione monolitica con un elevato accoppiamento interno è più difficile e costosa da migrare rispetto a un'applicazione a basso accoppiamento, a prescindere da quanto riportato nell'inventario dell'infrastruttura.

CAST Highlight esegue una valutazione automatizzata del codice sorgente delle applicazioni a livello di portfolio, analizzando il codice sorgente in diversi linguaggi per generare punteggi di compatibilità con il cloud, identificare i potenziali ostacoli e analizzare i rischi legati all'open source. È citato nel framework di adozione del cloud Azure di Microsoft come strumento consigliato per carichi di lavoro non .NET e non Java.

CloudPilot è specializzata nella valutazione dettagliata della predisposizione al cloud, con punteggio di compatibilità e generazione di roadmap di migrazione per JavaScript, Python, Node.js e Go.

GitHub Copilot App Modernization combina le funzionalità di valutazione AppCAT di CAST con la correzione del codice assistita dall'intelligenza artificiale, specificamente per carichi di lavoro .NET e Java.

Per gli ambienti aziendali che comprendono COBOL, JCL, PL/I, RPG e altri linguaggi mainframe, oltre a stack moderni, questi strumenti non sono sufficienti. La valutazione del codice applicativo per i sistemi legacy richiede una categoria di strumenti completamente diversa.

Valutazione dei dati

La valutazione dei dati determina la complessità, il volume, i requisiti di conformità e il metodo di migrazione per ogni archivio dati interessato. Viene spesso sottovalutata perché a prima vista sembra semplice – spostare il database, spostare i dati – finché non emerge la reale complessità.

Le domande chiave a cui la valutazione dei dati deve rispondere:

Volume e velocità di trasmissione : quanti dati sono presenti? Qual è la frequenza di variazione? È possibile migrare i dati senza interruzioni del servizio, oppure è necessario utilizzare la replica continua per ottenere un passaggio con tempi di inattività prossimi allo zero?

Compatibilità dello schema : il servizio di database di destinazione supporta le stesse funzionalità di schema, tipi di dati e stored procedure del database di origine? Le strutture PL/SQL specifiche di Oracle richiedono la conversione prima della migrazione a PostgreSQL o a un'alternativa cloud-native.

Sovranità dei dati e conformità : dove devono risiedere legalmente i dati? Il GDPR, l'HIPAA, il PCI-DSS e le normative specifiche di settore possono limitare le regioni cloud in cui è possibile ospitare determinate categorie di dati.

Accoppiamento dell'applicazione : quanto è stretto il legame tra il codice dell'applicazione e lo schema specifico del database? Una modifica dello schema, tecnicamente semplice, potrebbe richiedere ampie modifiche al codice dell'applicazione per essere implementata.

AWS Database Migration Service e Azure Database Migration Service supportano la replica continua con tempi di inattività minimi per le migrazioni omogenee (da Oracle a Oracle, da SQL Server a SQL Server) e la conversione dello schema per le migrazioni eterogenee (da Oracle a PostgreSQL, da SQL Server ad Aurora).

Striim e Attunity offrono streaming e replica dei dati in tempo reale per scenari di migrazione ad alta disponibilità in cui i tempi di inattività del database sono inaccettabili.

Valutazione della sicurezza e della conformità

La valutazione della sicurezza mappa lo stato attuale della sicurezza di ciascun carico di lavoro e identifica le modifiche necessarie per soddisfare gli standard di sicurezza del cloud, i framework di conformità e i principi dell'architettura zero-trust.

Le dimensioni che la valutazione della sicurezza deve coprire sono:

Gestione delle identità e degli accessi (IAM) : le applicazioni on-premise spesso utilizzano account di servizio con ampi permessi e autenticazione basata su password. Gli ambienti cloud richiedono il controllo degli accessi basato sui ruoli, identità di servizio con privilegi minimi e autenticazione basata su certificati o token. Il divario tra l'IAM attuale e quello richiesto è un problema di migrazione che non ha nulla a che vedere con l'inventario dell'infrastruttura.

Crittografia : i requisiti di crittografia dei dati a riposo e in transito differiscono tra ambienti on-premise e cloud. Le applicazioni che gestiscono la propria crittografia a livello applicativo devono integrarsi con i servizi di gestione delle chiavi del cloud. Gli archivi di dati non crittografati, accettabili su reti private, richiedono la crittografia prima di essere spostati su servizi ospitati nel cloud.

Sicurezza di rete : le regole del firewall, la segmentazione di rete e l'ispezione del traffico implementate nell'hardware di rete locale devono essere ricostruite come gruppi di sicurezza cloud, configurazioni di rete virtuali e regole firewall native del cloud.

Allineamento con il framework di conformità : ogni settore regolamentato ha requisiti di conformità specifici che corrispondono a configurazioni cloud specifiche. I carichi di lavoro HIPAA richiedono scelte di configurazione specifiche per quanto riguarda archiviazione, registrazione degli accessi e crittografia. Il PCI-DSS richiede la segmentazione della rete, che deve essere implementata in modo diverso in una VPC cloud rispetto a un'infrastruttura di rete fisica.

Microsoft Defender for Cloud offre una valutazione della postura di sicurezza e una verifica della conformità rispetto ai benchmark CIS, NIST, PCI-DSS e altri framework per i carichi di lavoro di Azure.

Prisma Cloud (Palo Alto Networks) e AWS Security Hub offrono servizi equivalenti di valutazione della sicurezza multi-cloud e monitoraggio della conformità.

Valutazione dei costi e del costo totale di proprietà (TCO)

La valutazione dei costi è il risultato più visibile della migrazione per gli stakeholder aziendali, ma anche quello che più spesso viene prodotto in modo errato. L'errore più comune consiste nel confrontare i costi attuali dell'hardware on-premise con i costi di elaborazione e archiviazione nel cloud, il che produce un confronto incompleto e solitamente fuorviante.

Una valutazione completa del TCO (Total Cost of Ownership) comprende:

Costi dell'infrastruttura cloud : costi di elaborazione, archiviazione, rete e servizi gestiti nella configurazione cloud di destinazione. Il dimensionamento corretto basato sui dati di utilizzo effettivi (non sulla capacità allocata) è ciò che distingue le stime accurate da quelle gonfiate.

Costi di migrazione : le ore di lavoro degli ingegneri necessarie per completare le modifiche al codice dell'applicazione, la migrazione dei dati, la riconfigurazione della sicurezza e i test. Le valutazioni basate esclusivamente sull'infrastruttura tendono a sottovalutare sistematicamente questo aspetto, poiché non tengono conto della complessità dell'applicazione.

Modifiche alle licenze : il passaggio da licenze perpetue on-premise a modelli di licenza basati sul cloud, o da software specifici di un fornitore ad alternative native del cloud, modifica radicalmente la struttura dei costi di licenza.

Cambiamenti nel modello operativo : i team operativi on-premise che gestiscono l'hardware fisico vengono sostituiti da team operativi cloud che gestiscono i servizi cloud. Cambiano le competenze, gli strumenti e l'organico.

Costi di formazione e transizione : i team che apprendono nuove piattaforme cloud, nuovi modelli di implementazione e nuove procedure operative sostengono costi di produttività durante la transizione.

AWS Pricing Calculator , Azure TCO Calculator e Google Cloud Pricing Calculator affrontano la dimensione dei costi dell'infrastruttura cloud. Infracost fornisce stime dei costi integrate nelle pipeline IaC, producendo stime dei costi come parte del processo CI/CD. Apptio Cloudability e strumenti FinOps simili forniscono visibilità continua sui costi dopo la migrazione.

Le sette strategie migratorie: come la valutazione determina quale si applica

Il framework "7 R" descrive le strategie disponibili per ogni migrazione di carico di lavoro. La valutazione determina quale strategia sia appropriata e, se la valutazione è errata, si finisce per applicare la strategia sbagliata, che è la causa principale della maggior parte degli sforamenti di budget dovuti alle migrazioni.

Online	Cosa significa	Segnale di valutazione che lo suggerisce
Riospitare (sollevamento e spostamento)	Passa al cloud senza modifiche al codice.	Bassa complessità applicativa, nessun blocco di compatibilità, compatibile con l'infrastruttura.
Ripiattaforma	Modifiche minori per sfruttare i servizi cloud (ad esempio, passaggio a un database gestito)	Accoppiamento moderato, opportunità di aggiornamento della piattaforma specifica, ambito di modifica del codice accettabile
Refactoring	Riprogettare l'architettura per adottare modelli cloud-native (microservizi, container).	Elevato accoppiamento monolitico, significativi requisiti di scalabilità, giustificati dalla crescita prevista del traffico.
Riarchitettare	Riprogettazione significativa dell'architettura dell'applicazione.	Applicazione fondamentalmente incompatibile con il cloud; la nuova architettura offre importanti vantaggi aziendali.
Ricostruire	Riscrivere da zero	L'intervento è troppo costoso per essere riparato; la sostituzione è più economica della bonifica.
sostituire	Abbandona l'applicazione personalizzata e adotta un'alternativa SaaS.	L'applicazione offre funzionalità standard che possono essere gestite meglio da un servizio cloud esistente.
Andare in pensione	Dismissione, l'applicazione non è più necessaria	Applicazione identificata come non più valida, ridondante o superata durante la valutazione

L'inventario dell'infrastruttura non è in grado di distinguere tra candidati per Rehost, Replatform, Refactor e Rebuild, poiché a livello di infrastruttura appaiono tutti identici. È la valutazione del codice applicativo che permette di effettuare questa distinzione.

Valutazione della migrazione al cloud per sistemi legacy e mainframe

Gli strumenti standard di valutazione della migrazione al cloud sono progettati per infrastrutture moderne: macchine virtuali, container, microservizi e applicazioni cloud-native. Le loro prestazioni sono scarse o nulle per carichi di lavoro mainframe, programmi COBOL in esecuzione su IBM z/OS, flussi di lavoro JCL per la gestione dell'elaborazione batch, applicazioni PL/I per la gestione di transazioni finanziarie e programmi RPG integrati in sistemi AS/400.

La valutazione della migrazione dei mainframe al cloud richiede un approccio fondamentalmente diverso, perché il vincolo non risiede nello strato infrastrutturale. Il vincolo è rappresentato dal codice applicativo, da decenni di logica aziendale accumulata, dalle dipendenze implicite attraverso dataset e copybook condivisi e dai comportamenti in fase di esecuzione che nessuna scansione dell'infrastruttura può rivelare.

Le otto analisi necessarie prima di poter pianificare in modo responsabile qualsiasi migrazione di mainframe (inventario dei programmi, mappatura delle dipendenze, estrazione della logica di business, identificazione del codice inutilizzato, classificazione della complessità, analisi della pianificazione dei batch, valutazione della qualità dei dati e mappatura dell'integrazione) sono descritte in dettaglio nel contesto della riduzione dei rischi della migrazione di mainframe . Ciascuna di queste è un'attività di valutazione a livello di codice, non un'attività di valutazione dell'infrastruttura.

Confronto tra strumenti di valutazione per la migrazione al cloud

La tabella seguente associa i principali strumenti di valutazione della migrazione al cloud alla dimensione di valutazione a cui si riferiscono e allo scenario più adatto.

Chiavetta	Livello di valutazione	bersaglio nuvola	Ideale per
Migrazione azzurra	Infrastruttura	azzurro	Individuazione e dimensionamento ottimale di macchine virtuali e server, stima dei costi di Azure.
Servizio di individuazione delle applicazioni AWS	Infrastruttura	AWS	Individuazione dei server locali per le migrazioni AWS
Centro migrazioni di Google	Infrastruttura	GCP	Inventario delle risorse e costo totale di proprietà (TCO) per le migrazioni a GCP
CAST in evidenza	Codice dell'applicazione	Multinuvola	Valutazione della prontezza del codice su scala di portfolio per diversi linguaggi di programmazione.
CloudPilot	Codice dell'applicazione	Multinuvola	Analisi dettagliata della compatibilità per Python, JS, Node.js, Go
SMART TS XL	Codice applicativo + mappatura delle dipendenze	Multinuvola	Analisi del portfolio COBOL, JCL, mainframe e multilingue.
AWS DMS	Dati	AWS	Migrazione del database con conversione dello schema
Servizio di migrazione del database di Azure	Dati	azzurro	Migrazione di SQL Server, MySQL e PostgreSQL ad Azure.
Strim	Dati	Multinuvola	Replica in tempo reale per una migrazione dei dati senza interruzioni.
Microsoft Defender per il cloud	Sicurezza	Azure / Multi-cloud	Valutazione della postura di sicurezza e della conformità
nuvola prismatica	Sicurezza	Multinuvola	CSPM e conformità su AWS, Azure e GCP
Infracosto	Costo	Multinuvola	Stima dei costi integrata con IaC nelle pipeline CI/CD
Apptio Cloudabilità	Costo	Multinuvola	FinOps e gestione continua dei costi del cloud
Corent SurPaaS	Infrastruttura + applicazione	Multinuvola	Scoperta, valutazione e orchestrazione della migrazione basate sull'intelligenza artificiale

Come SMART TS XL Esegue la valutazione del codice applicativo per la migrazione al cloud.

SMART TS XL Affronta il livello di valutazione del codice applicativo che gli strumenti di infrastruttura non possono raggiungere, in particolare per gli ambienti aziendali e legacy in cui il portfolio applicativo si estende su più linguaggi, piattaforme e generazioni tecnologiche.

Per un programma di migrazione che include programmi COBOL, flussi di lavoro JCL, servizi Java, pipeline Python e schemi SQL, SMART TS XL crea un modello di dipendenza unificato su tutti contemporaneamente. Prima che il team di migrazione decida cosa rihostare, cosa rifattorizzare e cosa ritirare, SMART TS XL fornisce:

Inventario completo dei programmi : ogni programma sorgente, copybook, procedura e schema in ogni linguaggio presente nell'ambiente, ovvero l'inventario effettivo, non quello documentato, che negli ambienti legacy in genere presenta una discrepanza del 20-30%.

Mappatura delle dipendenze tra linguaggi diversi : la funzionalità di mappatura delle dipendenze dell'applicazione traccia il modo in cui un programma COBOL si connette a uno schema DB2 interrogato da un servizio Java, che alimenta una pipeline Python che produce un output utilizzato da un moderno frontend React. Questa catena di dipendenze tra linguaggi diversi determina la sequenza di migrazione: i componenti con molte dipendenze devono essere migrati solo dopo che le rispettive dipendenze sono pronte.

Identificazione del codice inutilizzato : i programmi e le procedure che non vengono mai richiamati da alcun percorso di esecuzione in produzione possono essere completamente esclusi dall'ambito della migrazione. In ambienti legacy di grandi dimensioni, ciò rappresenta in genere il 10-25% dell'inventario totale, consentendo una significativa riduzione dei costi già in fase di valutazione.

Classificazione della complessità : la funzionalità di analisi statica del codice classifica ogni programma in base alla complessità ciclomica, al numero di dipendenze del copybook, al numero di chiamate e ad altre metriche che determinano la difficoltà di migrazione. I programmi ad alta complessità con molte chiamate sono candidati per la refactoring o la ricostruzione. I programmi a bassa complessità e con poche dipendenze sono candidati per il rehosting.

Analisi d'impatto prima di qualsiasi modifica : la capacità di analisi d'impatto risponde alla domanda "cosa verrà influenzato se questo programma cambia?" prima dell'inizio di qualsiasi attività di migrazione, trasformando il rischio sconosciuto in un ambito strutturato e dettagliato.

Per le organizzazioni che pianificano programmi di migrazione da mainframe a cloud, SMART TS XL'S modernizzazione dell'eredità L'analisi produce la valutazione preliminare alla migrazione richiesta dai fornitori di servizi di migrazione prima dell'inizio dei lavori di conversione: inventario strutturale completo, grafico delle dipendenze, classificazione della complessità e report sull'esclusione del codice inutilizzato.

Cosa dovrebbe produrre una valutazione completa della migrazione al cloud

Una valutazione è valida solo nella misura in cui consente di prendere decisioni. Una valutazione completa della migrazione al cloud dovrebbe produrre cinque risultati che, nel loro insieme, definiscono il programma di migrazione:

Inventario del portfolio applicativo con assegnazione della strategia di migrazione : ogni applicazione inclusa nell'ambito è classificata come Rehost, Replatform, Refactor, Rearchitect, Rebuild, Replace o Retire, con la documentazione di valutazione a supporto di ciascuna classificazione.

Piano di migrazione a ondate basato sulle dipendenze : la sequenza in cui le applicazioni dovrebbero migrare, derivata dal grafo delle dipendenze anziché da raggruppamenti arbitrari. Le applicazioni senza dipendenze in entrata da altre applicazioni incluse nell'ambito della migrazione possono migrare nelle prime ondate. Le applicazioni da cui dipendono molte altre applicazioni migrano nelle ondate successive, dopo che le applicazioni dipendenti sono pronte.

Costo totale stimato della migrazione : impegno ingegneristico, costi degli strumenti di migrazione, costi di esecuzione parallela temporanea e costi di formazione, non solo differenze di costo dell'infrastruttura.

Modello TCO post-migrazione : spesa cloud prevista in base a configurazioni di dimensioni adeguate e dati di utilizzo effettivi, confrontata con i costi operativi on-premise attuali, con ipotesi realistiche sui cambiamenti di licenza e sulle transizioni del modello operativo.

Registro dei rischi : i rischi identificati, i blocchi di compatibilità, le migrazioni di dati complesse, le dipendenze non documentate, i vincoli di conformità, con la relativa probabilità, l'impatto e le misure di mitigazione proposte per ciascuno.

Le organizzazioni che producono tutti e cinque questi documenti prima dell'inizio della migrazione dispongono delle informazioni necessarie per garantire il successo del programma. Le organizzazioni che tralasciano la valutazione del codice applicativo, la valutazione dei dati o la valutazione della sicurezza producono versioni incomplete di questi documenti e scoprono le lacune durante la migrazione, quando ogni problema scoperto ha un costo maggiore da risolvere.