Guida alla strategia di migrazione dei dati

La migrazione dei dati è il processo di spostamento dei dati da una posizione di storage a un'altra, da un data center on-premise al cloud, tra piattaforme di database o da array di storage legacy a un'infrastruttura moderna. L'esecuzione di una migrazione senza una strategia chiara può causare sforamenti di budget, perdita di dati e interruzione delle operazioni aziendali.

La posta in gioco è alta. Secondo una ricerca di Oracle, oltre l'80% dei progetti di migrazione dei dati supera il budget e nel tempo. Questa cifra non è migliorata molto nel corso degli anni, non perché la tecnologia è insufficiente, ma perché le organizzazioni sottovalutano la pianificazione, il lavoro sulla qualità dei dati e la gestione dei rischi richiesti dalle migrazioni di successo.

Questa guida illustra tutto ciò che riguarda una strategia di migrazione dei dati: come funzionano le migrazioni, quale approccio si adatta alla situazione, i rischi da pianificare e un framework di progetto dettagliato per mantenere la migrazione sulla strada giusta.

Decidere di passare a un nuovo sistema non è mai facile. Ma quando l'ambiente attuale non soddisfa più le tue esigenze, a causa di vincoli di capacità, limitazioni delle performance, modifiche delle licenze o passaggio all'infrastruttura cloud, la migrazione diventa inevitabile. La domanda è come affrontarlo senza creare più problemi di quelli che risolvi.

Una solida strategia di migrazione dei dati ti offre un percorso strutturato dalla pianificazione fino allo smantellamento. Si occupa della meccanica tecnica del trasferimento dei dati, dei rischi aziendali coinvolti e dei processi di governance necessari per mantenere i dati precisi e accessibili durante la transizione.

La migrazione dei dati è il processo di spostamento dei dati da una posizione di storage a un'altra, comprese le fasi di pianificazione, mappatura, estrazione e formattazione necessarie per garantire che i dati siano accessibili e precisi nel nuovo ambiente. Comprende il trasferimento di database, file, applicazioni e interi workload tra sistemi che possono variare per formato, struttura o piattaforma.

La possibilità di migrare i dati in modo efficiente è diventata fondamentale, poiché le organizzazioni gestiscono un numero esponenziale di dati in ambienti più diversi. Ciò che un tempo comportava la copia di un database da un server all'altro ora spesso implica piattaforme cloud, architetture distribuite e requisiti di conformità che aggiungono complessità significativa.

La maggior parte delle migrazioni dei dati segue un processo ETL generale, che prevede l'estrazione, la trasformazione e il caricamento, anche se le specifiche variano in base all'ambiente di origine e di destinazione. In sostanza, la migrazione comporta i seguenti passaggi:

• Analisi dei dati che si desidera migrare per identificare i problemi di compatibilità tra gli ambienti di origine e di destinazione, tra cui le differenze di schema, le mancate corrispondenze dei tipi di dati e le incoerenze di codifica.
• Mappatura dei campi di origine agli equivalenti di destinazione. Una buona documentazione di mappatura dei dati è essenziale per rilevare gli errori di trasformazione prima che raggiungano la produzione.
• Backup di tutti i dati prima dell'inizio della migrazione. Non è negoziabile. Senza un backup verificato, una migrazione non riuscita può comportare una perdita permanente di dati.
• Testare la logica di migrazione rispetto a una copia dell'ambiente di produzione per convalidare la precisione dei dati nel sistema di destinazione prima di eseguire il commit.
• Estrazione dei dati dal sistema di origine tramite un data loader o un'applicazione ETL.
• Trasformare i dati dove necessario per conformarsi ai requisiti di formato, schema o qualità dei dati del sistema di destinazione.
• Caricamento dei dati trasformati nell'ambiente di destinazione.
• Verificare che i dati trasferiti siano completi, precisi e accessibili, inclusi i conteggi delle righe, i checksum e i test a livello di applicazione.

Le fasi di mappatura e test sono quelle in cui la maggior parte delle migrazioni incontra problemi. Le organizzazioni che considerano la migrazione come un'operazione di copia pura, saltando la rigorosa profilazione e convalida dei dati, tendono a rilevare problemi di qualità dei dati solo dopo il cutover, quando sono più difficili da correggere.

Questi sono i rischi più comuni associati alle migrazioni dei dati e il motivo per cui ciascuno di essi deve essere affrontato in modo esplicito nella tua strategia.

1. Superare il budget

