Prospettiva del processo

I processi garantiscono coerenza, ma si evolvono e sono suscettibili di cambiamento perché ogni progetto è unico. Eseguendo ripetutamente il processo, identificherai le lacune e i margini di miglioramento che possono portare enormi vantaggi in caso di fallimento, apprendimento, adozione e iterazione. Questi cambiamenti possono portare a nuove idee o innovazioni di cui il progetto e l'azienda possono trarre vantaggio in futuro, il che fornisce un catalizzatore per la crescita che porta qualità e fiducia nel team.

I processi di migrazione possono essere complessi in quanto attraversano tecnologie e confini che potrebbero non essere stati collegati in precedenza. Questa prospettiva fornisce processi e linee guida sui requisiti specifici per le migrazioni di grandi dimensioni.

Preparazione per una migrazione su larga scala

Le sezioni seguenti descrivono i principi fondamentali necessari per garantire che il percorso di migrazione inizi con una direzione chiara e il consenso delle parti interessate, che sarà fondamentale per il suo successo.

In questa sezione:

• Definisci i fattori di business e comunica tempistica, ambito e strategia

• Definite un percorso di escalation chiaro per aiutare a rimuovere i blocchi

• Minimizza le modifiche non necessarie

• Documenta un end-to-end processo in anticipo

• Documenta modelli e artefatti di migrazione standard

• Stabilite un'unica fonte attendibile per i metadati e lo stato della migrazione

Definisci i fattori di business e comunica tempistica, ambito e strategia

Quando ti avvicini a una migrazione su larga AWS scala verso, scoprirai rapidamente che esistono numerosi modi per migrare i tuoi server. Ad esempio, è possibile eseguire le operazioni seguenti:

• Riorganizza i carichi di lavoro utilizzando. AWS Application Migration Service

• Containerizza la tua applicazione e ospitala sulla piattaforma di container gestiti Amazon Elastic Container Service (Amazon ECS) o Amazon Elastic Kubernetes Service (Amazon EKS).

• Riprogetta il tuo carico di lavoro in un'applicazione completamente serverless.

Per determinare il percorso di migrazione corretto, è importante partire dai fattori di business a ritroso. Se il vostro obiettivo finale è aumentare l'agilità aziendale, potreste preferire i secondi due modelli, che prevedono più livelli di trasformazione. Se il tuo obiettivo è quello di liberare un data center entro la fine dell'anno, potresti scegliere di riospitare i carichi di lavoro a causa della velocità offerta dal rehosting.

Una migrazione su larga scala coinvolge in genere un'ampia gamma di parti interessate, tra cui:

• Proprietari delle applicazioni

• Team di rete

• Amministratori di database

• Sponsor esecutivi

È fondamentale identificare i fattori di business alla base della migrazione e includere tale elenco in un documento, ad esempio una carta del progetto a cui possono accedere i membri del programma di migrazione. Inoltre, create indicatori chiave di performance (KPIs) che siano strettamente allineati ai risultati aziendali prefissati.

Ad esempio, un cliente desiderava migrare 2.000 server entro 12 mesi per raggiungere l'obiettivo aziendale che si era prefissato, ossia lo smantellamento del data center. Tuttavia, i loro team di sicurezza non erano allineati verso questo obiettivo. Il risultato sono stati diversi mesi di dibattiti tecnici sull'opportunità di non rispettare la data di chiusura del data di chiusura del data center ma modernizzare ulteriormente le applicazioni o riorganizzarle inizialmente per consentire la chiusura tempestiva del data center e poi modernizzare le applicazioni. AWS

Definite un percorso di escalation chiaro per aiutare a rimuovere i blocchi

I programmi di migrazione al cloud di grandi dimensioni in genere coinvolgono un'ampia gamma di parti interessate. Dopotutto, state potenzialmente cambiando le applicazioni ospitate in locale da diversi decenni. È normale che ciascuna delle parti interessate abbia priorità contrastanti.

