Migrați datele moștenite fără a le strica

Migrarea datelor moștenite este dificilă.

Multe organizații au vechi și complexe sisteme CRM de afaceri on-premise. Astăzi, există o mulțime de alternative cloud SaaS, care vin cu multe beneficii; plătiți pe măsură ce mergeți și să plătiți numai pentru ceea ce utilizați. Prin urmare, ei decid să treacă la noile sisteme.

Nimeni nu vrea să lase date valoroase despre clienți în vechiul sistem și să înceapă cu noul sistem gol, așa că trebuie să migrăm aceste date. Din păcate, migrarea datelor nu este o sarcină ușoară, deoarece aproximativ 50% din efortul de implementare este consumat de activitățile de migrare a datelor. Potrivit Gartner, Salesforce este liderul soluțiilor cloud CRM. Prin urmare, migrarea datelor este un subiect major pentru implementarea Salesforce.

Deci, cum putem asigura o tranziție cu succes a datelor moștenite într-un sistem nou strălucitor și să ne asigurăm că vom păstra toată istoria acestuia? În acest articol, vă ofer 10 sfaturi pentru o migrare reușită a datelor. Primele cinci sfaturi se aplică oricărei migrări de date, indiferent de tehnologia utilizată.

Migrarea datelor în general

1. Faceți din migrație un proiect separat

În lista de verificare a implementării software-ului, migrarea datelor nu este un element „export și import” gestionat de un instrument inteligent de migrare a datelor „apăsând un singur buton” care are mapare predefinită pentru sistemele țintă.

Migrarea datelor este o activitate complexă, care merită un proiect, un plan, o abordare, un buget și o echipă separate. Un domeniu de aplicare și un plan la nivel de entitate trebuie să fie create la începutul proiectului, asigurând nicio surpriză, cum ar fi „Oh, am uitat să încărcăm rapoartele de vizită ale acelor clienți, cine va face asta?” cu două săptămâni înainte de termenul limită.

Abordarea migrației datelor definește dacă vom încărca datele dintr-o singură mișcare (cunoscut și sub numele de big bang ) sau dacă vom încărca loturi mici în fiecare săptămână.

Aceasta nu este o decizie ușoară, totuși. Abordarea trebuie convenită și comunicată tuturor părților interesate de afaceri și tehnice, astfel încât toată lumea să știe când și ce date vor apărea în noul sistem. Acest lucru este valabil și pentru întreruperile sistemului.

2. Estimați realist

Nu subestimați complexitatea migrării datelor. Multe sarcini consumatoare de timp însoțesc acest proces, care poate fi invizibil la începutul proiectului.

De exemplu, încărcarea unor seturi de date specifice în scopuri de instruire cu o grămadă de date realiste, dar cu elemente sensibile ascunse, astfel încât activitățile de instruire să nu genereze notificări prin e-mail către clienți.

Factorul de bază pentru estimare este numărul de câmpuri care trebuie transferate de la un sistem sursă la un sistem țintă.

Este nevoie de o anumită perioadă de timp în diferite etape ale proiectului pentru fiecare domeniu, inclusiv înțelegerea câmpului, maparea câmpului sursă la câmpul țintă, configurarea sau construirea transformărilor, efectuarea de teste, măsurarea calității datelor pentru domeniu și așa mai departe.

Utilizarea unor instrumente inteligente, cum ar fi Jitterbit, Informatica Cloud Data Wizard, Starfish ETL, Midas și altele asemenea, poate reduce acest timp, mai ales în faza de construire.

În special, înțelegerea datelor sursă – cea mai importantă sarcină în orice proiect de migrare – nu poate fi automatizată de instrumente, dar necesită analiștilor să-și ia timp să parcurgă lista de câmpuri unul câte unul.

Cea mai simplă estimare a efortului total este o zi om pentru fiecare domeniu transferat din sistemul moștenit.

O excepție este replicarea datelor între aceleași scheme sursă și țintă fără alte transformări – uneori cunoscută sub numele de migrare 1:1 – unde putem baza estimarea pe numărul de tabele de copiat.

O estimare detaliată este o artă în sine.

3. Verificați calitatea datelor

Nu supraestimați calitatea datelor sursă, chiar dacă nu sunt raportate probleme legate de calitatea datelor din sistemele vechi.

Noile sisteme au reguli noi, care pot fi încălcate cu date vechi. Iată un exemplu simplu. E-mailul de contact poate fi obligatoriu în noul sistem, dar un sistem vechi de 20 de ani poate avea un punct de vedere diferit.