Secondo un white paper di Oracle sulla migrazione dei dati, i costi superano in media il 30% e il tempo supera in media il 41% tra i progetti di migrazione dei dati. Questi overrun sono quasi sempre riconducibili alla sottostima della complessità dei dati di origine, in particolare della quantità di lavoro di pulizia e trasformazione necessaria una volta avviata la profilazione dei dati effettiva.

L'altra causa comune degli sforamenti di budget è l'aumento dell'ambito di applicazione. Le migrazioni spesso scoprono dipendenze, integrazioni e problemi di qualità dei dati che non erano visibili durante lo scopo iniziale. Ogni scoperta aggiunge un lavoro che non era stato preventivato. Le organizzazioni che integrano la contingenza nei propri budget di migrazione, in genere dal 20% al 25% al di sopra della stima iniziale, gestiscono queste scoperte senza far deragliare il progetto. Quelle che non finiscono per tagliare gli angoli o per cercare un'ulteriore approvazione del budget a metà progetto, entrambe comportano rischi propri.

2. Perdita di dati

La perdita di dati è un risultato comune delle migrazioni che saltano o accelerano la fase di backup. Ogni piano di migrazione deve includere una strategia di backup verificata e testata prima che i dati si spostino. Ciò significa non solo creare un backup, ma anche confermare che è possibile eseguire il restore.

La distinzione è più importante di quanto sembri. Molte organizzazioni scoprono durante un tentativo di restore effettivo che il backup è incompleto, danneggiato o incompatibile con l'ambiente di destinazione. Un backup che non è mai stato testato non è un backup, ma un presupposto. I test di restore devono essere un requisito formale di approvazione prima dell'inizio dell'esecuzione della migrazione, non una pianificazione successiva al cutover.

3. Downtime

Senza la georeplica o le architetture a esecuzione parallela, la migrazione dei dati richiede in genere la messa offline dei sistemi. Ciò influisce sulle performance delle applicazioni e sull'accesso degli utenti. L'approccio di migrazione che scegli, Big Bang, trickle o zero downtime, determina in larga misura la quantità di downtime che la tua azienda deve assorbire.

Anche le stime dei tempi di inattività sono ottimistiche. Una finestra di migrazione proiettata a quattro ore può estendersi a 12 se i volumi di dati sono più grandi del previsto, la logica di trasformazione è più lenta del test o i passaggi di convalida possono causare problemi superficiali che devono essere risolti prima che il cutover possa procedere. La comunicazione di una stima realistica dei downtime e l'integrazione di un buffer nella finestra di manutenzione impediscono il tipo di pressione a metà migrazione che porta a decisioni sbagliate sulla possibilità di continuare o tornare indietro.

4. Corruzione dei dati

Il danneggiamento dei dati si verifica quando i dati non necessari, malformati o incompatibili vengono trasferiti nel nuovo sistema. I dati corrotti possono causare arresti anomali delle applicazioni e produrre output imprecisi che a volte sono più difficili da rilevare rispetto alla perdita completa di dati; un record mancante è ovvio, ma un record con valori leggermente errati può non essere rilevato per settimane.

Le cause più comuni di danneggiamento includono le discordanze di codifica dei caratteri tra i sistemi di origine e di destinazione, le conversioni dei tipi di dati che silenziosamente troncano o trasformano i valori e la logica di trasformazione che gestisce i casi edge in modo errato. La rigorosa pulizia dei dati prima della migrazione e la convalida dopo il cutover sono le difese principali. La convalida deve includere sia i controlli tecnici, ovvero il conteggio delle righe, i checksum, la verifica dei vincoli, sia i test a livello di applicazione che confermano il corretto comportamento dei dati nel contesto dei processi aziendali effettivi.

5. Gravità dei dati

La data gravity si riferisce alla tendenza dei dati ad accumulare dipendenze: applicazioni, servizi e altri dataset che si connettono a essi nel tempo. Maggiore è la gravità di un set di dati, più difficile è muoversi senza interrompere tali dipendenze. Le organizzazioni spesso scoprono che la data gravity a metà migrazione quando si sposta un database richiede anche la riconfigurazione di decine di servizi connessi.

