Migrazione in cloud

Le fasi

1. 1

   Analisi

   settimane 1–4
   • Contratto firmato
   • Riunione di avvio con la direzione e il team ITDopo «Contratto firmato».
   • Inventario di server, applicazioni e dipendenzeDopo «Riunione di avvio con la direzione e il team IT».
   • Misura dei carichi per due settimaneDopo «Riunione di avvio con la direzione e il team IT».
   • Licenze del software e vincoli dei fornitoriDopo «Riunione di avvio con la direzione e il team IT».
   • Requisiti di continuità: RPO e RTO per applicazioneDopo «Riunione di avvio con la direzione e il team IT».
   • Vincoli normativi e contrattuali sui datiDopo «Riunione di avvio con la direzione e il team IT».
   • Strategia per applicazione e ondate di migrazioneDopo «Inventario di server, applicazioni e dipendenze», «Misura dei carichi per due settimane», «Licenze del software e vincoli dei fornitori», «Requisiti di continuità: RPO e RTO per applicazione», «Vincoli normativi e contrattuali sui dati».
   • Costi in cloud a confronto con i costi attualiDopo «Inventario di server, applicazioni e dipendenze», «Misura dei carichi per due settimane», «Licenze del software e vincoli dei fornitori».
   • Piano di migrazione approvatoDopo «Strategia per applicazione e ondate di migrazione», «Costi in cloud a confronto con i costi attuali».
2. 2

   Architettura

   settimane 4–7
   • Disegno della landing zone: account, reti, identità, regoleDopo «Piano di migrazione approvato».
   • Rete: indirizzi, collegamento con la sede, DNSDopo «Piano di migrazione approvato».
   • Identità e accessi: ruoli, autenticazione a più fattori, accessi d'emergenzaDopo «Piano di migrazione approvato».
   • Copie di sicurezza e ripristino in caso di disastroDopo «Rete: indirizzi, collegamento con la sede, DNS».
   • Monitoraggio, registri e avvisiDopo «Disegno della landing zone: account, reti, identità, regole».
   • Architettura di destinazione di ogni applicazioneDopo «Rete: indirizzi, collegamento con la sede, DNS».
   • Documento di architetturaDopo «Disegno della landing zone: account, reti, identità, regole», «Identità e accessi: ruoli, autenticazione a più fattori, accessi d'emergenza», «Copie di sicurezza e ripristino in caso di disastro», «Monitoraggio, registri e avvisi», «Architettura di destinazione di ogni applicazione».
   • Revisione dell'architettura con il cliente e il responsabile della sicurezzaDopo «Documento di architettura».
   • Architettura approvataDopo «Revisione dell'architettura con il cliente e il responsabile della sicurezza».
3. 3

   Preparazione

   settimane 7–9
   • Landing zone scritta come codiceDopo «Architettura approvata».
   • Collegamento sicuro fra la sede e il cloudDopo «Architettura approvata».
   • Pipeline di rilascio verso il nuovo ambienteDopo «Architettura approvata».
   • Copie di sicurezza configurate e un ripristino provatoDopo «Landing zone scritta come codice».
   • Strumenti di replica dei server e dei databaseDopo «Landing zone scritta come codice», «Collegamento sicuro fra la sede e il cloud».
   • Piano dei passaggi e del ritorno indietroDopo «Landing zone scritta come codice».
   • Finestre di fermo concordate con chi usa le applicazioniDopo «Architettura approvata».
   • Ambiente cloud prontoDopo «Copie di sicurezza configurate e un ripristino provato», «Strumenti di replica dei server e dei database», «Piano dei passaggi e del ritorno indietro», «Finestre di fermo concordate con chi usa le applicazioni», «Pipeline di rilascio verso il nuovo ambiente».
4. 4

   Migrazione

   settimane 10–14
   • Migrazione dell'applicazione pilotaDopo «Ambiente cloud pronto».
   • Verifica della pilota e correzioni al pianoDopo «Migrazione dell'applicazione pilota».
   • Prima ondata: applicazioni interneDopo «Verifica della pilota e correzioni al piano».
   • Database sul servizio gestitoDopo «Verifica della pilota e correzioni al piano».
   • File condivisi sul servizio di archiviazioneDopo «Verifica della pilota e correzioni al piano».
   • Prova generale del passaggio delle applicazioni criticheDopo «Prima ondata: applicazioni interne», «Database sul servizio gestito».
   • Seconda ondata: applicazioni critiche, nella finestra di fermoDopo «Prova generale del passaggio delle applicazioni critiche», «File condivisi sul servizio di archiviazione».
   • Verifica degli utenti sulle applicazioni migrateDopo «Seconda ondata: applicazioni critiche, nella finestra di fermo».
   • Applicazioni in produzione nel cloudDopo «Verifica degli utenti sulle applicazioni migrate».
