Pianificare la migrazione

Un piano di migrazione definisce l'ordine, la tempistica e l'approccio specifici per la migrazione dei carichi di lavoro in Azure. Questo piano converte le strategie di migrazione di alto livello in sequenze di distribuzione interattivi. Si basa sul piano di adozione del cloud risolvendo decisioni tattiche come la definizione delle priorità dei carichi di lavoro, la sequenziazione della migrazione e i metodi di trasferimento dei dati.

Prerequisiti:Piano di adozione della migrazione, zona di destinazione di Azure

Valutare l'idoneità e le competenze della migrazione

Una valutazione dell'idoneità garantisce che il team disponga delle competenze e del supporto necessari per eseguire il piano di migrazione. Questo passaggio identifica le lacune delle funzionalità e accelera lo stato di avanzamento attraverso la formazione mirata o il supporto esterno.

1. Valutare le competenze di Azure del team. Esaminare l'esperienza del team con i servizi di Azure, gli strumenti di migrazione e il cutover. Questa valutazione consente di identificare lacune specifiche delle conoscenze e determinare quale formazione deve avere esito positivo.

2. Coinvolgere le competenze esterne quando necessario. Se il team non ha esperienza con la migrazione cloud, contattare Microsoft o un partner Microsoft. Gli esperti esterni possono convalidare la strategia di migrazione, consigliare strumenti appropriati e contribuire a definire sequenze temporali realistiche. Questo supporto riduce i rischi e accelera la migrazione, soprattutto per progetti complessi o su larga scala.

Scegliere il percorso di migrazione dei dati

Un percorso di migrazione dei dati è il modo in cui si spostano i dati dalla posizione corrente ad Azure. Il percorso corretto garantisce i trasferimenti di dati in modo sicuro, rapido e conveniente. Prima di tutto, controllare quali connessioni di rete sono disponibili, ExpressRoute, VPN o Internet pubblico per comprendere le opzioni disponibili.

1. Usare ExpressRoute quando è disponibile. ExpressRoute offre una connessione privata e dedicata ad Azure più veloce e sicura rispetto alle connessioni Internet. Se si ha già ExpressRoute o si prevede di ottenerlo, usare questo metodo per tutti i carichi di lavoro. Tenere presente che ExpressRoute richiede tempo di configurazione e ha costi di trasferimento dei dati.

2. Usare VPN se ExpressRoute non è disponibile. Scegli una VPN quando è necessario il trasferimento sicuro dei dati, se non hai ExpressRoute. Una VPN crea un tunnel crittografato tramite Internet in Azure, anche se in genere è più lento rispetto a ExpressRoute. Assicurarsi di avere un gateway VPN configurato in Azure prima di iniziare.

3. Usare Azure Data Box per grandi quantità di dati. Data Box è ideale per le migrazioni offline con un numero elevato di dati. Microsoft ti invia un dispositivo fisico su cui copiare i tuoi dati, quindi tu lo rispedisci indietro. Questa opzione evita l'uso della rete, ma richiede più tempo a causa del tempo di spedizione.

4. Usare Internet pubblico per dati meno sensibili. Questa opzione funziona quando i dati non richiedono la crittografia e non è possibile usare ExpressRoute o Data Box. Anche se questo metodo è disponibile ovunque, è il meno sicuro e può rallentare le altre attività Internet.

Determinare la sequenza di migrazione

La sequenziazione della migrazione riduce i rischi e crea la fiducia del team stabilendo un ordine logico per la migrazione del carico di lavoro. La sequenza determina i carichi di lavoro che si spostano per primi e il modo in cui i componenti dipendenti vengono migrati insieme per evitare interruzioni del servizio. Organizzare grandi portfolio in onde di migrazione. Per indicazioni dettagliate sulla pianificazione delle onde, vedere Pianificazione delle onde della migrazione.

Trovare le dipendenze

1. Individuare prima tutte le dipendenze. Le dipendenze tra carichi di lavoro causano interruzioni del servizio se non viene eseguita la migrazione insieme. Eseguire il mapping delle dipendenze interne ed esterne per individuare queste connessioni prima di creare gruppi di migrazione.