Questo rischio è particolarmente evidente in ambienti che sono cresciuti organicamente nel corso di molti anni. Le integrazioni vengono create, le API vengono codificate con stringhe di connessione e gli strumenti di reporting vengono puntati su origini dati specifiche, spesso senza documentazione centralizzata. Un'attenta mappatura delle dipendenze durante l'analisi del panorama è il modo migliore per far emergere queste connessioni prima che diventino sorprese giornaliere. Ogni applicazione, servizio e processo pianificato che tocca i dati da migrare deve essere identificato, testato e aggiornato come parte del piano di migrazione.

6. Scarsa qualità dei dati

I problemi di qualità dei dati, come la duplicazione dei record, la formattazione incoerente, i valori mancanti e i dati obsoleti, non scompaiono durante la migrazione. Essi arrivano nel sistema di destinazione e diventano problemi del nuovo sistema. Un processo di revisione e pulizia della governance dei dati prima della migrazione è l'unico modo affidabile per prevenirlo. Le organizzazioni che saltano la profilazione dei dati prima della migrazione dedicano sempre più tempo alla pulizia post-migrazione rispetto a quanto avrebbero dovuto dedicare alla pulizia iniziale, e la spendono in condizioni peggiori, con gli utenti già impegnati nel nuovo sistema e nelle operazioni aziendali a seconda dei dati che non sono ancora affidabili. Trattare la migrazione come un'opportunità per migliorare la qualità dei dati, invece di limitarsi a spostarli, produce un risultato notevolmente migliore dall'altra parte.

La strategia di migrazione definisce il modo in cui i dati si spostano dall'origine alla destinazione: tutto in una volta, in fasi o senza interruzioni percepibili. L'approccio corretto dipende dalla tolleranza al downtime, dalla complessità dell'ambiente e dalla criticità dei sistemi da migrare.

1. Migrazione Big Bang

Una migrazione Big Bang trasferisce tutti i dati in un'unica operazione, in genere durante una finestra di manutenzione pianificata. I sistemi vanno offline, l'elaborazione ETL viene eseguita e il sistema di destinazione viene fornito con il set di dati completo.

Il vantaggio è la semplicità e la velocità: non è necessario gestire sistemi paralleli o la sincronizzazione dei dati. Lo svantaggio è l'esposizione al rischio: Se la migrazione fallisce parzialmente, potresti dover affrontare un rollback o un downtime prolungato. Big Bang funziona bene per dataset più piccoli, sistemi con finestre di manutenzione naturali e organizzazioni in cui è accettabile un breve downtime.

2. Migrazione difficile

In una migrazione difficile, i dati si spostano in fasi mentre sia i sistemi vecchi che quelli nuovi operano in parallelo. Il sistema di origine rimane attivo durante la migrazione, eliminando il downtime per gli utenti. Gli strumenti di sincronizzazione dei dati mantengono entrambi gli ambienti coerenti durante il periodo di transizione.

Le migrazioni complesse sono più complesse da eseguire. L'esecuzione di sistemi paralleli richiede un'infrastruttura aggiuntiva, un'attenta logica di sincronizzazione e un punto di cutover definito in cui il nuovo sistema diventa autorevole. Ma per gli ambienti mission-critical, questa complessità aggiuntiva è spesso il giusto compromesso.

3. Migrazione zero downtime

La migrazione a zero downtime è un'estensione dell'approccio difficile che utilizza la replica continua e un cutover quasi istantaneo per eliminare qualsiasi interruzione del servizio. Invece di una finestra di manutenzione pianificata, il cutover avviene quando il sistema di destinazione raggiunge la parità con l'origine. Questo approccio è sempre più comune per le organizzazioni con requisiti di disponibilità 224X7 o impegni SLA che vietano qualsiasi downtime.

La complessità delle migrazioni senza downtime è la più alta tra i tre approcci, ma il rischio di interruzione dell'attività è la più bassa. Le moderne piattaforme di storage e database hanno reso questo approccio più accessibile: strumenti come la georeplica e il clustering active-active supportano la sincronizzazione continua su vasta scala.

La maggior parte delle migrazioni aziendali non rientra perfettamente in un'unica categoria. Un modello comune è l'utilizzo di un approccio "struckle" o "zero downtime" per i database di produzione attivi, mentre l'utilizzo di Big Bang per i dati di archiviazione può tollerare una breve indisponibilità.

Il tipo di migrazione dipende da ciò che stai spostando e dagli ambienti coinvolti. Ogni tipo comporta considerazioni tecniche, modalità di guasto e requisiti di pianificazione propri. Comprendere quale tipo, o combinazione di tipi, si applica al tuo progetto è una delle prime decisioni che la tua strategia di migrazione deve prendere.

