A volte non si migra perché lo si vuole, ma perché lo si deve fare. I sistemi legacy possono alla fine raggiungere un punto in cui non riescono più a tenere il passo con le esigenze di un'azienda moderna e la loro manutenzione potrebbe diventare un rischio piuttosto che una risorsa.

Ecco alcuni motivi principali per cui potresti aver bisogno di una migrazione del database:

• Hardware a fine ciclo di vita: i tuoi server fisici stanno invecchiando e il produttore non supporta più l'hardware o il sistema operativo
• Colli di bottiglia delle prestazioni: l'architettura del tuo attuale database non è in grado di gestire il volume di dati o i picchi di traffico, causando esperienze lente per i tuoi utenti
• Sicurezza e conformità: i sistemi legacy potrebbero non disporre delle funzionalità di sicurezza, delle patch o delle capacità di audit moderne necessarie per soddisfare gli standard normativi odierni
• Vendor lock-in: sei vincolato a una licenza proprietaria, costosa o inflessibile che limita la tua capacità di innovare o di scegliere gli strumenti migliori per le tue esigenze specifiche
• Silos di dati: i tuoi dati sono intrappolati in sistemi on-premise isolati, il che rende difficile l'inserimento in modelli di analisi o di AI moderni di cui il tuo team ha bisogno per rimanere competitivo

Quando l'architettura esistente non è più in grado di supportare i requisiti operativi, la migrazione è il passo successivo necessario per mantenere la tua attività in esecuzione in modo sicuro ed efficiente.

Quando sposti il tuo database, probabilmente sentirai i termini omogeneo ed eterogeneo. Comprendere la differenza ti aiuta a pianificare la quantità di lavoro che il tuo team tecnico deve svolgere.

Esistono 4 strategie comuni per la migrazione dei dati. Visita Strategie di migrazione al cloud per un approfondimento e per trovare le strategie consigliate.

• Rehosting: esegui la migrazione lift and shift. Il modo più semplice per eseguire la migrazione dei dati, che prevede la creazione di una copia completa del database esistente in un altro ambiente, di solito insieme al resto dello stack dell'applicazione [omogeneo]
• Replatforming: trasferisci e ottimizza. Questa strategia copia i database, le applicazioni e le macchine virtuali, per poi ottimizzarli per il nuovo ambiente cloud. Questa può essere una migrazione eterogenea, ad esempio quando si passa da un database commerciale a un database compatibile con PostgreSQL come AlloyDB [omogenea/eterogenea].
• Rifattorizzazione: sposta e migliora. Una strategia di migrazione al cloud basata sul refactoring prevede la riprogettazione delle applicazioni per allinearle ai principi cloud-native, il che richiede modifiche al codice dell'applicazione stessa. [di solito eterogenea].
• Riesegui build. Una strategia di migrazione al cloud basata sulla ricreazione prevede la riscrittura completa di un'architettura e un'applicazione per il cloud. A seconda dell'applicazione, questa operazione può essere meno costosa del refactoring [di solito eterogenea].

Sebbene tu possa eseguire la migrazione del database tra praticamente qualsiasi coppia di località, la maggior parte delle migrazioni avviene da on-premise al cloud o da un cloud all'altro.

Esistono molti motivi per cui le aziende eseguono la migrazione al cloud (o a un cloud provider alternativo):

• Sviluppo più rapido delle applicazioni
• Prestazioni e scalabilità migliorate 
• Risparmi sui costi
• Sicurezza
• Una gamma più ampia di funzionalità, in particolare quelle legate all'AI
• Il passaggio da una spesa in conto capitale on-premise (CapEx), comune ai database con licenza tradizionale, a una spesa operativa (OpEx), comune al servizio cloud

Scopri di più sui vantaggi della migrazione al cloud.

Molte organizzazioni stanno trasferendo i propri workload on-premise nel cloud per i motivi di cui sopra. Le migrazioni da on-premise richiedono considerazioni aggiuntive rispetto alle migrazioni da cloud a cloud.

