Go-live e adozione
Runbook di cutover
Lo switch vero e proprio, minuto per minuto, con assegnazione dei ruoli, finestra di freeze, comunicazione e un pulsante di roll-back esplicito. Un buon cutover è noioso, è proprio l'obiettivo.
Aggiornato il 18 mag 2026
Go-live · 5.4
Perché è importante ora
Il cutover è il momento in cui tutta la preparazione converge. Improvvisare qui costa giorni, non ore. Un buon runbook sembra troppo dettagliato, finché qualcuno alle 02:14 di notte deve prendere una decisione sotto pressione e lo script gli dice esattamente cosa fare.
Cosa consegna?
Runbook
Script step-by-step con orari, azioni, owner e validazioni.
Assegnazione ruoli e war room
Chi siede dove, chi chiama chi, war room fisica o virtuale.
Criteri di roll-back
Quale situazione fa scattare il reverting, chi decide, come si esegue.
Matrice di comunicazione
Cosa comunica internamente ed esternamente, quando, su quale canale.
Domande chiave
- 1Quando, weekend, festivo, venerdì sera? Qual è la finestra più tranquilla con minore impatto?
- 2Finestra di freeze, da quale momento non si possono più apportare modifiche ai sistemi sorgente? Come lo comunica?
- 3Assegnazione ruoli, cutover lead, tech lead, comunicazione, business validator, sponsor on-call? Un back-up per ciascun ruolo.
- 4Passaggi, per ogni azione: cosa si fa, quanto dura, chi la esegue, quale controllo ne valida il successo?
- 5Punti decisionali (gate), dopo quali passaggi si può procedere e quali sono i criteri? Chi firma?
- 6Procedura di roll-back, descritta concretamente, testata in dry run. Quali azioni, quanto dura, qual è il point of no return?
- 7Comunicazione, messaggio agli utenti prima, status page durante, messaggio "tutto live" dopo. Per canale e per lingua.
- 8Parti esterne, implementation consultant Gfacility, fornitore IdP, hosting, eventualmente tenant admin M365: chi è in standby, su quale linea di escalation?
- 9Smoke test subito dopo il go-live, quali 10-15 scenari esegue per acquisire fiducia che funzioni?
- 10Sicurezza, service account, API key, segreti OAuth, chi li detiene, come li conserva in modo sicuro nel weekend?
Template — Runbook (estratto)
| Orario | Passaggio | Owner | Validazione | Roll-back? |
|---|---|---|---|---|
| Ven 18:00 | Comunicazione "inizio freeze" | PM | Email inviata, banner intranet | N/A |
| Ven 19:00 | Sistema sorgente in read-only | Source admin | Il test manuale di scrittura fallisce | Ripristino read-write |
| Ven 19:30 | Export delta finale | Tech lead | Conteggi ≥ attesi | Ri-esecuzione script |
| Ven 20:30 | Script di migrazione in produzione | Tech lead | Log puliti, conteggi corretti | Snapshot restore |
| Ven 22:00 | Attivazione SSO + integrazioni | IT-Identity | Login con account di test | Rollback config SSO |
| Ven 23:00 | Smoke test (15 scenari) | Business validator | 14/15 PASS | Decisione per scenario |
| Sab 00:00 | Go/no-go gate 1 | Cutover lead | Lo sponsor firma | → Roll-back |
| Sab 09:00 | Champion testano sul posto | Champion | Issue log ≤ 5 P2 | — |
| Dom 18:00 | Comunicazione "live lun 8:00" | PM | Email + Teams + intranet | — |
| Lun 08:00 | Hypercare ufficialmente avviato | Hypercare lead | Hotline aperta | — |
| … | … | … | … | … |
Template — Criteri di roll-back
Trigger 1 — Qualità dati
Differenza > 2% nei totali tra sorgente e target dopo migrazione. Decisione di roll-back entro 30 min.
Trigger 2 — SSO fallisce
> 5% degli account di test non riesce a fare login. Roll-back salvo workaround entro 60 min.
Trigger 3 — Smoke test fallisce
> 3 dei 15 scenari falliti. Non superi nessun gate go/no-go. Analisi del problema + decisione.
Point of no return
Sabato 12:00, oltre questo orario il roll-back non è più sostenibile senza perdere il lavoro del weekend. Decida prima di quel momento.