Sebbene tutte le priorità possano generare valore, il programma avrà probabilmente un budget limitato e un obiettivo definito. Gestire i vari stakeholder e concentrarsi sui risultati aziendali prefissati può essere difficile. Questa sfida è aggravata se la si moltiplica per le centinaia o migliaia di applicazioni incluse nella migrazione. Inoltre, è probabile che le parti interessate rientrino in diversi team dirigenziali, che hanno altre priorità. In quest'ottica, oltre a documentare chiaramente i risultati aziendali da raggiungere, è importante definire una matrice di escalation chiara che aiuti a rimuovere gli ostacoli. Ciò può far risparmiare una notevole quantità di tempo e aiutare ad allineare i vari team verso un obiettivo comune.

Un esempio che lo dimostra è una società di servizi finanziari il cui obiettivo era quello di abbandonare il data center principale entro 12 mesi. Non esisteva un mandato chiaro o un percorso di escalation chiaro, il che ha portato le parti interessate a definire i percorsi di migrazione desiderati, indipendentemente dai vincoli di tempo e budget. A seguito di una richiesta al CIO, è stato fissato un mandato chiaro ed è stato fornito un meccanismo per richiedere le decisioni necessarie.

Minimizza le modifiche non necessarie

Cambiare è positivo, ma più cambiamenti significano più rischi. Una volta approvato il business case per una migrazione su larga scala, è molto probabile che questa iniziativa sia motivata da un risultato aziendale prefissato, ad esempio lo sgombero di un data center entro una data specifica. Sebbene sia normale che i tecnici vogliano riscrivere tutto per sfruttare appieno AWS i servizi, questo potrebbe non essere il vostro obiettivo aziendale.

Un cliente si è concentrato su una migrazione biennale dell'intera infrastruttura web dell'azienda verso. AWS Hanno creato una regola di due settimane come meccanismo per impedire ai team addetti alle applicazioni di passare mesi a riscrivere le proprie applicazioni. Utilizzando la regola delle due settimane, il cliente è stato in grado di sostenere una migrazione a lungo termine con una cadenza costante, quando centinaia di applicazioni dovevano essere trasferite in un periodo di più anni. Per ulteriori informazioni, consulta il post sul blog La regola delle due settimane: rifattorizza le tue applicazioni per il cloud in 10 giorni.

Ti consigliamo di ridurre al minimo qualsiasi modifica che non sia in linea con i risultati aziendali. Invece, crea meccanismi per gestire questi cambiamenti aggiuntivi nei progetti futuri.

Documenta un end-to-end processo in anticipo

Documenta l'intero processo di migrazione e l'assegnazione della proprietà nelle fasi iniziali di un programma di migrazione di grandi dimensioni. Questa documentazione è importante per informare tutte le parti interessate su come verrà eseguita la migrazione e sui loro ruoli e responsabilità. La documentazione ti aiuterà anche a capire dove potrebbero verificarsi i problemi e a fornire aggiornamenti e iterazioni del processo man mano che procedi con le migrazioni.

Durante lo sviluppo del progetto di migrazione, assicuratevi che tutti i processi esistenti siano compresi e che i punti di integrazione e le dipendenze siano documentati in modo chiaro. Includi i luoghi in cui sarà necessario coinvolgere i proprietari dei processi esterni, comprese le richieste di modifica, le richieste di assistenza, il supporto dei fornitori e il supporto di rete e firewall. Una volta compreso il processo, consigliamo di documentare la proprietà in una matrice RACI (responsabile, responsabile, consultata e informata) per tenere traccia delle diverse attività. Per finalizzare il processo, stabilisci un piano di conto alla rovescia identificando le tempistiche coinvolte in ogni fase della migrazione. Il piano di conto alla rovescia generalmente funziona a ritroso rispetto alla data e all'ora limite della migrazione del carico di lavoro.