Migrazioni di database

Una migrazione del database trasferisce dati o applicazioni tra due sistemi di database, per cambiare vendor o aggiornare il software del database. I fattori scatenanti più comuni includono gli annunci di fine ciclo di vita di un vendor di database, le modifiche dei costi di licenza, i limiti di performance nella piattaforma attuale o il passaggio a alternative open source.

Le differenze di schema sono la principale fonte di complessità. Due database possono memorizzare dati concettualmente simili in modi strutturalmente incompatibili, come: 

• Tipi di dati diversi
• Convenzioni di denominazione
• Regole di vincolo
• Approcci di indicizzazione

Le procedure memorizzate e le funzioni personalizzate scritte nel dialetto di un database spesso richiedono una riscrittura per il sistema di destinazione.

Le dipendenze delle applicazioni complicano la sfida. La maggior parte dei database di produzione viene utilizzata da più applicazioni che le leggono e le scrivono. Ciascuna di queste applicazioni deve essere testata rispetto al database di destinazione prima del cutover e tutte le query che si basano su un comportamento specifico del vendor devono essere identificate e riscritte. La mancanza di questa fase è uno dei motivi più comuni per cui le migrazioni dei database non riescono a eseguire la convalida dopo il fatto.

A cosa prestare attenzione:

• Conversioni implicite dei tipi di dati che si comportano in modo diverso tra le piattaforme
• Differenze di codifica dei caratteri (UTF-8 e Latin-1, ad esempio) che danneggiano i dati di testo
• Comportamenti di sequenza e incremento automatico che non vengono trasferiti in modo trasparente tra i vendor
• Attiva e memorizza le procedure scritte nei dialetti SQL specifici del vendor

Migrazioni cloud

Le migrazioni cloud spostano i dati o le applicazioni dagli ambienti on-premise all'infrastruttura cloud o tra i provider cloud. Sono spesso i più grandi nell'ambito di applicazione e il tipo di migrazione più complesso a livello organizzativo perché spesso comportano migrazioni di database, migrazioni di storage e migrazioni di applicazioni eseguite in parallelo.

Le migrazioni lift-and-shift, che spostano i workload nel cloud con modifiche minime, sono le più veloci da eseguire, ma spesso lasciano in essere problemi di performance e costi. La sostituzione o il refactoring dei workload per sfruttare i servizi cloud-native aumenta la complessità della migrazione, ma in genere produce risultati migliori a lungo termine.

I requisiti di conformità, le regole di residenza dei dati e la latenza della rete aggiungono dimensioni che le migrazioni puramente on-premise non devono affrontare. GDPR, HIPAA e altre normative possono limitare il luogo in cui i dati possono transitare o risiedere, anche temporaneamente. Per le organizzazioni che spostano dataset di grandi dimensioni, la larghezza di banda di rete può diventare un vero collo di bottiglia: alcune migrazioni sono più veloci e più economiche utilizzando i servizi di trasferimento dati fisici rispetto alla trasmissione over-the-wire.

Le migrazioni da cloud a cloud (ad esempio, tra AWS, Microsoft Azure e Google Cloud) sono sempre più comuni quando le organizzazioni rivalutano le relazioni con i fornitori o consolidano gli ambienti multi-cloud. Queste migrazioni richiedono la comprensione delle dipendenze dei servizi proprietari che si sono accumulate nel cloud di origine, delle API di object storage, dei servizi di database gestiti, delle funzioni serverless e la determinazione dell'esistenza di servizi equivalenti nella destinazione.

A cosa prestare attenzione:

• Costi di uscita che aumentano notevolmente il budget di migrazione
• Dipendenze di servizi proprietari che non hanno un equivalente diretto al provider di destinazione
• La residenza dei dati è in conflitto con i requisiti di conformità
• Impatto della latenza sulle applicazioni progettate per l'accesso on-premise a bassa latenza

Migrazioni dello storage

Le migrazioni dello storage spostano i dati dagli array di storage esistenti al nuovo hardware. Sono tra i tipi di migrazione più comuni negli ambienti aziendali, guidati dai cicli di aggiornamento hardware, dalle esigenze di espansione della capacità e dal passaggio da un disco a rotazione ad architetture all-flash.

A differenza delle migrazioni di database o applicazioni, le migrazioni dello storage non implicano intrinsecamente la trasformazione dei dati. Il formato dei dati non cambia, stai spostando blocchi o file da una posizione fisica a un'altra. Ma il rischio operativo è altrettanto reale. Qualsiasi migrazione degli array di storage che interrompa l'accesso ai dati di produzione influisce su ogni applicazione e utente a seconda di tale storage.

