Preparare la migrazione dei dati SaaS: fonti, qualità e test

Perché si migra – e cosa significa per i dati

Le migrazioni verso il SaaS seguono motivazioni ricorrenti: maggiore flessibilità, migliore scalabilità, innovazione più rapida e pagamento in base all'utilizzo anziché costi fissi per le infrastrutture. I clienti si aspettano disponibilità su tutti i canali e servizio 24 ore su 24. Il pool di risorse condiviso riduce i costi e il consumo di energia, poiché le risorse cloud sono utilizzate da più clienti. Nello studio TCS «Connected Future», il 63 percento delle grandi imprese europee ha indicato il cloud come chiave centrale per garantire la propria competitività.

Non tutte le applicazioni appartengono al cloud. La decisione cruciale è se la migrazione crei un valore aggiunto per l'applicazione specifica. Può capitare che un'applicazione nel cloud non funzioni correttamente, ad esempio perché mancano le interfacce o le connessioni necessarie. Questi casi devono essere chiariti prima di copiare i dati, non dopo.

Per la pianificazione dei dati, si decide per ogni applicazione: migrare, adattare, sostituire con un'alternativa SaaS o continuare a gestirla in locale. Da ciò deriva quali basi di dati devono essere trasferite e quali rimangono nel vecchio sistema fino alla sua sostituzione. Volume, struttura e dipendenze dei dati interessati determinano l'impegno della migrazione.

Fatti importanti sulla migrazione al cloud in Svizzera

Inventario: rendere visibili fonti dati, sistemi e silos di dati

L'inventario copre l'intero panorama IT: applicazioni, dati e fabbisogno aziendale per la continuità operativa. Ogni applicazione rientra in una di tre categorie: già pronta per il cloud, da adattare, non migrabile al cloud. Per le applicazioni più vecchie o personalizzate, non sviluppate per un ambiente cloud standardizzato, bisogna verificare se esistono alternative moderne come una soluzione SaaS.

Le piccole applicazioni, utilizzate da una o poche persone, possono essere decisive per le operazioni aziendali e meritano la stessa attenzione dei silos di dati: ambienti di dati isolati tra loro. Bisogna chiarire se questi silos possono essere dissolti durante la migrazione e cosa è necessario per collegare i dati provenienti da silos diversi. Negli ospedali svizzeri si creano silos di dati derivanti da molti sistemi IT, in parte isolati o tecnicamente integrati in modo insufficiente.

L'inventario include la verifica di tutte le tecnologie per l'archiviazione, l'integrazione, l'elaborazione e l'analisi dei dati, compresi i vecchi sistemi obsoleti. L'analisi della prontezza e l'inventario delle applicazioni creano trasparenza su dati, dipendenze e rischi; i debiti tecnici e la mancanza di trasparenza su applicazioni e dipendenze sono tra i freni più comuni. L'inventario registra per ogni base di dati l'origine, l'utilizzo, le dipendenze, gli obblighi di conservazione e la decisione di migrazione.

Valutare la qualità dei dati prima ancora di copiarli

Prima della copia, viene verificata la gestione attuale dei dati: le pratiche, le linee guida e i processi attuali di gestione dei dati vengono valutati per identificare silos di dati, duplicati e vulnerabilità, e per garantire la qualità, la sicurezza, la protezione dei dati e la conformità dei dati. Una gestione dei dati insufficiente e la mancanza di integrazione generano ridondanze di dati inutili e un maggiore sforzo amministrativo; impediscono uno sviluppo end-to-end continuo delle applicazioni digitali. Una migrazione che trasferisce invariata questa situazione si limita a spostare il problema nel nuovo sistema.

Per ogni base di dati vanno definite delle regole: campi obbligatori, formati e codifiche, gestione dei duplicati, risoluzione dei riferimenti tra i record e termini di conservazione e cancellazione. Ogni duplicato non ripulito e ogni riferimento mancante viene trasferito e dovrà poi essere cercato e corretto nel nuovo sistema: un'operazione più onerosa, poiché mancano gli strumenti di verifica e i punti di contatto abituali.

Come parametri di valutazione servono la completezza dei campi obbligatori, la percentuale di duplicati, la validità dei riferimenti e l'età dei record. Se questi valori vengono rilevati prima e dopo la pulizia, si può dimostrare se i lavori preliminari hanno avuto effetto.

Chiarire ruoli, responsabilità e interfacce

La migrazione coinvolge diverse discipline: ingegneria dei dati, data science, IT, sicurezza, protezione dei dati, conformità, business intelligence e le unità aziendali che utilizzano i dati quotidianamente. Nella struttura del team, vengono definiti ruoli e responsabilità per ogni membro. In questo modo è possibile identificare lacune nelle qualifiche e limitazioni nelle risorse che potrebbero ostacolare una migrazione.

I compiti vanno assegnati in modo concreto: chi crea l'inventario dei dati, chi definisce le regole di qualità, chi chiarisce le questioni relative alla protezione dei dati, chi esegue la migrazione di prova, chi approva il risultato. Va inoltre regolato quali compiti spettano al fornitore SaaS e quali rimangono all'interno dell'azienda. L'origine e il significato dei dati sono di norma noti solo all'organizzazione che migra, mentre i formati di importazione e i limiti del prodotto sono noti solo al fornitore. Un change management accompagna i collaboratori nell'uso del nuovo ambiente durante le operazioni quotidiane.

Prendere per tempo le misure di protezione dei dati

Se i dati personali vengono trasferiti nel cloud, secondo le indicazioni dell'autorità svizzera competente (IFPD), vanno verificati tre punti: l'impiego di incaricati del trattamento e subincaricati, la sicurezza del trattamento dei dati e la trasmissione di dati personali in Paesi terzi. Il fornitore cloud agisce in materia di protezione dei dati di norma come incaricato del trattamento del cliente ai sensi dell'Art. 9 LPD; il cliente può essere egli stesso il responsabile del trattamento o a sua volta incaricato del trattamento.

In qualità di responsabile del trattamento, l'utente del cloud deve assicurarsi e garantire contrattualmente il rispetto dei requisiti per un trattamento su incarico ai sensi dell'Art. 9 LPD. In caso di comunicazione di dati all'estero, prima della comunicazione va verificato se essa soddisfa i requisiti legali. A seconda della sede dell'azienda o dei clienti, possono applicarsi ulteriori normative – vengono citati ad esempio il GDPR, la LGPD brasiliana e il CCPA californiano; i trasferimenti transfrontalieri di dati vanno gestiti di conseguenza.

La protezione dei dati è anche una questione di architettura: un'architettura attenta alla protezione dei dati permette di rispettare norme e regolamenti e allo stesso tempo di scalare economicamente. Le specifiche nazionali sulla protezione dei dati vanno considerate fin dall'inizio. A ciò appartiene un concetto di autorizzazioni con una documentazione verificabile – nel settore sanitario, ad esempio, per le cartelle dei pazienti ai sensi della LPD svizzera e del GDPR.

Testare invece di sperare: migrazioni di prova e quality gate

Prima del passaggio in produzione, bisogna dimostrare due cose: i dati finora memorizzati in locale devono essere trasmessi integri nel cloud e protetti lì; gli account con i relativi diritti di accesso devono essere trasferiti in modo fluido e completo. Per la migrazione di prova si sceglie una quantità di dati limitata ma rappresentativa, con tutti i tipi di dati, i casi speciali e i livelli di autorizzazione della base di dati in produzione. Dopo l'importazione, i record vengono contati e confrontati, i campioni vengono verificati per contenuto e formato e i diritti degli account di test nel nuovo ambiente vengono controllati.

I quality gate definiti in anticipo stabiliscono quando la migrazione si considera superata: nessun record mancante, nessuna autorizzazione impostata in modo errato, nessun errore nei campi obbligatori. Se si verifica un errore, la causa viene risolta e la prova viene ripetuta; l'elenco degli errori funge allo stesso tempo da modello di lavoro per l'esecuzione in produzione.

I test sono una precauzione contro i rischi. Gli errori nella gestione di dati e servizi sensibili nel cloud possono portare a fughe di dati e sanzioni, a interruzioni dei flussi di lavoro e a costose misure di adattamento. Le migrazioni preparate male comportano rischi durante le operazioni quotidiane; le migrazioni con interruzioni minime lavorano con i quality gate.

Dopo il trasferimento: garantire la qualità e la stabilità dei dati

Dopo il go-live segue la stabilizzazione del nuovo ambiente: monitoraggio continuo, controllo della sicurezza e delle prestazioni e ottimizzazione dei costi. I concetti di emergenza e un servizio gestito con manutenzione continua mantengono le operazioni in caso di interruzioni.

Il controllo successivo include il confronto dei record migrati dopo il trasferimento, la verifica dei diritti di accesso in produzione e la dismissione dei vecchi sistemi sostituiti, compresi i dati che non era necessario trasferire. Se il confronto rivela lacune, si può dedurre quale lavoro preliminare è mancato.

La qualità dei dati rimane un compito continuo: senza un'integrazione curata si creano nuovi silos di dati e ridondanze, la stessa meccanica che era stata ripulita prima della migrazione. Le indicazioni e le linee guida sulla protezione dei dati vanno mantenute aggiornate, affinché riflettano le effettive attività di trattamento dei dati e i diritti delle persone interessate.