2. Analizzare i tipi di dipendenza e la criticità. Diversi tipi di dipendenza richiedono approcci di migrazione diversi. Distinguere tra queste categorie:

   Tipo di dipendenza	Description	Approccio alla migrazione
   Dipendenze dirette	Richiedere comunicazioni immediate e bassa latenza tra i componenti.	Spostare tutti i componenti connessi direttamente insieme per mantenere le prestazioni ed evitare interruzioni.
   Dipendenze indirette	Coinvolgere interazioni occasionali o non critiche tra sistemi.	Eseguire la migrazione insieme o in onde separate se la connessione tollera la latenza o supporta l'uso ibrido.
   Dipendenze aziendali	Dipende dalle relazioni organizzative o di gestione.	Raggruppare ed eseguire la migrazione di carichi di lavoro e sistemi di report correlati per allinearsi alle priorità aziendali.

3. Raggruppare i carichi di lavoro in base alle relazioni di dipendenza. Creare gruppi basati su database condivisi, API, servizi di autenticazione o connessioni di rete. Questi gruppi costituiscono la base delle onde di migrazione e assicurano che tutti i componenti necessari per la funzionalità si spostino insieme. Quando esistono incertezze sulla criticità delle dipendenze, raggruppare i componenti. Questo approccio conservativo offre flessibilità per la separazione futura.

4. Documentare sistematicamente ogni gruppo di dipendenze. Contrassegna gli asset in base ai gruppi di dipendenze usando convenzioni di denominazione coerenti. Documentare ogni gruppo con:

   • Nome e ID del gruppo - Identificatore univoco e nome descrittivo
   • Inventario dei componenti - Tutti gli elementi dell'infrastruttura, le applicazioni e i servizi
   • Dipendenze critiche - Connessioni essenziali che richiedono una gestione speciale
   • Vincoli di migrazione - Requisiti aziendali, tecnici o temporali

5. Convalidare la completezza del gruppo. Verificare che ogni gruppo includa tutti i componenti necessari per il funzionamento delle applicazioni, tra cui l'infrastruttura di supporto, ad esempio servizi di bilanciamento del carico, record DNS o livelli di memorizzazione nella cache.

Gestire le operazioni su ambienti separati

1. Pianificare le dipendenze inamovibili. Identificare i componenti che devono rimanere nell'ambiente di origine a causa di motivi tecnici o normativi. Documentare perché non possono spostarsi, come si connettono ad altri sistemi e quali dati condividono. Questa documentazione consente di creare strategie per questi componenti per funzionare senza problemi con i sistemi cloud.

2. Ridurre al minimo il tempo di funzionamento dell'ambiente diviso. Quando i componenti possono passare al cloud in un secondo momento ma non immediatamente, documentare le connessioni e i flussi di dati con i sistemi cloud. Creare un piano chiaro con sequenze temporali e approcci di gestione dei rischi per ridurre il tempo di funzionamento del carico di lavoro in entrambi gli ambienti. Valutare la possibilità di ritardare la migrazione fino a quando altri componenti non possono spostarsi insieme.

3. Connettere gli ambienti in modo efficace. Usare metodi di integrazione come gateway API, code di messaggi e sincronizzazione dei dati per creare connessioni affidabili tra i carichi di lavoro cloud e i componenti dell'ambiente di origine. Questi approcci riducono i ritardi, migliorano la sicurezza e preparano il modo per spostare i componenti rimanenti nel cloud.

Assegnare priorità ai carichi di lavoro da migrare

1. Esaminare i dettagli del carico di lavoro. Collaborare con gli stakeholder per esaminare i dettagli aziendali e tecnici per ogni carico di lavoro. Assicurarsi che l'impatto sui tempi di inattività o sugli errori sia ben compreso e allineato alle priorità aziendali correnti. Usare il piano di adozione della migrazione per verificare dettagli come unità aziendale, proprietario del carico di lavoro, dipendenze tecniche e classificazione della criticità. Questi dettagli consentono di classificare in ordine di priorità e sequenza i carichi di lavoro in modo efficace.

   Priority	Valore aziendale	Effort	Description
   High	High	Low	Vantaggi immediati: attuare la migrazione prima per un impatto subito
   Medium-High	High	High	Investimenti strategici - pianificare attentamente con risorse adeguate
   Medium-Low	Low	Low	Candidati facili: colmare le lacune tra le migrazioni principali
   Low	Low	High	Evitare o rinviare: concentrarsi sulle risorse sulle opportunità di valore più elevato

