Una proposta di migrazione può sembrare completa quando elenca i server e una destinazione. Le domande più complesse riguardano però il lavoro che quei server supportano. Il personale può continuare a elaborare gli ordini? Quando viene eseguita un’esportazione pianificata? Chi controlla i record dopo il trasferimento? Un piano di migrazione cloud dovrebbe collegare le decisioni infrastrutturali a queste attività quotidiane. Usa la sequenza seguente per trasformare un trasferimento generico in un lavoro che si possa esaminare.
In questa pagina
Definisci il miglioramento operativo
Sostituisci «passare al cloud» con una motivazione che possa essere valutata. Forse i rilasci dipendono da un solo server configurato manualmente, oppure un periodo di picco richiede una capacità che l’assetto attuale non offre. Documenta il comportamento presente prima di definire l’ambiente futuro. Senza questo riferimento, è difficile capire se il trasferimento abbia risolto il problema originale o ne abbia soltanto cambiato la collocazione.
- Individua il flusso di lavoro interessato e il suo responsabile.
- Descrivi un miglioramento osservabile, per esempio un processo di distribuzione ripetibile.
- Elenca i vincoli che il trasferimento deve rispettare.
Mappa le connessioni di ogni carico di lavoro
Per ogni applicazione, elenca database, archiviazione dei file, attività pianificate, servizi esterni e requisiti di accesso. Chiedi a chi la gestisce di rivedere la mappa. Un report notturno o un collegamento con un fornitore possono sfuggire facilmente a un inventario dei server. Segna quali dipendenze devono essere spostate insieme e quali connessioni possono restare inalterate durante una transizione per fasi.
Scegli un approccio di migrazione per ogni applicazione
Esempio di decisione: un portale clienti usa un runtime ancora supportato, ma condivide un database con un’applicazione contabile meno recente. Spostare prima il portale può essere ragionevole solo se la connessione al database che rimane soddisfa i requisiti concordati di accesso e prestazioni. Altrimenti, sposta insieme i carichi di lavoro collegati o risolvi prima la dipendenza. Confronta trasferimento diretto, modifiche mirate e risviluppo con le esigenze di questa applicazione: l’intero parco applicativo non deve seguire un unico approccio.
Progetta la gestione del nuovo ambiente
Assegna le responsabilità per accessi, distribuzioni, avvisi, backup e revisioni della spesa. Stima la domanda usando le informazioni disponibili sull’utilizzo, includendo periodi tranquilli e picchi. Valuta come cambia la stima quando cresce lo spazio di archiviazione o vengono trasferiti dati tra servizi. Un confronto utile sui costi chiarisce le ipotesi e cosa verrà monitorato dopo l’avvio, invece di trattare la prima stima come un conto operativo fisso.
- Chi può modificare le impostazioni di produzione?
- Chi interviene quando un’attività non riesce?
- Come verrà verificato il ripristino dei backup?
Stabilisci le condizioni di rollback prima del passaggio
Per il portale dell’esempio, concorda come il team verificherà accesso, invio degli ordini e conteggi dei record prima di aprire il nuovo ambiente. Definisci quali errori interrompono la transizione e chi prende questa decisione. Se gli utenti possono creare nuovi record dopo il passaggio, riportare il traffico al vecchio server non basta: serve un piano concordato per gestire quei record. Prova la sequenza, compreso il punto oltre il quale il rollback richiede ulteriori interventi sui dati.
Concludi la migrazione con verifiche operative
Dopo il trasferimento, confronta flussi di lavoro, attività pianificate, avvisi e modalità di utilizzo con il riferimento concordato. Assegna un responsabile a ogni problema irrisolto. Dismetti il vecchio ambiente solo dopo che il team ha completato le verifiche di transizione e deciso quali dati o configurazioni conservare. Mantieni la mappa delle applicazioni e le istruzioni di ripristino a disposizione di chi si occuperà della manutenzione del servizio.