Questo approccio alla documentazione ha funzionato bene per una multinazionale di elettrodomestici che è migrata AWS con successo in meno di un anno e ha chiuso quattro data center. Avevano coinvolto sei diversi team organizzativi e diverse terze parti, il che ha comportato un sovraccarico di gestione che ha comportato decisioni e ritardi nell' back-and-forthimplementazione. Il team dei Servizi AWS professionali, insieme al cliente e alle terze parti, ha identificato i processi chiave per le attività di migrazione e li ha documentati con i rispettivi proprietari. La matrice RACI risultante è stata condivisa e concordata da tutti i team coinvolti. Utilizzando la matrice RACI e una matrice di escalation, il cliente ha risolto i blocchi e i problemi che creavano ritardi. Sono stati quindi in grado di uscire dai data center prima del previsto.

In un altro esempio di utilizzo delle matrici RACI e di escalation, una compagnia di assicurazioni è riuscita a uscire dal data center in meno di 4 mesi. Il cliente ha compreso e implementato un modello di responsabilità condivisa ed è stata seguita una matrice RACI dettagliata per tracciare l'avanzamento di ogni processo e attività durante la migrazione. Di conseguenza, il cliente è stato in grado di migrare oltre 350 server nelle prime 12 settimane di implementazione.

Documenta modelli e artefatti di migrazione standard

Pensate a questo come alla creazione di stampini per biscotti per l'implementazione. Riferimenti, documentazione, runbook e pattern riutilizzabili sono la chiave per la scalabilità. Questi documentano l'esperienza, l'apprendimento, le insidie, i problemi e le soluzioni che i futuri progetti di migrazione possono riutilizzare ed evitare, accelerando significativamente la migrazione. I modelli e gli artefatti sono anche un investimento che contribuirà a migliorare il processo e guidare i progetti futuri.

Ad esempio, un cliente stava eseguendo una migrazione della durata di un anno in cui le applicazioni venivano migrate da tre diversi partner SI. AWS Nelle fasi iniziali, ogni AWS partner utilizzava i propri standard, runbook e artefatti. Ciò ha messo a dura prova i team dei clienti, poiché le stesse informazioni potevano essere presentate loro in modi diversi. Dopo queste prime difficoltà, il cliente ha acquisito la proprietà centralizzata di tutta la documentazione e gli elementi da utilizzare nella migrazione, con una procedura per l'invio delle modifiche consigliate. Queste risorse includono quanto segue:

• Un processo di migrazione standard e liste di controllo

• Standard di stile e formato dei diagrammi di rete

• Standard di architettura e sicurezza delle applicazioni basati sulla criticità aziendale

Inoltre, le modifiche a tali documenti e standard sono state inviate a tutti i team con cadenza settimanale e a ciascun partner è stato richiesto di confermare la ricezione e l'adesione a tali modifiche. Ciò ha migliorato notevolmente la comunicazione e la coerenza del progetto di migrazione e, quando è iniziata un'ulteriore operazione di migrazione in un'altra unità aziendale, il team è stato in grado di adottare il processo e i documenti esistenti, accelerando notevolmente il successo.

Stabilite un'unica fonte attendibile per i metadati e lo stato della migrazione

Quando si tratta di pianificare una migrazione di grandi dimensioni, stabilire una fonte attendibile è importante per mantenere allineati i vari team e consentire decisioni basate sui dati. Quando inizi questo percorso, potresti trovare numerose fonti di dati da utilizzare, come il database di gestione della configurazione (CMDB), gli strumenti di monitoraggio delle prestazioni delle applicazioni, gli elenchi di inventario e così via.

In alternativa, potresti scoprire che le fonti di dati sono poche e che devi creare meccanismi per acquisire i dati necessari. Ad esempio, potrebbe essere necessario utilizzare strumenti di rilevamento per scoprire informazioni tecniche e intervistare i responsabili IT per ottenere informazioni aziendali.

È importante aggregare le varie fonti di dati in un unico set di dati da utilizzare per la migrazione. È quindi possibile utilizzare l'unica fonte di verità per tracciare la migrazione durante l'implementazione. Ad esempio, è possibile tenere traccia dei server migrati.