2. Iniziare con carichi di lavoro più semplici per ridurre i rischi. Iniziare a eseguire la migrazione di carichi di lavoro meno complessi e con un rischio inferiore. Questo approccio consente al team di acquisire fiducia e perfezionare i processi di migrazione prima di affrontare carichi di lavoro più complessi. Rivolgere verso gli strumenti interni, gli ambienti di sviluppo o le applicazioni a basso utilizzo con architetture autonome e punti di integrazione minimi.

3. Spostare gli ambienti non di produzione prima di quelli di produzione. Gli ambienti non di produzione offrono uno spazio sicuro per testare il processo di migrazione completo. Eseguire la migrazione di ambienti di sviluppo, gestione temporanea e controllo di qualità prima della produzione per convalidare l'idoneità. Questo ordine consente ai team di testare configurazioni, prestazioni e procedure di ripristino senza influire sugli utenti. Usare migrazioni non di produzione per eseguire il training dei team operativi.

4. Pianificare i sistemi critici dopo aver dimostrato il successo iniziale. Le applicazioni critiche richiedono funzionalità di migrazione comprovate prima di spostarle in Azure. Pianificare queste migrazioni per le fasi successive quando il team dimostra la competenza con i servizi di Azure. Le scadenze aziendali, ad esempio i cicli di aggiornamento hardware, potrebbero richiedere di assegnare priorità alle applicazioni critiche in precedenza con più misure di sicurezza e periodi di test estesi.

5. Includere carichi di lavoro complessi rappresentativi per testare gli scenari. Aggiungere uno o due carichi di lavoro complessi a ciascuna ondata iniziale per mettere in luce le sfide affrontate con le applicazioni mission-critical. Scegliere i carichi di lavoro che rappresentano modelli comuni, ad esempio applicazioni multilivello o sistemi dipendenti dal database.

Creare una pianificazione dettagliata della migrazione

1. Impostare le date di inizio e di fine per ogni migrazione. Includere il tempo del buffer per il test e la risoluzione dei problemi per garantire un'esecuzione uniforme. Questa pianificazione dettagliata riduce il rischio di ritardi e supporta una pianificazione efficace delle risorse.

2. Allineare le sequenze temporali agli eventi aziendali. Evitare di pianificare le migrazioni durante periodi aziendali critici, ad esempio chiusura finanziaria, lancio di prodotti o stagioni festivi. Questo allineamento riduce il rischio di interruzioni aziendali e garantisce la fiducia degli stakeholder.

3. Usare gli strumenti di gestione dei progetti per tenere traccia dello stato di avanzamento. Usare strumenti come Azure DevOps per gestire le dipendenze, tenere traccia delle attività cardine e comunicare in modo efficace le modifiche. Questi strumenti offrono visibilità sullo stato della migrazione e supportano la risoluzione proattiva dei problemi.

Scegliere il metodo di migrazione per ogni carico di lavoro

I metodi di migrazione rientrano in due categorie: migrazione con tempi di inattività e migrazione con tempi di inattività quasi zero. Scegliere il metodo di migrazione migliore per ogni carico di lavoro in base alla tolleranza di inattività e alla criticità aziendale.

1. Scegliere la migrazione con tempi di inattività per i carichi di lavoro che tollerano fermi pianificati. La migrazione dei tempi di inattività è più semplice e veloce perché non richiede la sincronizzazione in tempo reale tra gli ambienti di origine e di destinazione. Questo metodo funziona bene per carichi di lavoro non critici, ad esempio ambienti di sviluppo, sistemi di test o applicazioni con finestre di manutenzione pianificate. Documentare la durata del tempo di inattività accettabile per ogni carico di lavoro e pianificare le migrazioni durante periodi di basso utilizzo per ridurre al minimo gli effetti aziendali.

2. Scegliere la migrazione a quasi zero tempi di inattività per carichi di lavoro critici. La migrazione con tempi di inattività quasi nulli garantisce che i carichi di lavoro critici rimangano operativi durante la transizione tramite tecniche di replica continua dei dati e commutazione. Questo metodo è essenziale per applicazioni rivolte ai clienti, sistemi di transazioni in tempo reale o carichi di lavoro con contratti di servizio rigorosi. Verificare che l'architettura del carico di lavoro supporti la replica continua e che la larghezza di banda di rete possa gestire il trasferimento dei dati in tempo reale. Testare i processi di connettività e replica in un ambiente non di produzione per confermare l'idoneità per questo metodo di migrazione.

Definire il piano di rollback