Le migrazioni basate su host utilizzano software in esecuzione sul server per copiare i dati dallo storage di origine a quello di destinazione. Sono flessibili e non richiedono hardware specializzato, ma consumano CPU server e risorse di memoria durante la migrazione. Le migrazioni basate su array utilizzano funzionalità di replica integrate nell'hardware di storage, che in genere produce meno costi generali lato host e supporta il cutover non disruptive.

Per le organizzazioni che utilizzano array all-flash, le migrazioni dello storage spesso coincidono con un più ampio impegno di modernizzazione dell'infrastruttura. Il passaggio dallo storage su disco ibrido o a rotazione all'all-flash cambia notevolmente le caratteristiche delle performance: le applicazioni ottimizzate per lo storage a latenza più elevata potrebbero dover essere riconfigurate per sfruttare appieno il nuovo ambiente.

A cosa prestare attenzione:

• Configurazione multipercorso host che deve essere aggiornata quando cambiano le destinazioni di storage
• Applicazioni con percorsi di storage hardcoded che si interrompono dopo la migrazione
• Differenze di performance tra array di origine e target che influiscono sul comportamento delle applicazioni
• Pianificazione della capacità che tiene conto dei diversi rapporti di data reduction tra hardware vecchio e nuovo

Migrazioni delle applicazioni

Le migrazioni delle applicazioni spostano le applicazioni da un ambiente all'altro, on-premise, nel cloud, nel cloud o in una nuova piattaforma SaaS. Sono il tipo di migrazione più complesso da pianificare ed eseguire perché quasi sempre attivano migrazioni di database e storage come dipendenze.

La complessità si aggrava rapidamente. La migrazione di un sistema ERP, ad esempio, può richiedere la migrazione del database sottostante, dello storage su cui viene eseguito, dei servizi di rete da cui dipende e delle integrazioni che mantiene con altre applicazioni, ognuna delle quali presenta i propri requisiti di migrazione e vincoli di sequenziamento.

Le migrazioni delle applicazioni comportano anche il rischio di business più elevato di qualsiasi tipo perché influiscono direttamente sugli utenti e sui processi aziendali. Una migrazione dello storage non è riuscita è un problema dell'infrastruttura. La migrazione di un'applicazione è andata storta e interrompe i workflow da cui le persone dipendono per svolgere il proprio lavoro.

Le migrazioni SaaS, che passano da un'applicazione autogestita a un servizio cloud gestito dai vendor, presentano una serie di sfide diverse. Spesso passi a un ambiente multi-tenant con opzioni di personalizzazione limitate, il che significa valutare se la piattaforma di destinazione può effettivamente supportare i tuoi workflow attuali prima che i dati si spostino.

A cosa prestare attenzione:

• Integrazioni di terze parti che si connettono all'applicazione tramite API documentate o non documentate
• Dipendenze dall'autenticazione utente (LDAP, Active Directory) che devono essere replicate o migrate
• Configurazioni ed estensioni personalizzate che potrebbero non essere trasferite nell'ambiente di destinazione
• Requisiti di formazione degli utenti finali che devono essere presi in considerazione nella tempistica del progetto

Comprendere queste dipendenze è importante per il sequenziamento. Le migrazioni dello storage devono essere completate prima di poter convalidare le migrazioni delle applicazioni. Le migrazioni dei database devono essere eseguite prima del cutover delle applicazioni. Trattarli come flussi di lavoro indipendenti invece che come una sequenza dipendente può portare a problemi imprevisti al cutover.

La qualità dei dati è il fattore più trascurato nella pianificazione della migrazione. Le organizzazioni scoprono costantemente a metà migrazione che i dati di origine contengono duplicati, formattazione incoerente, record orfani e valori mancanti che non erano visibili fino a quando i dati non erano necessari per conformarsi a un nuovo schema.

Una valutazione pre-migrazione deve includere tre componenti:

• Profilo dei dati: Analisi sistematica dei dati di origine per identificare problemi di qualità, distribuzioni dei tipi di dati, tassi null e violazioni dei vincoli. La profilazione fornisce un quadro preciso di ciò che si sta effettivamente migrando, non di ciò che si pensa di migrare.
• Pulizia dei dati: Risolvere i problemi identificati durante la profilazione prima dell'inizio della migrazione. Ciò include la deduplica, la standardizzazione dei formati, la correzione dei problemi di codifica e la rimozione o l'archiviazione di record obsoleti.
• Convalida della mappatura source-to-target: Conferma che ogni campo di origine ha una destinazione valida, che i tipi di dati sono compatibili e che la logica di trasformazione è documentata e testata.

L'output di questa valutazione deve essere un report sulla qualità dei dati che gli stakeholder firmano prima che i dati si spostino. Ciò crea responsabilità e impedisce lo scenario comune in cui i problemi di qualità dei dati rilevati dopo la migrazione sono imputati alla migrazione stessa piuttosto che ai problemi dei dati di origine preesistenti.

Le migrazioni dei dati creano finestre temporanee a rischio elevato. I dati in transito tra sistemi sono potenzialmente più vulnerabili dei dati inattivi in ambienti noti e protetti. Qualsiasi strategia di migrazione che gestisca i dati regolamentati, come le informazioni personali, i documenti finanziari e i dati sanitari, deve soddisfare in modo esplicito i requisiti di conformità.

Le principali considerazioni sulla sicurezza per le migrazioni includono:

• Crittografia in transito: Assicurati che i dati siano crittografati in tutta la pipeline di migrazione. Questo vale sia per i trasferimenti di rete che per gli ambienti di staging intermedi.
• Controlli degli accessi: Limita l'accesso al sistema di migrazione solo al personale autorizzato. Le autorizzazioni elevate temporanee concesse ai fini della migrazione devono essere revocate subito dopo il completamento.
• Registrazione degli audit: Mantieni registri dettagliati di tutti gli accessi e gli spostamenti dei dati durante il periodo di migrazione. Questi registri fungono sia da record operativi che da documentazione di conformità.
• Residenza dei dati: Per le organizzazioni soggette a GDPR, HIPAA o altre normative sulla governance dei dati, verificare che i dati non transitino o risiedano temporaneamente in giurisdizioni non conformi durante la migrazione.
• Politica di rollback: Definire le condizioni in cui eseguire il rollback della migrazione e verificare che il rollback sia tecnicamente fattibile prima del cutover. Un piano di rollback che esiste solo su carta non è un piano di rollback.

I requisiti di conformità normativa devono essere esaminati e documentati durante la fase di pianificazione pre-migrazione, senza essere rilevati durante l'esecuzione. Coinvolgere i team di sicurezza e conformità in anticipo aiuta a prevenire le interruzioni dell'ultimo minuto che possono trasformare una migrazione di due settimane in un progetto di tre mesi.

Tutte le migrazioni dei dati implicano una qualche forma di ETL, ma la forma esatta del piano di migrazione dipende dalle esigenze specifiche della tua azienda. I passaggi precedenti, la profilazione dei dati, la selezione della strategia, la revisione della sicurezza, devono essere inseriti in un piano di migrazione formale prima che inizi qualsiasi esecuzione.

Un piano di migrazione deve specificare l'ambito dei dati da spostare, la strategia di migrazione scelta e il motivo, la policy di rollback, i criteri di test per la convalida, le tempistiche di comunicazione degli stakeholder e il piano di dismissione per l'ambiente di origine.

Un piano di progetto per la migrazione dei data center mantiene la migrazione puntuale e nel rispetto del budget. Ecco un framework passo-passo tratto da una metodologia di migrazione consolidata:

1. Pianificazione pre-migrazione

Esegui una valutazione dell'impatto pre-migrazione per verificare il costo effettivo della migrazione. Valuta se le stime dei costi si basano su analisi concrete o su congetture: le cifre del budget ricavate dalle stime dei vendor o dalle medie di settore senza riferimento al tuo ambiente specifico sono probabilmente imprecise. Riassumere i dirigenti e l'IT sul coinvolgimento richiesto, compresi gli impegni di tempo che tendono a sottovalutarsi fino a quando non sono già scaduti.

Ottenere l'approvazione formale della governance della sicurezza prima di iniziare qualsiasi lavoro tecnico. Determina la struttura di delivery del progetto (agile e a cascata), definisci ruoli e autorità decisionale, progetta un piano di formazione e conferma la policy di gestione della configurazione. L'obiettivo di questa fase è assicurarsi che tutti siano d'accordo su ciò che viene fatto e su chi è responsabile prima che qualcuno tocchi un sistema.

2. Avvio del progetto