Un cliente di servizi finanziari che desiderava migrare tutti i carichi di lavoro per AWS concentrarsi sulla pianificazione della migrazione con il set di dati fornito. Questo set di dati presentava lacune fondamentali, come le informazioni sulla criticità aziendale e sulle dipendenze, quindi il programma ha avviato un esercizio di individuazione.

In un altro esempio, un'azienda dello stesso settore è passata all'implementazione dell'ondata di migrazione sulla base di una out-of-date conoscenza approfondita dell'inventario dell'infrastruttura server. Hanno subito iniziato a vedere diminuire il numero di migrazioni perché i dati non erano corretti. In questo caso, i proprietari delle applicazioni non erano compresi, il che significava che non riuscivano a trovare i tester in tempo. Inoltre, i dati non erano allineati alla disattivazione completata dai team addetti alle applicazioni, quindi i server funzionavano senza essere utilizzati per scopi aziendali.

Esecuzione di una migrazione su larga scala

Dopo aver stabilito i risultati aziendali e comunicato la strategia alle parti interessate, potete passare alla pianificazione del modo in cui suddividere l'ambito della migrazione su larga scala in eventi o ondate di migrazione sostenibili. Gli esempi seguenti forniscono linee guida fondamentali per la creazione del piano d'ondata.

In questa sezione:

• Pianifica le ondate migratorie in anticipo per garantire un flusso costante

• Mantieni l'implementazione e la pianificazione delle ondate come processi e team separati

• Inizia in piccolo per ottenere ottimi risultati

• Riduci al minimo il numero di finestre di taglio

• Fallisci velocemente, applica l'esperienza e ripeti

• Non dimenticate la retrospettiva

Pianifica le ondate migratorie in anticipo per garantire un flusso costante

La pianificazione della migrazione è una delle fasi più importanti del programma. Si accompagna al detto «se non riesci a pianificare, prevedi di fallire». La pianificazione anticipata delle ondate di migrazione consente al progetto di procedere rapidamente man mano che il team diventa più proattivo rispetto alla situazione della migrazione. Aiuta il progetto a scalare più facilmente e migliora il processo decisionale e le previsioni man mano che le richieste del progetto aumentano e diventano complesse. La pianificazione anticipata migliora anche la capacità del team di adattarsi ai cambiamenti.

Ad esempio, un importante cliente di servizi finanziari stava lavorando a un programma di uscita dal data center. Inizialmente, il cliente pianificava le ondate di migrazione in modo sequenziale, completandone una prima di iniziare a pianificare la successiva. Questo approccio ha consentito di ridurre i tempi di preparazione. Quando le parti interessate sono state informate che le loro applicazioni erano in corso di migrazione verso AWS, avevano ancora diversi passaggi da eseguire prima di iniziare la migrazione. Ciò ha comportato notevoli ritardi nel programma. Dopo che il cliente se ne è reso conto, ha implementato un flusso di pianificazione della migrazione olistico e orientato al futuro in cui le ondate di migrazione sono state pianificate con diversi mesi di anticipo. Ciò ha fornito un preavviso sufficiente ai team delle applicazioni per svolgere le attività precedenti alla migrazione, come la notifica ai AWS partner, l'analisi delle licenze e così via. Potrebbero quindi rimuovere tali attività dal percorso critico del programma.

Mantieni l'implementazione e la pianificazione delle ondate come processi e team separati

Quando i team di pianificazione delle ondate e di implementazione delle ondate sono separati, i due processi possono funzionare in parallelo. Grazie alla comunicazione e al coordinamento, ciò evita di rallentare la migrazione perché non sono pronti abbastanza server o applicazioni per raggiungere la velocità prevista. Ad esempio, il team addetto alla migrazione potrebbe dover migrare 30 server ogni settimana, ma nella fase attuale solo 10 server sono pronti. Questa sfida è spesso causata da quanto segue:

• Il team di implementazione della migrazione non è stato coinvolto nella pianificazione delle ondate e i dati raccolti nella fase di pianificazione delle ondate non sono completi. Il team di implementazione della migrazione deve raccogliere più dati sul server prima di iniziare l'ondata.