Un piano di rollback consente ai team di invertire rapidamente le modifiche quando una distribuzione ha esito negativo o introduce rischi. Un piano ben definito riduce al minimo i tempi di inattività, limita l'impatto aziendale e mantiene l'affidabilità del sistema. Stabilire sempre criteri e procedure di rollback prima di avviare qualsiasi migrazione o distribuzione.

1. Definire l'implementazione non riuscita. Collaborare con stakeholder aziendali, proprietari dei carichi di lavoro e team operativi per decidere cosa costituisce una distribuzione fallita. Gli esempi includono controlli di integrità non riusciti, prestazioni scarse, problemi di sicurezza o metriche di successo non soddisfatte. Questa definizione garantisce che le decisioni di rollback siano allineate alla tolleranza ai rischi dell'organizzazione. Includere condizioni specifiche che attivano un rollback nel piano di distribuzione, ad esempio limiti di utilizzo della CPU, soglie del tempo di risposta o percentuali di errore. Questa valutazione rende chiare e coerenti le decisioni di rollback durante gli eventi imprevisti.

2. Automatizzare i passaggi di roll-back nelle pipeline CI/CD. Usare strumenti come Azure Pipelines o GitHub Actions per automatizzare i processi di rollback. Ad esempio, configurare le pipeline per ridistribuire una versione precedente se i controlli di integrità hanno esito negativo.

3. Creare istruzioni di rollback specifiche per i workload. Sviluppare i passaggi di rollback che corrispondono al tipo di carico di lavoro, all'ambiente e al metodo di distribuzione. Ad esempio, le distribuzioni di infrastruttura come codice richiedono la riapplicazione dei modelli precedenti. I rollback dell'applicazione comportano la ridistribuzione di un'immagine del contenitore precedente. Allega script di rollback, snapshot di configurazione e modelli di infrastruttura come codice al piano di rollback. Questi asset consentono l'esecuzione rapida e riducono la dipendenza dall'intervento manuale.

4. Testare le procedure di rollback. Simulare gli errori di distribuzione in un ambiente di preproduzione per convalidare l'efficacia del rollback. Identificare e risolvere le lacune nell'automazione, nelle autorizzazioni o nelle dipendenze. Verificare che il rollback ripristini il sistema in uno stato stabile, conosciuto e affidabile.

5. Migliorare le strategie di rollback Dopo ogni evento di distribuzione o rollback, eseguire un'analisi retrospettiva per valutare cosa ha funzionato e cosa non ha funzionato. Aggiornare criteri, procedure e automazione del rollback in base a lezioni apprese, modifiche dell'architettura o nuovi strumenti. Gestire la documentazione per garantire che le strategie di rollback rimangano aggiornate ed efficaci.

Coinvolgere gli stakeholder nel piano di migrazione

L'approvazione degli stakeholder convalida il piano di migrazione soddisfa i requisiti aziendali e la tolleranza ai rischi. È consigliabile ottenere l'approvazione formale prima di eseguire le migrazioni.

1. Documentare il piano di migrazione con giustificazione aziendale. Creare un piano strutturato che mostra il nome del carico di lavoro, il proprietario, la criticità, il metodo di migrazione, la finestra di inattività e gli effetti aziendali. Includere la logica per ogni approccio e spiegare in che modo riduce al minimo i rischi.

2. Presentare le procedure di rollback testate. Mostra piani di rollback specifici con passaggi, intervalli di tempo e criteri di esito positivo. Includere funzionalità automatizzate e manuali. Documentare i risultati dei test di preproduzione per dimostrare un ripristino rapido del servizio.

3. Convalidare le pianificazioni in base ai vincoli aziendali. Esaminare le sequenze temporali con gli stakeholder per evitare periodi aziendali critici, blocchi di manutenzione e picchi stagionali. Fornire opzioni alternative con compromessi in caso di conflitti.

4. Ottenere l'approvazione formale e la facoltà di rollback. Ottenere l'approvazione scritta dai responsabili per il piano di migrazione e le procedure di rollback. Definire l'autorità decisionale e stabilire canali di comunicazione di emergenza.

5. Definire criteri di successo e punti di controllo della revisione. Impostare metriche misurabili, inclusi benchmark delle prestazioni, convalida delle funzionalità e criteri di accettazione utente. Pianifica i punti di revisione formali per le decisioni di go/no-go.

Passo successivo