Quando serve
Devi aggiornare SQL Server o cambiare compatibilità database, ma non hai visibilità sui rischi reali di regressione. Hai workload business-critical, finestre di fermo ridotte e nessun margine per scoprire problemi solo dopo il go-live.
Cosa analizziamo
- Compatibilità motore e database
- Query Store e baseline prestazionale
- Feature deprecate e comportamenti sensibili
- Dipendenze applicative e job critici
- Piano di rollback e controlli post-upgrade
Situazioni in cui veniamo coinvolti
Ci contattano aziende che devono affrontare upgrade di versione, cambi di compatibility level o progetti di refresh infrastrutturale senza esporre produzione a regressioni poco governabili.
Il rischio più sottovalutato
Un upgrade SQL Server fallisce raramente per il motore in astratto. Più spesso il problema emerge da query sensibili, job dimenticati, dipendenze applicative, statistiche poco affidabili o assenza di una baseline solida da confrontare dopo il go-live.
Cosa consegniamo
Readiness assessment con aree a rischio, verifiche obbligatorie pre-upgrade, elenco query sensibili da monitorare e piano operativo per rollout, validazione e rollback. L'obiettivo è ridurre il rischio tecnico prima della finestra di intervento, non durante.
Un caso ricorrente
L'ambiente sembra stabile e pronto finché non si scopre che report critici, stored procedure storiche o integrazioni esterne reagiscono in modo diverso al nuovo compatibility level. Il lavoro vero è far emergere queste fragilità prima del cambio.
Domande frequenti
Fate anche supporto durante la finestra di upgrade?
Sì, se concordato. Possiamo affiancare il team sia nella fase di readiness sia nel rollout e nella validazione post-intervento.
Serve una baseline prestazionale storica?
È molto utile. Se manca, impostiamo almeno una baseline mirata prima della finestra di cambio.