Migra i dati legacy senza rovinarli

La migrazione dei dati legacy è difficile.

Molte organizzazioni dispongono di sistemi CRM aziendali on-premise vecchi e complessi. Oggi ci sono molte alternative SaaS cloud, che offrono molti vantaggi; paga come vai e paga solo per quello che usi. Pertanto, decidono di passare ai nuovi sistemi.

Nessuno vuole lasciare dati preziosi sui clienti nel vecchio sistema e iniziare con il nuovo sistema vuoto, quindi dobbiamo migrare questi dati. Sfortunatamente, la migrazione dei dati non è un compito facile, poiché circa il 50% dello sforzo di distribuzione viene consumato dalle attività di migrazione dei dati. Secondo Gartner, Salesforce è il leader delle soluzioni di cloud CRM. Pertanto, la migrazione dei dati è un argomento importante per l'implementazione di Salesforce.

Quindi, come possiamo garantire una transizione di successo dei dati legacy in un nuovo sistema brillante e assicurarci di preservare tutta la sua storia? In questo articolo, fornisco 10 suggerimenti per una corretta migrazione dei dati. I primi cinque suggerimenti si applicano a qualsiasi migrazione dei dati, indipendentemente dalla tecnologia utilizzata.

Migrazione dei dati in generale

1. Rendi la migrazione un progetto separato

Nell'elenco di controllo della distribuzione del software, la migrazione dei dati non è un elemento di "esportazione e importazione" gestito da un intelligente strumento di migrazione dei dati "premere un pulsante" che ha una mappatura predefinita per i sistemi di destinazione.

La migrazione dei dati è un'attività complessa, che merita un progetto, un piano, un approccio, un budget e un team separati. È necessario creare un ambito e un piano a livello di entità all'inizio del progetto, assicurando che non ci siano sorprese, ad esempio "Oh, ci siamo dimenticati di caricare i rapporti sulle visite di quei clienti, chi lo farà?" due settimane prima della scadenza.

L'approccio alla migrazione dei dati definisce se caricheremo i dati in una volta sola (noto anche come big bang ) o se caricheremo piccoli batch ogni settimana.

Questa non è una decisione facile, però. L'approccio deve essere concordato e comunicato a tutte le parti interessate aziendali e tecniche in modo che tutti siano consapevoli di quando e quali dati appariranno nel nuovo sistema. Questo vale anche per le interruzioni del sistema.

2. Stima realisticamente

Non sottovalutare la complessità della migrazione dei dati. Molte attività dispendiose in termini di tempo accompagnano questo processo, che potrebbe essere invisibile all'inizio del progetto.

Ad esempio, caricare set di dati specifici per scopi di formazione con una serie di dati realistici, ma con elementi sensibili offuscati, in modo che le attività di formazione non generino notifiche e-mail ai clienti.

Il fattore di base per la stima è il numero di campi da trasferire da un sistema di origine a un sistema di destinazione.

È necessaria una certa quantità di tempo nelle diverse fasi del progetto per ogni campo, inclusa la comprensione del campo, la mappatura del campo di origine sul campo di destinazione, la configurazione o la creazione di trasformazioni, l'esecuzione di test, la misurazione della qualità dei dati per il campo e così via.

L'utilizzo di strumenti intelligenti, come Jitterbit, Informatica Cloud Data Wizard, Starfish ETL, Midas e simili, può ridurre questo tempo, soprattutto nella fase di creazione.

In particolare, la comprensione dei dati di origine, l'attività più cruciale in qualsiasi progetto di migrazione, non può essere automatizzata da strumenti, ma richiede agli analisti di dedicare del tempo a esaminare l'elenco dei campi uno per uno.

La stima più semplice dello sforzo complessivo è di un giorno uomo per ogni campo trasferito dal sistema legacy.

Un'eccezione è rappresentata dalla replica dei dati tra lo stesso schema di origine e quello di destinazione senza ulteriore trasformazione, a volte nota come migrazione 1:1, in cui è possibile basare la stima sul numero di tabelle da copiare.

Un preventivo dettagliato è un'arte a sé stante.

3. Verificare la qualità dei dati

Non sopravvalutare la qualità dei dati di origine, anche se non vengono segnalati problemi di qualità dei dati dai sistemi legacy.

I nuovi sistemi hanno nuove regole, che possono essere violate con i dati legacy. Ecco un semplice esempio. L'e-mail di contatto può essere obbligatoria nel nuovo sistema, ma un sistema legacy di 20 anni può avere un punto di vista diverso.

Ci possono essere mine nascoste nei dati storici che non vengono toccate da molto tempo ma potrebbero attivarsi durante il trasferimento al nuovo sistema. Ad esempio, i vecchi dati che utilizzano valute europee che non esistono più devono essere convertiti in euro, altrimenti le valute devono essere aggiunte al nuovo sistema.

La qualità dei dati influenza in modo significativo lo sforzo e la semplice regola è: più andiamo avanti nella storia, più grande sarà il pasticcio che scopriremo. Pertanto, è fondamentale decidere in anticipo quanta storia vogliamo trasferire nel nuovo sistema.

4. Coinvolgi gli uomini d'affari

Gli uomini d'affari sono gli unici che comprendono veramente i dati e che possono quindi decidere quali dati possono essere buttati via e quali dati conservare.

È importante avere qualcuno del team aziendale coinvolto durante l'esercizio di mappatura e, per tornare indietro in futuro, è utile registrare le decisioni di mappatura e le ragioni per esse.

Poiché un'immagine vale più di mille parole, carica un batch di prova nel nuovo sistema e lascia che il team aziendale ci giochi.

Anche se la mappatura della migrazione dei dati viene rivista e approvata dal team aziendale, possono verificarsi sorprese una volta che i dati vengono visualizzati nell'interfaccia utente del nuovo sistema.

"Oh, ora capisco, dobbiamo cambiarlo un po'", diventa una frase comune.

Il mancato coinvolgimento di esperti in materia, che di solito sono persone molto impegnate, è la causa più comune dei problemi dopo che un nuovo sistema diventa operativo.

5. Puntare a una soluzione di migrazione automatizzata

La migrazione dei dati è spesso vista come un'attività una tantum e gli sviluppatori tendono a trovare soluzioni piene di azioni manuali sperando di eseguirle solo una volta. Ma ci sono molte ragioni per evitare un simile approccio.

• Se la migrazione è suddivisa in più ondate, dobbiamo ripetere le stesse azioni più volte.
• In genere, ci sono almeno tre esecuzioni di migrazione per ogni ondata: un ciclo di prova per testare le prestazioni e la funzionalità della migrazione dei dati, un carico di convalida dei dati completo per testare l'intero set di dati ed eseguire test aziendali e, naturalmente, il carico di produzione. Il numero di esecuzioni aumenta con una scarsa qualità dei dati. Il miglioramento della qualità dei dati è un processo iterativo, quindi sono necessarie diverse iterazioni per raggiungere la percentuale di successo desiderata.

Pertanto, anche se la migrazione è per natura un'attività occasionale, la presenza di azioni manuali può rallentare notevolmente le operazioni.

Migrazione dei dati di Salesforce

Successivamente tratteremo cinque suggerimenti per una migrazione Salesforce di successo. Tieni presente che questi suggerimenti sono probabilmente applicabili anche ad altre soluzioni cloud.

6. Prepararsi per carichi lunghi

Le prestazioni sono uno dei compromessi, se non il più grande, quando si passa da una soluzione on-premise a una cloud, non escluso Salesforce.

I sistemi locali di solito consentono il caricamento diretto dei dati in un database sottostante e, con un buon hardware, possiamo facilmente raggiungere milioni di record all'ora.

Ma non nel cloud. Nel cloud, siamo fortemente limitati da diversi fattori.

• Latenza di rete: i dati vengono trasferiti tramite Internet.
• Livello dell'applicazione Salesforce: i dati vengono spostati attraverso uno spesso strato multi-tenancy dell'API finché non arrivano nei loro database Oracle.
• Codice personalizzato in Salesforce: convalide personalizzate, trigger, flussi di lavoro, regole di rilevamento della duplicazione e così via, molti dei quali disabilitano i carichi paralleli o in blocco.

Di conseguenza, le prestazioni di carico possono essere di migliaia di account all'ora.

Può essere inferiore o superiore, a seconda di cose, come il numero di campi, le convalide e i trigger. Ma è di diversi gradi più lento di un caricamento diretto del database.

È necessario considerare anche il degrado delle prestazioni, che dipende dal volume dei dati in Salesforce.

È causato dagli indici nell'RDBMS sottostante (Oracle) utilizzati per il controllo di chiavi esterne, campi univoci e valutazione delle regole di duplicazione. La formula di base è di circa il 50 percento di rallentamento per ogni grado 10, causato da O(logN) la porzione di complessità temporale nelle operazioni di ordinamento e B-tree.

Inoltre, Salesforce ha molti limiti di utilizzo delle risorse.

Uno di questi è il limite dell'API in blocco impostato su 5.000 batch in finestre di 24 ore, con un massimo di 10.000 record in ogni batch.

Quindi, il massimo teorico è di 50 milioni di record caricati in 24 ore.

In un progetto reale, il massimo è molto più basso a causa delle dimensioni limitate del batch quando si utilizzano, ad esempio, trigger personalizzati.

Ciò ha un forte impatto sull'approccio alla migrazione dei dati.

Anche per set di dati di medie dimensioni (da 100.000 a 1 milione di account), l'approccio del big bang è fuori questione, quindi dobbiamo dividere i dati in ondate migratorie più piccole.

Ciò, ovviamente, influisce sull'intero processo di distribuzione e aumenta la complessità della migrazione perché aggiungeremo incrementi di dati in un sistema già popolato da migrazioni precedenti e dati inseriti dagli utenti.

Dobbiamo anche considerare questi dati esistenti nelle trasformazioni e convalide della migrazione.

Inoltre, carichi lunghi possono significare che non possiamo eseguire migrazioni durante un'interruzione del sistema.

Se tutti gli utenti si trovano in un paese, possiamo sfruttare un'interruzione di otto ore durante la notte.

Ma per un'azienda, come Coca-Cola, con attività in tutto il mondo, questo non è possibile. Una volta che abbiamo Stati Uniti, Giappone ed Europa nel sistema, ci occupiamo di tutti i fusi orari, quindi il sabato è l'unica opzione di interruzione che non influisce sugli utenti.

E ciò potrebbe non essere sufficiente, quindi dobbiamo caricare mentre siamo online , quando gli utenti stanno lavorando con il sistema.

7. Rispettare le esigenze di migrazione nello sviluppo di applicazioni

I componenti dell'applicazione, come convalide e trigger, dovrebbero essere in grado di gestire le attività di migrazione dei dati. La disabilitazione definitiva delle convalide al momento del carico di migrazione non è un'opzione se il sistema deve essere online. Invece, dobbiamo implementare una logica diversa nelle convalide per le modifiche eseguite da un utente di migrazione dei dati.

• I campi della data non devono essere confrontati con la data di sistema effettiva perché ciò disabiliterebbe il caricamento dei dati storici. Ad esempio, la convalida deve consentire l'inserimento di una data di inizio dell'account passata per i dati migrati.
• I campi obbligatori, che potrebbero non essere popolati con dati storici, devono essere implementati come non obbligatori, ma con validazione sensibile all'utente, consentendo così valori vuoti per i dati provenienti dalla migrazione, ma rifiutando valori vuoti provenienti da utenti regolari tramite la GUI .
• I trigger, in particolare quelli che inviano nuovi record all'integrazione, devono poter essere attivati/disattivati ​​per l'utente della migrazione dei dati al fine di evitare l'allagamento dell'integrazione con i dati migrati.

Un altro trucco consiste nell'utilizzare il campo Legacy ID o Migration ID in ogni oggetto migrato. Ci sono due ragioni per questo. Il primo è ovvio: mantenere l'ID del vecchio sistema per tornare indietro; dopo che i dati sono stati inseriti nel nuovo sistema, le persone potrebbero comunque voler cercare nei propri account utilizzando i vecchi ID, trovati in luoghi come e-mail, documenti e sistemi di tracciamento dei bug. Cattiva abitudine? Forse. Ma gli utenti ti ringrazieranno se conserverai i loro vecchi ID. Il secondo motivo è tecnico e deriva dal fatto che Salesforce non accetta ID forniti esplicitamente per i nuovi record (a differenza di Microsoft Dynamics) ma li genera durante il caricamento. Il problema sorge quando vogliamo caricare oggetti figli perché dobbiamo assegnare loro gli ID degli oggetti principali. Poiché conosceremo quegli ID solo dopo il caricamento, questo è un esercizio inutile.

Usiamo gli Account e i loro Contatti, ad esempio:

1. Genera dati per Account.
2. Carica gli account in Salesforce e ricevi gli ID generati.
3. Incorpora nuovi ID account nei dati di contatto.
4. Genera dati per Contatti.
5. Carica contatti in Salesforce.

Possiamo farlo in modo più semplice caricando gli account con i loro ID legacy archiviati in un campo esterno speciale. Questo campo può essere utilizzato come riferimento principale, quindi durante il caricamento dei contatti, utilizziamo semplicemente l'ID legacy dell'account come puntatore all'account principale:

1. Genera dati per gli account, incluso l'ID legacy.
2. Genera dati per i contatti, incluso l'ID legacy dell'account.
3. Carica gli account in Salesforce.
4. Carica i contatti in Salesforce, utilizzando l'Account Legacy ID come riferimento principale.

La cosa bella qui è che abbiamo separato una generazione e una fase di caricamento, che consente un migliore parallelismo, una riduzione del tempo di interruzione e così via.

8. Prestare attenzione alle caratteristiche specifiche di Salesforce

Come ogni sistema, Salesforce ha molte parti complicate di cui dovremmo essere a conoscenza per evitare spiacevoli sorprese durante la migrazione dei dati. Ecco una manciata di esempi:

• Alcune modifiche sugli Utenti attivi generano automaticamente notifiche e-mail alle e-mail degli utenti. Pertanto, se vogliamo giocare con i dati degli utenti, dobbiamo prima disattivare gli utenti e attivarli dopo che le modifiche sono state completate. Negli ambienti di test, confondiamo le e-mail degli utenti in modo che le notifiche non vengano affatto attivate. Poiché gli utenti attivi consumano licenze costose, non siamo in grado di avere tutti gli utenti attivi in ​​tutti gli ambienti di test. Dobbiamo gestire sottoinsiemi di utenti attivi, ad esempio, per attivare solo quelli in un ambiente di formazione.
• Gli utenti inattivi, per alcuni oggetti standard come Account o Caso, possono essere assegnati solo dopo aver concesso al sistema l'autorizzazione "Aggiorna record con proprietari inattivi", ma possono essere assegnati, ad esempio, ai Contatti e a tutti gli oggetti personalizzati.
• Quando il contatto è disattivato, tutti i campi di disattivazione vengono attivati ​​silenziosamente.
• Quando si carica un membro del team account o un oggetto Condivisione account duplicati, il record esistente viene sovrascritto automaticamente. Tuttavia, quando si carica un Opportunity Partner duplicato, il record viene semplicemente aggiunto, risultando in un duplicato.
• I campi di sistema, come Created Date di creazione , Created By ID , Last Modified Date , Last Modified By ID , possono essere scritti in modo esplicito solo dopo aver concesso una nuova autorizzazione di sistema "Imposta campi di controllo alla creazione del record".
• Le modifiche ai valori della cronologia dei campi non possono essere migrate affatto.
• I proprietari degli articoli della conoscenza non possono essere specificati durante il caricamento, ma possono essere aggiornati in un secondo momento.
• La parte difficile è la memorizzazione dei contenuti (documenti, allegati) in Salesforce. Esistono diversi modi per farlo (usando Allegati, File, Allegati del feed, Documenti) e ogni modo ha i suoi pro e contro, inclusi diversi limiti di dimensione del file.
• I campi dell'elenco di selezione obbligano gli utenti a selezionare uno dei valori consentiti, ad esempio un tipo di account. Ma quando si caricano i dati utilizzando l'API Salesforce (o qualsiasi strumento basato su di essa, come Apex Data Loader o Informatica Salesforce Connector), qualsiasi valore passerà.

L'elenco potrebbe continuare, ma la linea di fondo è: acquisire familiarità con il sistema e imparare cosa può fare e cosa non può fare prima di formulare ipotesi. Non assumere un comportamento standard, specialmente per gli oggetti principali. Ricerca e prova sempre.

9. Non utilizzare Salesforce come piattaforma di migrazione dei dati

È molto allettante utilizzare Salesforce come piattaforma per la creazione di una soluzione di migrazione dei dati, in particolare per gli sviluppatori Salesforce. È la stessa tecnologia per la soluzione di migrazione dei dati come per la personalizzazione dell'applicazione Salesforce, la stessa GUI, lo stesso linguaggio di programmazione Apex, la stessa infrastruttura. Salesforce dispone di oggetti che possono fungere da tabelle e una sorta di linguaggio SQL, Salesforce Object Query Language (SOQL). Tuttavia, per favore non usarlo; sarebbe un difetto architettonico fondamentale.

Salesforce è un'eccellente applicazione SaaS con molte caratteristiche interessanti, come la collaborazione avanzata e la personalizzazione avanzata, ma l'elaborazione di massa dei dati non è una di queste. I tre motivi più significativi sono:

• Prestazioni : l'elaborazione dei dati in Salesforce è di diversi gradi più lenta rispetto a RDBMS.
• Mancanza di funzionalità analitiche : Salesforce SOQL non supporta query complesse e funzioni analitiche che devono essere supportate dal linguaggio Apex e degraderebbe ulteriormente le prestazioni.
• Architettura * – Mettere una piattaforma di migrazione dei dati all'interno di un ambiente Salesforce specifico non è molto conveniente. Di solito, abbiamo più ambienti per scopi specifici, spesso creati ad hoc in modo da poter dedicare molto tempo alla sincronizzazione del codice. Inoltre, faresti affidamento anche sulla connettività e sulla disponibilità di quello specifico ambiente Salesforce.

Crea invece una soluzione di migrazione dei dati in un'istanza separata (potrebbe essere un cloud o in locale) utilizzando una piattaforma RDBMS o ETL. Collegalo ai sistemi di origine e individua gli ambienti Salesforce desiderati, sposta i dati di cui hai bisogno nella tua area di staging ed elaborali lì. Questo ti permetterà di:

• Sfrutta tutta la potenza e le capacità del linguaggio SQL o delle funzionalità ETL.
• Avere tutto il codice e i dati in un'unica posizione in modo da poter eseguire analisi su tutti i sistemi.
  • Ad esempio, è possibile combinare la configurazione più recente dell'ambiente Salesforce di prova più aggiornato con i dati reali dell'ambiente Salesforce di produzione.
• Non sei così dipendente dalla tecnologia dei sistemi di origine e di destinazione e puoi riutilizzare la tua soluzione per il prossimo progetto.

10. Supervisione dei metadati di Salesforce

All'inizio del progetto, di solito prendiamo un elenco di campi Salesforce e iniziamo l'esercizio di mappatura. Durante il progetto, capita spesso che nuovi campi vengano aggiunti dal team di sviluppo dell'applicazione in Salesforce o che alcune proprietà dei campi vengano modificate. Possiamo chiedere al team dell'applicazione di notificare al team di migrazione dei dati ogni modifica del modello di dati, ma non sempre funziona. Per essere sicuri, dobbiamo avere tutte le modifiche al modello di dati sotto supervisione.

Un modo comune per farlo è scaricare, su base regolare, metadati rilevanti per la migrazione da Salesforce in alcuni repository di metadati. Una volta ottenuto questo, non solo possiamo rilevare le modifiche nel modello di dati, ma possiamo anche confrontare i modelli di dati di due ambienti Salesforce.

Quali metadati scaricare:

• Un elenco di oggetti con le loro etichette e nomi tecnici e attributi come creatable o updatable .
• Un elenco di campi con i loro attributi (meglio ottenerli tutti).
• Un elenco di valori dell'elenco di selezione per i campi dell'elenco di selezione. Avremo bisogno di loro per mappare o convalidare i dati di input per i valori corretti.
• Un elenco di convalide, per assicurarsi che le nuove convalide non creino problemi ai dati migrati.

Come scaricare i metadati da Salesforce? Bene, non esiste un metodo di metadati standard, ma ci sono più opzioni:

• Genera Enterprise WSDL: nell'applicazione Web Salesforce, accedere al menu Setup / API e scaricare Enterprise WSDL fortemente tipizzato, che descrivono tutti gli oggetti e i campi in Salesforce (ma non i valori dell'elenco di selezione né le convalide).
• Chiama Salesforce per describeSObjects il servizio Web SObjects, direttamente o utilizzando il wrapper Java o C# (consultare l'API Salesforce). In questo modo, ottieni ciò di cui hai bisogno e questo è il modo consigliato per esportare i metadati.
• Utilizza uno dei numerosi strumenti alternativi disponibili su Internet.

Preparati per la prossima migrazione dei dati

Le soluzioni cloud, come Salesforce, sono pronte all'istante. Se sei soddisfatto delle funzionalità integrate, accedi e utilizzalo. Tuttavia, Salesforce, come qualsiasi altra soluzione CRM cloud, pone problemi specifici agli argomenti di migrazione dei dati di cui essere consapevoli, in particolare per quanto riguarda le prestazioni e i limiti delle risorse.

Lo spostamento dei dati legacy nel nuovo sistema è sempre un viaggio, a volte un viaggio nella storia nascosta nei dati degli anni passati. In questo articolo, basato su una dozzina di progetti di migrazione, ho presentato dieci suggerimenti su come migrare i dati legacy ed evitare con successo la maggior parte delle insidie.

La chiave è capire cosa rivelano i dati. Quindi, prima di iniziare la migrazione dei dati, assicurati che il tuo team di sviluppo Salesforce sia ben preparato per i potenziali problemi che i tuoi dati potrebbero avere.