Il go-live non è un evento tecnico ma la transizione controllata tra un sistema “costruito” e un sistema “in esercizio”. Come Solution Architect il tuo valore non sta nel premiare il pulsante di deploy, ma nel garantire che quel passaggio sia reversibile fino al punto di non ritorno, misurabile e sostenibile nel tempo. I pilastri dell’Azure Well-Architected Framework che governano questa fase sono Reliability (il sistema resta disponibile e recuperabile) e Operational Excellence (il team sa gestirlo dopo che tu te ne sei andato).

Progettare il piano di cutover

Il cutover è la sequenza orchestrata che porta il carico di lavoro reale sulla nuova soluzione. Un piano solido definisce quattro elementi non negoziabili:

  • Sequenza e dipendenze: import della solution managed tramite Power Platform Pipelines, attivazione delle connection reference e delle environment variable production, migrazione dati Dataverse, riattivazione di Power Automate flows e integrazioni. L’ordine conta: attivi i flussi dopo la migrazione dati per non innescare trigger su record storici.
  • Finestra di cutover: scegli l’orario di minor traffico e stima il tempo di ciascuno step con margine. Se la migrazione dati supera la finestra, valuta un approccio a delta migration (bulk iniziale + sincronizzazione incrementale) invece di un big-bang notturno.
  • Criteri go/no-go: checklist oggettiva e binaria — smoke test sui processi critici, conteggi di riconciliazione dati (record attesi vs importati), tempi di risposta entro SLA, integrazioni che rispondono 200. Se un criterio fallisce, si attiva il no-go: non si decide “a sensazione”.
  • Piano di rollback: definito prima del go-live, con trigger espliciti e punto di non ritorno. Il rollback in Power Platform raramente è un “annulla”: è ripristinare la solution precedente e, soprattutto, gestire i dati già scritti dagli utenti. Per questo servono backup/restore dell’environment Dataverse e una strategia per i record creati durante la finestra.

Trade-off chiave — big-bang vs phased rollout. Il big-bang è più semplice da coordinare ma concentra il rischio in un’unica finestra. Un rollout per fasi (per reparto o geografia) o in pilot ring riduce il blast radius e permette di validare in produzione con utenti reali prima dell’estensione: lo raccomandi quando il processo è business-critical, la base utenti è ampia e il rollback totale sarebbe costoso.

Verificare capacity e performance in condizioni reali

La UAT non stressa mai il sistema come la produzione. Prima del go-live verifica la capacity effettiva: Dataverse storage capacity (Database/File/Log), API request limits legate alle licenze, e i limiti di throughput dei flow. Nel Power Platform admin center controlli il consumo previsto contro l’allocato; se il carico reale eccede, la scelta è tra capacity add-on, ottimizzazione (ridurre le chiamate API superflue, batching) o Managed Environment con controllo delle richieste. Esegui load test sui form più pesanti e sui flussi ad alto volume: un flow che gira bene con 10 record può saturare i limiti con 10.000.

Organizzare l’hypercare

L’hypercare è il periodo di supporto intensivo (tipicamente 2–4 settimane) subito dopo il go-live, con presidio dedicato e canali di escalation rapidi. Definisci in anticipo: war room con owner tecnico e business, dashboard di monitoraggio (adozione, errori dei flow, ticket per severità), SLA di risposta e un processo di triage. Sfrutta Application Insights integrato con l’app e i flow run history per il monitoraggio proattivo. L’obiettivo è chiudere l’hypercare con criteri di uscita misurabili (volume ticket sotto soglia, nessun incidente P1 aperto), non “quando sembra stabile”.

Change management e handover operativo

La sostenibilità nel tempo dipende dalla Operational Excellence. Il change management non è formazione una tantum: è comunicazione strutturata (modello ADKAR), champion nei reparti, materiali di supporto e gestione della resistenza. L’handover al team operativo trasferisce runbook, architettura, procedure di gestione delle solution e delle environment, contatti di escalation e ownership del backlog. Consegna anche i controlli di governance — DLP policy, Managed Environments, CoE Starter Kit per il monitoraggio — così che chi gestisce sappia dove intervenire senza reinventare il contesto.

Trappole tipiche d’esame

  • Cutover irreversibile deciso “a sensazione”, senza criteri go/no-go né rollback → progetta una checklist go/no-go oggettiva e un piano di rollback con punto di non ritorno definito prima del go-live; il rollback deve includere la strategia per i dati scritti dagli utenti.
  • Sistema business-critical con base utenti ampia e alto costo di fallimento → raccomanda un phased rollout / pilot ring invece del big-bang per contenere il blast radius e validare in produzione.
  • Performance ottima in UAT ma degrado atteso in produzione → esegui capacity planning e load test reali su API limits e storage Dataverse; prevedi add-on o ottimizzazione, non scoprirlo dopo il go-live.
  • Go-live “concluso” appena l’app è online, senza presidio → pianifica un periodo di hypercare con war room, monitoraggio (Application Insights, flow history) e criteri di uscita misurabili.
  • Nessun handover: il team di progetto resta l’unico a saper operare → formalizza runbook, trasferimento di governance (DLP, Managed Environments, CoE) e change management per garantire la sostenibilità.