Assicurati che il tuo back office sia in ordine. Crea un piano di comunicazione con gli stakeholder che specifichi chi riceve gli aggiornamenti, con quale frequenza e attraverso quale canale. Configura la tua piattaforma di collaborazione ai progetti, formalizza gli accordi con i fornitori terzi e definisci i requisiti hardware e software per le fasi successive.

Non saltare gli accordi con i fornitori. Le migrazioni si bloccano regolarmente perché non era in vigore un contratto con un vendor quando erano necessari hardware o licenze. La loro definizione precoce aiuta a eliminare una potenziale fonte di ritardo.

3. Analisi del paesaggio

L'analisi del paesaggio è la fase più importante della pianificazione della migrazione perché determina ciò che si sta effettivamente migrando, non ciò che si presume si stia migrando. Queste due cose raramente sono uguali.

Crea un dizionario di dati dettagliato, una specifica di mappatura source-to-target di alto livello e un report di scoping. Determina i dati volumetrici (quantità di dati, quanti record, quante dipendenze), crea un processo di gestione della qualità dei dati, crea un registro dei rischi e perfeziona le stime dei progetti in base a ciò che scopri. Le stime prodotte prima dell'analisi del panorama sono segnaposti. Le stime prodotte dopo sono impegni.

4. Progettazione della soluzione

Mappa le trasformazioni source-to-target in dettaglio e produci la progettazione finale per la creazione. Questa fase produce gli artefatti da cui lavorerà il team di compilazione: specifiche di progettazione di mappatura dettagliate, una specifica di progettazione dell'interfaccia e una specifica di gestione della qualità dei dati.

Definisci i requisiti hardware di produzione e concorda i Service Level Agreement per la migrazione stessa, non solo per l'ambiente di destinazione dopo il cutover. Le migrazioni hanno i propri requisiti di performance e disponibilità che devono essere documentati e concordati prima dell'inizio dell'esecuzione.

5. Creazione e test

Implementa l'architettura di migrazione e testala a confronto con un ambiente mirror, non con un piccolo esempio. I test con una frazione dei dati di produzione spesso non riescono a rilevare problemi di performance e scalabilità che appaiono solo a volume pieno. Documenta completamente la logica di migrazione in modo che qualsiasi membro del team possa eseguire o risolvere i problemi della migrazione senza fare affidamento sulle conoscenze istituzionali detenute da una sola persona.

Sviluppa un motore di convalida per confermare in modo indipendente la precisione dei dati nel sistema di destinazione. Stabilisci un monitoraggio continuo della qualità dei dati, crea una policy di fallback e completa la formazione sull'esecuzione. Il team che esegue la migrazione il giorno del cutover avrebbe dovuto provarla, non eseguirla per la prima volta sotto pressione.

6. Migrazione e convalida

Esegui la migrazione utilizzando l'approccio scelto: Big Bang, scontro o zero downtime. La convalida non è una formalità in questa fase, ma è il criterio che determina se la migrazione è effettivamente completa. Conferma in modo indipendente che i conteggi delle righe, i checksum e i test a livello di applicazione siano superati prima di dichiarare il successo.

Dimostrare la conformità ai revisori e agli sponsor aziendali come parte di questa fase, non dopo. Se la documentazione sulla conformità è un aspetto secondario, aspettatevi che provochi ritardi nel lancio del nuovo ambiente.

7. Dismissione e monitoraggio

Abbandonare l'ambiente legacy solo dopo che il sistema di destinazione è stato convalidato e sta funzionando in modo stabile sotto carico di produzione. L'esecuzione di entrambi gli ambienti a tempo indeterminato aumenta i costi e crea un rischio di sincronizzazione, ma il taglio troppo breve prima della conferma della stabilità crea una serie diversa di problemi.

Trasferire le responsabilità di monitoraggio della qualità dei dati al team appropriato e documentare il trasferimento in modo esplicito. Completa una convalida del ritiro del sistema e documenta il processo di dismissione a scopo di audit. Le migrazioni che terminano al cutover senza una fase di dismissione formale tendono a lasciare i sistemi orfani in funzione più a lungo di quanto chiunque abbia previsto, spesso a un costo reale dell'infrastruttura.

Le organizzazioni che eseguono le migrazioni con successo tendono a condividere alcune pratiche comuni che le aziende che faticano a evitare.