Una strategia comune per la migrazione dei workload on-premise è il rehosting, che copia l'intero workload nel cloud. In questo modo, si ottengono sicurezza, affidabilità e alcuni vantaggi in termini di costi associati alla migrazione al cloud. 

Tuttavia, è importante notare che questa strategia può anche trasferire eventuali inefficienze esistenti dall'architettura on-premise all'infrastruttura cloud, il che può farti perdere i maggiori risparmi sui costi e le efficienze associate a un'architettura cloud-native. Potresti anche perdere la ricca funzionalità del cloud in aree come disaster recovery, integrazione di analisi, servizi di AI/ML e un marketplace di offerte dei partner.

Assicurati di mantenere la sicurezza dei tuoi dati durante la migrazione, in particolare tra diversi tipi di ambienti. Un modo per garantire la massima sicurezza è utilizzare un servizio di migrazione dei database affidabile.

Le migrazioni di dati e database possono essere complesse. È essenziale garantire che i dati della tua azienda, nonché la sua organizzazione e le sue funzioni, passino alla nuova architettura senza problemi. Se eseguite in modo errato, potresti riscontrare perdita di dati, esecuzione non corretta dei workload o problemi di sicurezza.

Alcune best practice:

• Comprendi i tuoi dati. È essenziale conoscere le esigenze specifiche dei casi d'uso aziendali e della relativa applicazione.
• Valuta che tipo di orientamento che sta prendendo la tua attività. Prendere in considerazione la scalabilità è fondamentale per scegliere l'architettura e il provider giusti. 
• Testa con i flag di funzionalità. Utilizza i flag funzionalità per implementare il nuovo database prima su un piccolo gruppo di utenti. In questo modo puoi testare il sistema in sicurezza prima del lancio completo.
• Seleziona la strategia di migrazione dei dati giusta per la tua situazione.
• Segui attentamente un piano di migrazione dei dati per garantire prestazioni ottimali.

Per un approfondimento del processo, fai riferimento aiconcetti e principi della migrazione dei dati e alla configurazione ed esecuzione del processo di migrazione dei dati.

Sebbene i dettagli possano variare in base al caso d'uso specifico, questi sono i passaggi di base per una migrazione corretta:

1. Identifica dove si trovano attualmente tutti i tuoi dati, in quale formato sono e dove dovrebbero essere dopo la migrazione. Potresti decidere di non migrare tutti i dati e di archiviare o eliminare quelli vecchi. È anche un momento chiave per prendere nota di eventuali potenziali rischi di migrazione.
2. Pianifica la tua strategia di migrazione. Determina quale strategia di migrazione funzionerà meglio, decidi se i tempi di inattività possono verificarsi durante l'orario di lavoro e imposta un budget. 
3. Esegui la migrazione. Potresti voler utilizzare un servizio di migrazione per l'implementazione.
4. Testa il nuovo sistema prima del passaggio. In questo modo puoi identificare i workload che non funzionano correttamente e risolvere eventuali problemi. Potresti dover eseguire entrambi i database contemporaneamente, il che richiede la replica dei dati da un sistema all'altro. Solo dopo aver verificato che tutti i workload funzionano come previsto nel nuovo database, puoi arrestare il tuo vecchio sistema.

Il numero di fasi della migrazione dipenderà dalla configurazione esistente e dalla sequenza temporale della tua organizzazione. Ad esempio, la migrazione da un deployment on-premise autogestito a un servizio cloud gestito può essere eseguita in un unico passaggio. In alternativa, se hai poco tempo a disposizione, puoi prima eseguire la migrazione a un database autogestito nel cloud e poi passare a una soluzione completamente gestita.

Idealmente, la migrazione del database non è un processo che la tua azienda eseguirà spesso. Per ottenere il massimo dalla migrazione, ecco alcune domande chiave di cui tenere conto: