Migrare nel cloud senza volare alla cieca.

Un'applicazione può dipendere da componenti che non compaiono nel primo elenco dei sistemi: servizi di directory, attività pianificate in background, condivisioni di file o l'interfaccia di un partner esterno. Questi collegamenti vengono rilevati insieme ai responsabili. Ne derivano gruppi di migrazione i cui componenti vengono trasferiti insieme oppure, per scelta, mantenuti collegati in via transitoria. Il volume dei dati, le finestre di manutenzione e la disponibilità dei referenti funzionali influenzano la sequenza. Il piano delle ondate riflette così i processi reali e non solo un elenco di sistemi tecnicamente spostabili.

Per ogni gruppo viene stabilito un percorso di migrazione adeguato. Alcune applicazioni possono essere inizialmente trasferite in gran parte senza modifiche, altre richiedono adattamenti all'ambiente target. Può avere senso affrontare una modernizzazione più ampia come fase separata, qualora appesantisse inutilmente il trasferimento. La decisione tiene conto del rischio della transizione, della gestione operativa successiva e delle risorse disponibili. Prima del trasferimento vengono verificati l'ambiente target, gli accessi e i collegamenti necessari, in modo che i presupposti già noti non debbano essere creati solo durante la finestra di commutazione prevista.

Il giorno della commutazione, lo stato dei dati, le modifiche agli accessi e le verifiche funzionali devono essere coerenti tra loro. Una procedura concordata descrive quindi quando termina il lavoro nel vecchio sistema, quali dati vengono trasferiti e quali test si svolgono successivamente. Ne fanno parte i referenti e i canali di comunicazione. I soggetti coinvolti devono sapere chi valuta un problema e chi decide sulla prosecuzione. La raggiungibilità tecnica è solo uno dei passi di verifica; l'applicazione deve anche poter eseguire le operazioni rilevanti per la vostra attività aziendale.

Si discute inoltre in anticipo a quali condizioni la commutazione debba essere interrotta o annullata. Un rollback non è altrettanto semplice per ogni applicazione, in particolare se nel sistema target sono già stati generati nuovi dati. La pianificazione fissa quindi i presupposti e i limiti della procedura prevista. Il progetto pilota e i test servono a verificare le ipotesi e a migliorare la procedura. Solo con questi risultati si può valutare insieme se un'ulteriore ondata di migrazione sia pronta o se sia ancora necessario lavoro aggiuntivo.

Dopo l'avvio in produzione possono emergere nuovi aspetti: variazioni del carico, autorizzazioni mancanti o processi che nei test non erano del tutto visibili. Durante la fase di stabilizzazione concordata, questi punti vengono rilevati, valutati e gestiti. Il passaggio alla gestione operativa comprende configurazione, accessi, monitoraggio e compiti residui noti. I responsabili delle vostre applicazioni confermano l'utilizzabilità funzionale; le responsabilità tecniche e organizzative vengono documentate in modo che, dopo la fine del progetto, sia chiaro chi reagisce a ulteriori segnalazioni.

In seguito, i vecchi sistemi non dovrebbero restare in funzione senza verifica. Allo stesso tempo, lo smantellamento non deve rimuovere una dipendenza ancora necessaria. Dopo il collaudo si stabilisce quindi insieme quali risorse disattivare, quali dati conservare e quali contratti adattare. Un piano di smantellamento fissa la sequenza e le approvazioni. Così i costi doppi e i compiti aperti restano visibili. La migrazione si conclude con un passaggio di consegne ordinato e con i lavori successivi concordati, e non con la semplice constatazione che i dati ora si trovano in un altro luogo.