• Inizia con un audit dei dati, non con un piano di migrazione. La comprensione dello stato effettivo dei dati di origine, ovvero problemi di qualità, dipendenze e volume, deve precedere qualsiasi pianificazione strategica. Le migrazioni effettuate prima della profilazione dei dati richiedono quasi sempre la ridefinizione del progetto medio.
• Non migrare mai i dati di cui non hai bisogno. Le migrazioni sono un'opportunità per archiviare o eliminare dati che non servono più a scopi aziendali. Lo spostamento di dati non necessari aumenta i costi, i tempi e i rischi senza alcun ritorno.
• Prova con i dati di produzione. I test eseguiti con un piccolo campione spesso non riescono a rilevare problemi di performance e scalabilità che si verificano solo a un volume di produzione completo. Se la tua migrazione ETL richiede due ore di test, puoi aspettarti che siano necessarie 20 ore con dati di produzione completi.
• Definire i criteri di successo prima del cutover. Scopri esattamente cosa significa "migrazione riuscita" prima di iniziare: numero di righe specifiche, controlli di integrità, test di funzionalità delle applicazioni. Senza criteri definiti, non esiste una base oggettiva per dichiarare completata la migrazione.
• Comunicare con gli utenti interessati. Gli utenti finali e i proprietari delle applicazioni devono sapere cosa sta cambiando, quando e cosa fare in caso di problemi dopo il cutover. Una comunicazione inadeguata trasforma i successi tecnici in problemi organizzativi.
• Pianifica il rollback prima di averne bisogno. I piani di rollback devono essere testati, non solo documentati. Sapere che la procedura di rollback è tecnicamente efficace riduce notevolmente la pressione della finestra di cutover.

La migrazione dei dati si sta evolvendo da un'attività basata su progetto a una capacità operativa continua. Man mano che le organizzazioni adottano strategie multi-cloud e spostano i workload in modo dinamico tra gli ambienti, la distinzione tra "migrazione" e "gestione dei dati di routine" è sfocata.

L'automazione sta guidando questo cambiamento. AI strumenti di profilazione dei dati con AI possono ora identificare i problemi di qualità e suggerire regole di trasformazione senza analisi manuale. Le piattaforme di migrazione intelligenti possono monitorare la sincronizzazione dei dati in tempo reale e segnalare le anomalie durante le migrazioni complesse prima che diventino problemi. Le piattaforme di storage basate su architetture di data fabric supportano sempre più la mobilità dei dati non disruptive come funzionalità nativa anziché come procedura eccezionale.

Le organizzazioni che integrano la prontezza alla migrazione nell'infrastruttura dati, invece di trattarla come una funzionalità una tantum, avranno un vantaggio strutturale man mano che gli ambienti di dati continuano a evolversi. Il momento migliore per definire le procedure e gli strumenti di migrazione è prima che venga annunciata la prossima migrazione.

Il data storage è un elemento fondamentale di ogni migrazione. Senza un'infrastruttura di storage che supporti il movimento dei dati non disruptive, le organizzazioni devono affrontare una difficile scelta tra downtime prolungati e soluzioni alternative complesse.

Basate sull'architettura Evergreen®, le offerte di abbonamento Everpure sono progettate per rendere le migrazioni dei dati più semplici e convenienti, eliminando i cicli di aggiornamento e le finestre di manutenzione richiesti dagli array di storage tradizionali:

• Evergreen//One™ riduce la complessità e il costo dell'amministrazione e del supporto dello storage, fornendo flessibilità finanziaria e semplicità operativa, riducendo al tempo stesso il rischio IT.
• Evergreen//Flex™ offre la flessibilità necessaria per rispondere ai cambiamenti della domanda e dell'utilizzo, aumentare l'agilità dello storage e massimizzare il ROI sull'utilizzo della capacità con costi iniziali inferiori.
• Evergreen//Forever™ offre una reale agilità IT: acquista lo storage una sola volta e scala in modo non disruptive, senza penalità, a tempo indeterminato.

Per le organizzazioni che effettuano la migrazione da un ambiente cloud all'altro, la piattaforma di storage unificato Everpure supporta la resilienza e la continuità dei dati durante l'intero ciclo di vita della migrazione. Il risultato sono migrazioni meno disruptive, più prevedibili e meno propense a diventare il costo e la pianificazione degli overrun che caratterizzano la maggior parte dei progetti di migrazione.

Esplora il portafoglio Evergreen di Everpure per scoprire come un'infrastruttura di storage appositamente progettata può semplificare la tua prossima migrazione dei dati.