Pot exista mine ascunse în datele istorice care nu au fost atinse de mult timp, dar care s-ar putea activa la transferul în noul sistem. De exemplu, datele vechi care folosesc monede europene care nu mai există trebuie convertite în euro, în caz contrar, monedele trebuie adăugate la noul sistem.

Calitatea datelor influențează semnificativ efortul, iar regula simplă este: cu cât mergem mai departe în istorie, cu atât mai mare dezordine vom descoperi. Prin urmare, este vital să decidem din timp câtă istorie vrem să transferăm în noul sistem.

4. Implicați oamenii de afaceri

Oamenii de afaceri sunt singurii care înțeleg cu adevărat datele și, prin urmare, pot decide ce date pot fi aruncate și ce date să păstreze.

Este important să fie implicat pe cineva din echipa de afaceri în timpul exercițiului de cartografiere, iar pentru viitor, este util să se înregistreze deciziile de cartografiere și motivele acestora.

Deoarece o imagine valorează mai mult decât o mie de cuvinte, încărcați un lot de testare în noul sistem și lăsați echipa de afaceri să se joace cu ea.

Chiar dacă maparea migrației datelor este revizuită și aprobată de echipa de afaceri, pot apărea surprize odată ce datele apar în interfața de utilizare a noului sistem.

„Oh, acum înțeleg, trebuie să o schimbăm puțin”, devine o expresie comună.

Eșecul de a angaja experți în domeniu, care sunt de obicei oameni foarte ocupați, este cea mai frecventă cauză a problemelor după lansarea unui nou sistem.

5. Vizualizați soluția de migrare automată

Migrarea datelor este adesea privită ca o activitate unică, iar dezvoltatorii tind să ajungă la soluții pline de acțiuni manuale, sperând să le execute o singură dată. Dar există multe motive pentru a evita o astfel de abordare.

• Dacă migrația este împărțită în mai multe valuri, trebuie să repetăm ​​aceleași acțiuni de mai multe ori.
• În mod obișnuit, există cel puțin trei rulări de migrare pentru fiecare val: o rulare uscată pentru a testa performanța și funcționalitatea migrării datelor, o încărcare completă de validare a datelor pentru a testa întregul set de date și pentru a efectua teste de afaceri și, bineînțeles, încărcarea de producție. Numărul de rulări crește cu o calitate slabă a datelor. Îmbunătățirea calității datelor este un proces iterativ, așa că avem nevoie de mai multe iterații pentru a ajunge la rata de succes dorită.

Astfel, chiar dacă migrarea este o activitate unică prin natura sa, acțiunile manuale vă pot încetini semnificativ operațiunile.

Migrarea datelor Salesforce

În continuare, vom acoperi cinci sfaturi pentru o migrare de succes a Salesforce. Rețineți că aceste sfaturi sunt probabil aplicabile și altor soluții cloud.

6. Pregătiți-vă pentru încărcături lungi

Performanța este unul dintre, dacă nu cel mai mare, compromis atunci când treceți de la o soluție on-premise la o soluție cloud – Salesforce nu este exclus.

Sistemele on-premise permit, de obicei, încărcarea directă a datelor într-o bază de date de bază și, cu un hardware bun, putem ajunge cu ușurință la milioane de înregistrări pe oră.

Dar, nu în nor. În cloud, suntem puternic limitați de mai mulți factori.

• Latența rețelei – Datele sunt transferate prin internet.
• Stratul de aplicație Salesforce – Datele sunt mutate printr-un strat gros de API multitenancy până când ajung în bazele lor de date Oracle.
• Cod personalizat în Salesforce – validări personalizate, declanșatoare, fluxuri de lucru, reguli de detectare a duplicării și așa mai departe – multe dintre ele dezactivează încărcările paralele sau în bloc.

Ca rezultat, performanța de încărcare poate fi de mii de conturi pe oră.

Poate fi mai puțin, sau poate fi mai mult, în funcție de lucruri, cum ar fi numărul de câmpuri, validări și declanșatoare. Dar este cu câteva grade mai lent decât încărcarea directă a bazei de date.

Degradarea performanței, care depinde de volumul datelor din Salesforce, trebuie de asemenea luată în considerare.

Este cauzată de indici din RDBMS-ul de bază (Oracle) utilizați pentru verificarea cheilor străine, câmpurile unice și evaluarea regulilor de duplicare. Formula de bază este o încetinire de aproximativ 50% pentru fiecare nota de 10, cauzată de O(logN) porțiunea de complexitate a timpului în operațiunile de sortare și B-tree.

În plus, Salesforce are multe limite de utilizare a resurselor.