5. 5

   Ottimizzazione

   settimane 14–16
   • Budget e avvisi di spesaDopo «Applicazioni in produzione nel cloud».
   • Ridimensionamento sulle misure realiDopo «Applicazioni in produzione nel cloud».
   • Impegni di uno o tre anni sulle risorse stabiliDopo «Ridimensionamento sulle misure reali».
   • Dismissione dei vecchi server e chiusura dei contrattiDopo «Applicazioni in produzione nel cloud».
   • Documentazione operativa e procedureDopo «Applicazioni in produzione nel cloud».
   • Passaggio di consegne e formazione del team IT del clienteDopo «Documentazione operativa e procedure».
   • Verifica finale: costi, prestazioni, obiettiviDopo «Impegni di uno o tre anni sulle risorse stabili», «Dismissione dei vecchi server e chiusura dei contratti», «Passaggio di consegne e formazione del team IT del cliente».
   • Migrazione chiusaDopo «Verifica finale: costi, prestazioni, obiettivi».

I rischi tipici

• Dipendenze nascoste fra applicazioni

  Critico · 16

  Un'applicazione migrata smette di parlare con una rimasta in sede, o con una stampante, un lettore di badge, un servizio che nessuno aveva elencato.

  Mitigare: Connessioni osservate per due settimane, non solo dichiarate; interviste a chi usa i sistemi; ogni ondata provata con gli utenti chiave prima di chiuderla.

• Costi del cloud oltre la stima

  Alto · 12

  Risorse dimensionate come i vecchi server, ambienti di prova sempre accesi, traffico in uscita non previsto: la prima fattura spaventa la direzione.

  Mitigare: Stima sulle misure, non sulle schede dei server; budget con avvisi dal primo giorno; ridimensionamento dopo alcune settimane di carico vero.

• Licenze che non si portano in cloud

  Alto · 12

  Un database o un software di terze parti ha una licenza legata all'hardware o non ammessa in cloud: costi nuovi, o un'applicazione da lasciare in sede.

  Mitigare: Verifica scritta con ogni fornitore prima di decidere la strategia; le alternative già nel confronto dei costi.

• Fermo oltre la finestra concordata

  Alto · 10

  La copia finale dei dati dura più del previsto o una verifica fallisce: lunedì mattina le applicazioni critiche non ci sono.

  Mitigare: Prova generale con i tempi misurati; punto di non ritorno scritto nel piano; ritorno indietro già provato con la pilota.

• Applicazioni lente per la distanza dalla sede

  Medio · 9

  Applicazioni pensate per la rete locale rallentano quando il database è in cloud e gli utenti in ufficio.

  Mitigare: Le applicazioni che si parlano molto migrano nella stessa ondata; tempi di risposta misurati con la pilota; banda del collegamento verificata prima.

• Il team IT del cliente non sa gestire il nuovo ambiente

  Medio · 9

  Dopo la consegna nessuno sa leggere i costi, cambiare una regola di rete o ripristinare una copia.

  Mitigare: Il team del cliente lavora con noi dalla pilota; procedure scritte per le operazioni frequenti; formazione su operazioni vere, non sulla teoria.

• Dati personali fuori dall'Unione

  Medio · 8

  Un servizio o una copia di sicurezza finisce in una regione fuori dall'Unione, senza garanzie per i trasferimenti.

  Evitare: Regione europea imposta da una regola della landing zone; accordo di trattamento con il fornitore cloud; elenco dei servizi usati con la loro regione.

La commessa

A corpo, fatturata per SAL · 5 voci. Importi e tariffe li metti tu.

• Analisi e piano di migrazione
• Architettura
• Preparazione dell'ambiente
• Migrazione delle applicazioni
• Ottimizzazione e consegna

Le pagine dei documenti

• Inventario delle applicazioni
• Piano del passaggio in produzione
• Lista di controllo della landing zone