• L'implementazione della migrazione è programmata per iniziare subito dopo la pianificazione della fase, senza alcun buffer intermedio.

È fondamentale pianificare le ondate in anticipo e creare un buffer tra la preparazione e l'inizio dell'implementazione dell'ondata. È inoltre importante assicurarsi che il team di pianificazione delle ondate e il team di migrazione collaborino per raccogliere i dati giusti ed evitare rilavorazioni.

Inizia in piccolo per ottenere ottimi risultati

Pianificate di iniziare in piccolo e di aumentare la velocità di migrazione con ogni ondata successiva. L'ondata iniziale dovrebbe essere una singola applicazione di piccole dimensioni, con meno di 10 server. Aggiungi applicazioni e server aggiuntivi nelle ondate successive, raggiungendo la massima velocità di migrazione. Dando priorità alle applicazioni meno complesse o rischiose e aumentando la velocità in base a una pianificazione, il team ha il tempo di abituarsi alla collaborazione e di apprendere il processo. Inoltre, il team può identificare e implementare miglioramenti del processo con ogni ondata, il che può migliorare sostanzialmente la velocità delle ondate successive.

Un cliente stava migrando più di 1.300 server in un anno. Partendo da una migrazione pilota e da alcune ondate più piccole, il team addetto alla migrazione è stato in grado di identificare diversi modi per migliorare le migrazioni successive. Ad esempio, hanno identificato in precedenza nuovi segmenti di rete di data center. Hanno collaborato con il team addetto ai firewall sin dalle prime fasi del processo per mettere in atto regole firewall che consentissero la comunicazione con gli strumenti di migrazione. Ciò ha contribuito a prevenire inutili ritardi nelle ondate future. Inoltre, il team è stato in grado di sviluppare script che aiutassero ad automatizzare maggiormente i processi di scoperta e cutover ad ogni ondata. Iniziare in piccolo ha aiutato il team a concentrarsi sui primi miglioramenti dei processi e ha aumentato notevolmente la fiducia.

Riduci al minimo il numero di finestre di taglio

Le migrazioni di massa richiedono un approccio disciplinato per promuovere la scalabilità. Essere troppo flessibili in alcune aree è un ostacolo alle migrazioni di grandi dimensioni. Limitando il numero di finestre di taglio settimanali, il tempo dedicato alle attività di cutover ha un valore maggiore.

Ad esempio, se la finestra di taglio è troppo flessibile, si potrebbero avere 20 cutover con cinque server ciascuna. È invece possibile disporre di due cutover con 50 server ciascuno. Poiché il tempo e l'impegno necessari per ogni cutover sono simili, disporre di un numero inferiore di cutover più grandi riduce l'onere operativo della pianificazione e limita i ritardi inutili.

Una grande azienda tecnologica stava cercando di migrare da alcuni data center in leasing prima della scadenza del contratto. La mancata scadenza comporterebbe costosi termini di rinnovo a breve termine. All'inizio della migrazione, i team addetti alle applicazioni avevano la possibilità di stabilire la pianificazione delle migrazioni fino all'ultimo minuto, compresa la possibilità di rinunciare alla migrazione per qualsiasi motivo pochi giorni prima della scadenza. Ciò ha comportato numerosi ritardi nelle fasi iniziali del progetto. Spesso, il cliente doveva negoziare all'ultimo minuto con altri team addetti alle applicazioni per la compilazione. Alla fine il cliente ha aumentato la disciplina di pianificazione, ma questo errore iniziale ha portato a uno stress costante per il team di migrazione. I ritardi rispetto alla pianificazione generale hanno fatto sì che alcune applicazioni non riuscissero a uscire dai data center in tempo.

Fallisci velocemente, applica l'esperienza e ripeti

Inizialmente ogni migrazione presenta delle insidie. Fallire precocemente aiuta il team a imparare, a comprendere gli ostacoli e ad applicare le lezioni apprese a ondate più ampie. Si prevede che le prime due ondate di una migrazione siano lente per i seguenti motivi:

• I membri del team si stanno adattando gli uni agli altri e al processo.

• Le migrazioni di grandi dimensioni di solito coinvolgono molti strumenti e persone diversi.

• Ci vuole tempo per integrare, testare, fallire, imparare e migliorare continuamente il end-to-end processo.

I problemi sono comuni e prevedibili durante le prime due ondate. È importante capirlo e comunicarlo all'intera organizzazione, perché ad alcuni team potrebbe non piacere provare cose nuove e fallire. Un fallimento può scoraggiare il team e ostacolare le future migrazioni. Assicurarsi che tutti capiscano che i problemi iniziali fanno parte del lavoro e incoraggiare tutti a provare e fallire è fondamentale per una migrazione di successo.

Un'azienda ha pianificato di migrare più di 10.000 server in 24-36 mesi. Per raggiungere questo obiettivo, aveva bisogno di migrare quasi 300 server al mese. Tuttavia, ciò non significa che abbiano migrato 300 server sin dal primo giorno. Le prime due ondate sono state di apprendimento, in modo che il team potesse capire come funzionavano le cose e chi aveva i permessi per fare cosa. Hanno anche identificato integrazioni che avrebbero migliorato il processo, come l'integrazione con CMDB e. CyberArk Hanno usato le onde di apprendimento per fallire, migliorare e fallire ancora, perfezionando il processo e l'automazione. Dopo 6 mesi, sono stati in grado di migrare più di 120 server ogni settimana.

Non dimenticate la retrospettiva

Questa è una parte importante di un processo agile. È il luogo in cui il team comunica, si adatta, impara, concorda e va avanti. Una retrospettiva di livello più elementare consiste nel guardare indietro, discutere di ciò che è successo, determinare cosa è andato bene e cosa deve migliorare. È quindi possibile apportare miglioramenti sulla base di tali discussioni. Le retrospettive definiscono alcune formalità o processi attorno all'idea delle lezioni apprese. Le retrospettive sono importanti perché, per raggiungere la scala e la velocità necessarie per il successo di migrazioni di grandi dimensioni, i processi, gli strumenti e i team devono evolversi e migliorare costantemente. Le retrospettive possono svolgere un ruolo importante in questo senso.

Le sessioni tradizionali basate sulle lezioni apprese non si svolgono fino alla fine di un programma, quindi spesso queste lezioni non vengono riviste all'inizio della prossima ondata migratoria. Nel caso di migrazioni di grandi dimensioni, le lezioni apprese dovrebbero essere applicate all'ondata successiva e costituire una parte fondamentale del processo di pianificazione delle ondate.

Per un cliente, sono state organizzate retrospettive settimanali per discutere e documentare le lezioni apprese dai cutover. In queste sessioni, hanno scoperto aree in cui era possibile semplificare i processi dal punto di vista dell'automazione. Ciò ha portato all'implementazione di un conto alla rovescia con attività specifiche, proprietari e script di automazione per ridurre al minimo le attività manuali, inclusa la convalida di strumenti di terze parti e l'installazione di CloudWatch agenti Amazon, durante il cutover.

Presso un'altra grande azienda tecnologica, sono state organizzate regolarmente retrospettive con il team per identificare i problemi legati alle precedenti ondate migratorie. Ciò ha comportato miglioramenti nei processi, negli script e nell'automazione che hanno ridotto il tempo medio di migrazione del 40% nel corso del programma.

Ulteriori considerazioni

Molte aree devono essere prese in considerazione in un ampio programma di migrazione. Le sezioni seguenti forniscono riflessioni su altri elementi che devono essere considerati.

In questa sezione:

• Pulisci man mano che procedi

• Implementa più fasi per qualsiasi trasformazione aggiuntiva

Pulisci man mano che procedi

Una migrazione non è considerata riuscita se costa 10 volte quello previsto e il progetto non è completo finché le risorse utilizzate per la migrazione non vengono chiuse e ripulite. Questa pulizia dovrebbe far parte dell'attività successiva alla migrazione. Garantisce che non lascerete risorse e servizi inutilizzati nell'ambiente, il che comporterebbe un aumento dei costi. La pulizia post-migrazione è anche una buona pratica di sicurezza per prevenire minacce e vulnerabilità che espongono l'ambiente.

Due risultati chiave del passaggio a Cloud AWS sono il risparmio sui costi e la sicurezza. Lasciare risorse inutilizzate può vanificare lo scopo aziendale del passaggio al cloud. Le risorse più comuni che non vengono ripulite includono:

• Dati di test

• Database di test

• Account di test, tra cui regole firewall, gruppi di sicurezza e indirizzi IP della lista di controllo degli accessi alla rete (Network ACL)

• Porte predisposte per il test

• Volumi Amazon Elastic Block Store (Amazon EBS)

• Snapshot

• Replica (ad esempio interruzione della replica dei dati dall'ambiente locale a) AWS

• File che occupano spazio (come i backup temporanei del database utilizzati per la migrazione)

• Istanze che ospitano gli strumenti di migrazione

In un esempio di pratiche di pulizia errate, AWS i partner SI non hanno rimosso gli agenti di replica dopo una migrazione riuscita. Un AWS audit ha rilevato che i server di replica e i volumi EBS già migrati costavano 20.000 dollari (USD) al mese. Per mitigare il problema, AWS Professional Services ha creato un processo di audit automatizzato che notificava ai AWS partner SI quando i server obsoleti erano ancora in fase di replica. I AWS partner SI potevano quindi intervenire sulle istanze non utilizzate e obsolete.

Per le migrazioni future, è stato adottato un processo per definire un periodo di hypercare post-migrazione di 48 ore per garantire un'adozione agevole della piattaforma. Il team dell'infrastruttura del cliente ha quindi inviato una richiesta di smantellamento per i server locali. È stato consigliato che, dopo l'approvazione della richiesta di smantellamento, i server della rispettiva ondata sarebbero stati rimossi dalla console del servizio di migrazione delle applicazioni.

Implementa più fasi per qualsiasi trasformazione aggiuntiva

Quando si effettua una migrazione di grandi dimensioni, è importante rimanere concentrati sull'obiettivo principale, come la chiusura del data center o la trasformazione dell'infrastruttura. Nelle migrazioni più piccole, lo scope creep potrebbe avere un impatto minimo. Tuttavia, alcuni giorni di impegno aggiuntivo moltiplicati per potenzialmente migliaia di server possono aggiungere una notevole quantità di tempo al programma. Inoltre, le modifiche aggiuntive potrebbero richiedere anche aggiornamenti della documentazione, dei processi e della formazione per i team di supporto.

Per ovviare a potenziali distorsioni di ambito, puoi implementare un approccio in più fasi alla migrazione. Ad esempio, se il tuo obiettivo era quello di liberare un data center, la fase 1 potrebbe includere solo il rehosting del carico di lavoro il più velocemente possibile. AWS Dopo il rehosting di un carico di lavoro, la fase 2 può implementare attività di trasformazione senza mettere a rischio il risultato aziendale previsto.

Ad esempio, un cliente ha pianificato di uscire dal proprio data center entro 12 mesi. Tuttavia, la loro migrazione comprendeva altre attività di trasformazione, come l'implementazione di nuovi strumenti di monitoraggio delle prestazioni delle applicazioni e l'aggiornamento dei sistemi operativi. La migrazione comprendeva più di 1.000 server, quindi queste attività hanno comportato un notevole ritardo nella migrazione. Inoltre, questo approccio richiedeva una formazione sull'uso dei nuovi strumenti. Il cliente ha successivamente deciso di implementare un approccio in più fasi con un focus iniziale sul rehosting. Ciò ha aumentato la velocità di migrazione e ridotto il rischio di non rispettare la data di chiusura del data di chiusura del data di chiusura del data center.