Una dintre ele este limita Bulk API stabilită la 5.000 de loturi în ferestre rulante de 24 de ore, cu maximum 10.000 de înregistrări în fiecare lot.

Deci, maximul teoretic este de 50 de milioane de înregistrări încărcate în 24 de ore.

Într-un proiect real, maximul este mult mai mic datorită dimensiunii lotului limitat atunci când se utilizează, de exemplu, declanșatoare personalizate.

Acest lucru are un impact puternic asupra abordării migrării datelor.

Chiar și pentru seturile de date de dimensiuni medii (de la 100.000 la 1 milion de conturi), abordarea big bang este exclusă, așa că trebuie să împărțim datele în valuri mai mici de migrare.

Acest lucru, desigur, are un impact asupra întregului proces de implementare și crește complexitatea migrării, deoarece vom adăuga incremente de date într-un sistem deja populat de migrațiile anterioare și datele introduse de utilizatori.

De asemenea, trebuie să luăm în considerare aceste date existente în transformările și validările migrației.

În plus, încărcările îndelungate pot însemna că nu putem efectua migrări în timpul unei întreruperi a sistemului.

Dacă toți utilizatorii sunt localizați într-o singură țară, putem folosi o întrerupere de opt ore în timpul nopții.

Dar pentru o companie, precum Coca-Cola, cu operațiuni în toată lumea, asta nu este posibil. Odată ce avem SUA, Japonia și Europa în sistem, acoperim toate fusurile orare, așa că sâmbăta este singura opțiune de întrerupere care nu afectează utilizatorii.

Și asta poate să nu fie suficient, așa că trebuie să încărcăm în timp ce sunt online , când utilizatorii lucrează cu sistemul.

7. Respectați nevoile de migrație în dezvoltarea aplicațiilor

Componentele aplicației, cum ar fi validările și declanșatoarele, ar trebui să poată gestiona activitățile de migrare a datelor. Dezactivarea completă a validărilor în momentul încărcării migrației nu este o opțiune dacă sistemul trebuie să fie online. În schimb, trebuie să implementăm o logică diferită în validările pentru modificările efectuate de un utilizator de migrare a datelor.

• Câmpurile de dată nu trebuie comparate cu data reală a sistemului, deoarece aceasta ar dezactiva încărcarea datelor istorice. De exemplu, validarea trebuie să permită introducerea unei date anterioare de începere a contului pentru datele migrate.
• Câmpurile obligatorii, care este posibil să nu fie completate cu date istorice, trebuie implementate ca neobligatorii, dar cu validare sensibilă la utilizator, permițând astfel valori goale pentru datele care provin din migrare, dar respingând valorile goale provenite de la utilizatorii obișnuiți prin intermediul GUI .
• Declanșatorii, în special cei care trimit noi înregistrări către integrare, trebuie să poată fi activați/dezactivați pentru utilizatorul de migrare a datelor pentru a preveni inundarea integrării cu date migrate.

Un alt truc este utilizarea câmpului Legacy ID sau Migration ID în fiecare obiect migrat. Există două motive pentru aceasta. Primul este evident: pentru a păstra ID-ul din vechiul sistem pentru backtracking; după ce datele sunt în noul sistem, oamenii pot dori în continuare să-și caute conturile folosind vechile ID-uri, găsite în locuri ca e-mailuri, documente și sisteme de urmărire a erorilor. Obicei prost? Pot fi. Dar utilizatorii vă vor mulțumi dacă le păstrați vechile ID-uri. Al doilea motiv este tehnic și provine din faptul că Salesforce nu acceptă ID-urile furnizate în mod explicit pentru înregistrările noi (spre deosebire de Microsoft Dynamics), dar le generează în timpul încărcării. Problema apare atunci când dorim să încărcăm obiecte copil deoarece trebuie să le atribuim ID-uri ale obiectelor părinte. Deoarece vom cunoaște acele ID-uri numai după încărcare, acesta este un exercițiu inutil.

Să folosim Conturile și persoanele de contact ale acestora, de exemplu:

1. Generați date pentru Conturi.
2. Încărcați Conturi în Salesforce și primiți ID-urile generate.
3. Încorporați ID-uri de cont noi în datele de contact.
4. Generați date pentru Contacte.
5. Încărcați contacte în Salesforce.

Putem face acest lucru mai simplu încărcând Conturi cu ID-urile lor vechi stocate într-un câmp extern special. Acest câmp poate fi folosit ca referință pentru părinte, așa că atunci când încărcăm Contacte, pur și simplu folosim ID-ul moștenit al contului ca indicator către contul părinte:

1. Generați date pentru Conturi, inclusiv ID-ul vechi.
2. Generați date pentru Agendă, inclusiv ID-ul vechi al contului.
3. Încărcați conturi în Salesforce.
4. Încărcați persoanele de contact în Salesforce, folosind ID-ul moștenit al contului ca referință pentru părinte.

Lucrul frumos aici este că am separat o generație și o fază de încărcare, ceea ce permite un paralelism mai bun, reducerea timpului de întrerupere și așa mai departe.

8. Fiți conștienți de caracteristicile specifice Salesforce

Ca orice sistem, Salesforce are o mulțime de părți complicate de care ar trebui să fim conștienți pentru a evita surprizele neplăcute în timpul migrării datelor. Iată câteva exemple:

• Unele modificări ale utilizatorilor activi generează automat notificări prin e-mail către e-mailurile utilizatorilor. Astfel, dacă vrem să ne jucăm cu datele utilizatorului, trebuie să dezactivăm mai întâi utilizatorii și să activăm după finalizarea modificărilor. În mediile de testare, amestecăm e-mailurile utilizatorilor, astfel încât notificările să nu fie lansate deloc. Deoarece utilizatorii activi consumă licențe costisitoare, nu putem avea toți utilizatorii activi în toate mediile de testare. Trebuie să gestionăm subseturi de utilizatori activi, de exemplu, pentru a-i activa doar pe cei dintr-un mediu de antrenament.
• Utilizatorii inactivi, pentru unele obiecte standard, cum ar fi Cont sau Caz, pot fi alocați numai după acordarea permisiunii de sistem „Actualizați înregistrările cu proprietari inactivi”, dar pot fi alocați, de exemplu, la Contacte și la toate obiectele personalizate.
• Când Contact este dezactivat, toate câmpurile de renunțare sunt activate în tăcere.
• Când încărcați un obiect duplicat de membru al echipei de cont sau de partajare a contului, înregistrarea existentă este suprascrisă în tăcere. Cu toate acestea, la încărcarea unui partener de oportunitate duplicat, înregistrarea este pur și simplu adăugată, rezultând o duplicare.
• Câmpurile de sistem, cum ar fi Created Date , Created By ID , Last Modified Date , Last Modified By ID , pot fi scrise în mod explicit numai după acordarea unei noi permisiuni de sistem „Setați câmpurile de audit la crearea înregistrării”.
• Modificările valorii istoricului câmpului nu pot fi migrate deloc.
• Proprietarii articolelor de cunoștințe nu pot fi specificați în timpul încărcării, dar pot fi actualizați ulterior.
• Partea dificilă este stocarea conținutului (documente, atașamente) în Salesforce. Există mai multe moduri de a face acest lucru (folosind atașamente, fișiere, atașamente de feed, documente) și fiecare mod are avantajele și dezavantajele sale, inclusiv limite diferite de dimensiune a fișierului.
• Câmpurile de selecție obligă utilizatorii să selecteze una dintre valorile permise, de exemplu, un tip de cont. Dar atunci când încărcați date folosind API-ul Salesforce (sau orice instrument construit pe acesta, cum ar fi Apex Data Loader sau conectorul Informatica Salesforce), orice valoare va trece.

Lista continuă, dar concluzia este: familiarizați-vă cu sistemul și aflați ce poate face și ce nu poate face înainte de a face presupuneri. Nu vă asumați un comportament standard, în special pentru obiectele de bază. Întotdeauna cercetați și testați.

9. Nu utilizați Salesforce ca platformă de migrare a datelor

Este foarte tentant să folosiți Salesforce ca platformă pentru construirea unei soluții de migrare a datelor, în special pentru dezvoltatorii Salesforce. Este aceeași tehnologie pentru soluția de migrare a datelor ca și pentru personalizarea aplicației Salesforce, aceeași GUI, același limbaj de programare Apex, aceeași infrastructură. Salesforce are obiecte care pot acționa ca tabele și un fel de limbaj SQL, Salesforce Object Query Language (SOQL). Cu toate acestea, vă rugăm să nu-l utilizați; ar fi un defect arhitectural fundamental.

Salesforce este o aplicație SaaS excelentă, cu o mulțime de caracteristici frumoase, cum ar fi colaborarea avansată și personalizarea bogată, dar procesarea în masă a datelor nu este una dintre ele. Cele mai importante trei motive sunt:

• Performanță – Procesarea datelor în Salesforce este cu câteva grade mai lentă decât în ​​RDBMS.
• Lipsa caracteristicilor analitice – Salesforce SOQL nu acceptă interogări complexe și funcții analitice care trebuie să fie acceptate de limbajul Apex și ar degrada și mai mult performanța.
• Arhitectură * – Nu este foarte convenabilă introducerea unei platforme de migrare a datelor într-un anumit mediu Salesforce. De obicei, avem mai multe medii pentru scopuri specifice, adesea create ad-hoc, astfel încât să putem pune mult timp pe sincronizarea codului. În plus, vă veți baza, de asemenea, pe conectivitatea și disponibilitatea acelui mediu Salesforce specific.

În schimb, construiți o soluție de migrare a datelor într-o instanță separată (ar putea fi un cloud sau on-premise) folosind o platformă RDBMS sau ETL. Conectați-l cu sistemele sursă și vizați mediile Salesforce pe care le doriți, mutați datele de care aveți nevoie în zona dvs. de pregătire și procesați-le acolo. Acest lucru vă va permite să:

• Profitați de toată puterea și capacitățile limbajului SQL sau ale caracteristicilor ETL.
• Aveți tot codul și datele într-un singur loc, astfel încât să puteți efectua analize pe toate sistemele.
  • De exemplu, puteți combina cea mai nouă configurație din cel mai recent mediu de testare Salesforce cu date reale din mediul de producție Salesforce.
• Nu sunteți atât de dependent de tehnologia sistemelor sursă și țintă și vă puteți reutiliza soluția pentru următorul proiect.

10. Supravegherea metadatelor Salesforce

La începutul proiectului, luăm de obicei o listă de câmpuri Salesforce și începem exercițiul de mapare. În timpul proiectului, se întâmplă adesea ca echipa de dezvoltare a aplicației să adauge noi câmpuri în Salesforce sau ca unele proprietăți ale câmpului să fie modificate. Putem cere echipei aplicației să notifice echipa de migrare a datelor despre fiecare modificare a modelului de date, dar nu funcționează întotdeauna. Pentru a fi în siguranță, trebuie să avem toate modificările modelului de date sub supraveghere.

O modalitate obișnuită de a face acest lucru este să descărcați, în mod regulat, metadate relevante pentru migrare din Salesforce într-un depozit de metadate. Odată ce avem acest lucru, nu numai că putem detecta modificări în modelul de date, dar putem și compara modele de date a două medii Salesforce.

Ce metadate să descărcați:

• O listă de obiecte cu etichetele și denumirile și atributele tehnice ale acestora, cum ar fi creatable sau updatable .
• O listă de câmpuri cu atributele lor (mai bine să le obțineți pe toate).
• O listă de valori ale listei de selectare pentru câmpurile listei de selectare. Vom avea nevoie de ei pentru a mapa sau a valida datele de intrare pentru valorile corecte.
• O listă de validări, pentru a vă asigura că noile validări nu creează probleme pentru datele migrate.

Cum să descărcați metadate din Salesforce? Ei bine, nu există o metodă standard de metadate, dar există mai multe opțiuni:

• Generați Enterprise WSDL – În aplicația web Salesforce, navigați la meniul Setup / API și descărcați Enterprise WSDL puternic scris, care descriu toate obiectele și câmpurile din Salesforce (dar nu valorile listei de selectare sau validările).
• Apelați serviciul web Salesforce describeSObjects , direct sau utilizând Java sau C# wrapper (consultați API-ul Salesforce). În acest fel, obțineți ceea ce aveți nevoie și acesta este modalitatea recomandată de a exporta metadatele.
• Utilizați oricare dintre numeroasele instrumente alternative disponibile pe internet.

Pregătiți-vă pentru următoarea migrare a datelor

Soluțiile cloud, cum ar fi Salesforce, sunt gata instantaneu. Dacă sunteți mulțumit de funcționalitățile încorporate, trebuie doar să vă conectați și să îl utilizați. Cu toate acestea, Salesforce, ca orice altă soluție CRM în cloud, aduce probleme specifice subiectelor de migrare a datelor de care trebuie să fiți conștienți, în special, în ceea ce privește limitele de performanță și resurse.

Mutarea datelor moștenite în noul sistem este întotdeauna o călătorie, uneori o călătorie către istorie ascunsă în datele din anii trecuți. În acest articol, bazat pe o duzină de proiecte de migrare, am prezentat zece sfaturi despre cum să migrați datele vechi și să evitați cu succes cele mai multe capcane.

Cheia este să înțelegeți ce dezvăluie datele. Așadar, înainte de a începe migrarea datelor, asigurați-vă că echipa de dezvoltare Salesforce este bine pregătită pentru potențialele probleme pe care le pot apărea datele dvs.