Migrasikan Data Lama Tanpa Mengacaukannya

Memigrasikan data lama itu sulit.

Banyak organisasi memiliki sistem CRM bisnis on-premise yang lama dan kompleks. Saat ini, ada banyak alternatif SaaS cloud, yang hadir dengan banyak manfaat; bayar sesuai pemakaian dan bayar hanya untuk apa yang Anda gunakan. Oleh karena itu, mereka memutuskan untuk pindah ke sistem baru.

Tidak ada yang ingin meninggalkan data berharga tentang pelanggan di sistem lama dan memulai dengan sistem baru yang kosong, jadi kami perlu memigrasikan data ini. Sayangnya, migrasi data bukanlah tugas yang mudah, karena sekitar 50 persen upaya penerapan digunakan oleh aktivitas migrasi data. Menurut Gartner, Salesforce adalah pemimpin solusi cloud CRM. Oleh karena itu, migrasi data adalah topik utama untuk penerapan Salesforce.

Jadi, bagaimana kami dapat memastikan transisi yang sukses dari data lama ke sistem baru yang mengkilap dan memastikan kami akan mempertahankan semua riwayatnya? Pada artikel ini, saya memberikan 10 tips untuk migrasi data yang sukses. Lima tips pertama berlaku untuk migrasi data apa pun, apa pun teknologi yang digunakan.

Migrasi Data Secara Umum

1. Jadikan Migrasi sebagai Proyek Terpisah

Dalam daftar periksa penerapan perangkat lunak, migrasi data bukanlah item "ekspor dan impor" yang ditangani oleh alat migrasi data "tekan satu tombol" pintar yang memiliki pemetaan yang telah ditentukan sebelumnya untuk sistem target.

Migrasi data adalah aktivitas yang kompleks, memerlukan proyek, rencana, pendekatan, anggaran, dan tim yang terpisah. Lingkup dan rencana tingkat entitas harus dibuat di awal proyek, memastikan tidak ada kejutan, seperti "Oh, kami lupa memuat laporan kunjungan klien itu, siapa yang akan melakukannya?" dua minggu sebelum batas waktu.

Pendekatan migrasi data menentukan apakah kita akan memuat data sekaligus (juga dikenal sebagai big bang ), atau apakah kita akan memuat batch kecil setiap minggu.

Ini bukan keputusan yang mudah, meskipun. Pendekatan tersebut harus disepakati dan dikomunikasikan kepada semua pemangku kepentingan bisnis dan teknis sehingga semua orang mengetahui kapan dan data apa yang akan muncul dalam sistem baru. Ini berlaku untuk pemadaman sistem juga.

2. Perkirakan Secara Realistis

Jangan remehkan kerumitan migrasi data. Banyak tugas yang memakan waktu menyertai proses ini, yang mungkin tidak terlihat di awal proyek.

Misalnya, memuat kumpulan data tertentu untuk tujuan pelatihan dengan sekumpulan data realistis, tetapi dengan item sensitif yang dikaburkan, sehingga aktivitas pelatihan tidak menghasilkan pemberitahuan email kepada klien.

Faktor dasar untuk estimasi adalah jumlah bidang yang akan ditransfer dari sistem sumber ke sistem target.

Sejumlah waktu diperlukan dalam berbagai tahap proyek untuk setiap bidang, termasuk memahami bidang, memetakan bidang sumber ke bidang target, mengonfigurasi atau membangun transformasi, melakukan pengujian, mengukur kualitas data untuk bidang tersebut, dan sebagainya.

Menggunakan alat pintar, seperti Jitterbit, Informatica Cloud Data Wizard, Starfish ETL, Midas, dan sejenisnya, dapat mengurangi waktu ini, terutama dalam fase build.

Secara khusus, memahami data sumber – tugas paling penting dalam proyek migrasi apa pun – tidak dapat diotomatisasi oleh alat, tetapi memerlukan analis untuk meluangkan waktu menelusuri daftar bidang satu per satu.

Perkiraan paling sederhana dari upaya keseluruhan adalah satu hari kerja untuk setiap bidang yang ditransfer dari sistem lama.

Pengecualian adalah replikasi data antara skema sumber dan target yang sama tanpa transformasi lebih lanjut – terkadang dikenal sebagai migrasi 1:1 – di mana kita dapat mendasarkan perkiraan pada jumlah tabel yang akan disalin.

Perkiraan terperinci adalah seninya sendiri.

3. Periksa Kualitas Data

Jangan melebih-lebihkan kualitas data sumber, meskipun tidak ada masalah kualitas data yang dilaporkan dari sistem lama.

Sistem baru memiliki aturan baru, yang mungkin dilanggar dengan data lama. Berikut adalah contoh sederhana. Email kontak dapat menjadi wajib di sistem baru, tetapi sistem lama yang berusia 20 tahun mungkin memiliki sudut pandang yang berbeda.

Mungkin ada ranjau yang tersembunyi dalam data historis yang sudah lama tidak disentuh tetapi dapat diaktifkan saat mentransfer ke sistem baru. Misalnya, data lama menggunakan mata uang Eropa yang tidak ada lagi perlu dikonversi ke Euro, jika tidak, mata uang harus ditambahkan ke sistem baru.

Kualitas data secara signifikan memengaruhi upaya, dan aturan sederhananya adalah: Semakin jauh kita menelusuri sejarah, semakin besar kekacauan yang akan kita temukan. Jadi, sangat penting untuk memutuskan sejak awal berapa banyak sejarah yang ingin kita transfer ke dalam sistem baru.

4. Libatkan Pebisnis

Pelaku bisnis adalah satu-satunya yang benar-benar memahami data dan oleh karena itu dapat memutuskan data apa yang dapat dibuang dan data apa yang harus disimpan.

Penting untuk melibatkan seseorang dari tim bisnis selama latihan pemetaan, dan untuk pelacakan balik di masa mendatang, akan berguna untuk mencatat keputusan pemetaan dan alasannya.

Karena sebuah gambar bernilai lebih dari seribu kata, muat kumpulan uji ke dalam sistem baru, dan biarkan tim bisnis memainkannya.

Bahkan jika pemetaan migrasi data ditinjau dan disetujui oleh tim bisnis, kejutan dapat muncul setelah data muncul di UI sistem baru.

“Oh, sekarang saya mengerti, kita harus mengubahnya sedikit,” menjadi ungkapan umum.

Gagal melibatkan pakar materi pelajaran, yang biasanya adalah orang-orang yang sangat sibuk, adalah penyebab paling umum masalah setelah sistem baru diluncurkan.

5. Bertujuan untuk Solusi Migrasi Otomatis

Migrasi data sering dipandang sebagai aktivitas satu kali, dan pengembang cenderung berakhir dengan solusi yang penuh dengan tindakan manual yang berharap untuk menjalankannya hanya sekali. Tetapi ada banyak alasan untuk menghindari pendekatan seperti itu.

• Jika migrasi dibagi menjadi beberapa gelombang, kita harus mengulangi tindakan yang sama beberapa kali.
• Biasanya, setidaknya ada tiga proses migrasi untuk setiap gelombang: uji coba kering untuk menguji kinerja dan fungsionalitas migrasi data, beban validasi data lengkap untuk menguji seluruh kumpulan data dan untuk melakukan uji bisnis, dan tentu saja, beban produksi. Jumlah proses meningkat dengan kualitas data yang buruk. Meningkatkan kualitas data merupakan proses yang berulang, sehingga diperlukan beberapa iterasi untuk mencapai rasio keberhasilan yang diinginkan.

Jadi, meskipun migrasi pada dasarnya adalah aktivitas satu kali, tindakan manual dapat memperlambat operasi Anda secara signifikan.

Migrasi Data Tenaga Penjualan

Selanjutnya kita akan membahas lima tips untuk migrasi Salesforce yang sukses. Perlu diingat, tips ini kemungkinan juga berlaku untuk solusi cloud lainnya.

6. Bersiaplah untuk Beban yang Panjang

Performa adalah salah satu, jika bukan yang terbesar, tradeoff saat berpindah dari solusi lokal ke solusi cloud – Salesforce tidak dikecualikan.

Sistem di tempat biasanya memungkinkan pemuatan data langsung ke basis data yang mendasarinya, dan dengan perangkat keras yang baik, kami dapat dengan mudah mencapai jutaan catatan per jam.

Tapi, tidak di awan. Di cloud, kami sangat dibatasi oleh beberapa faktor.

• Latensi jaringan – Data ditransfer melalui internet.
• Lapisan aplikasi Salesforce – Data dipindahkan melalui lapisan multipenyewaan API yang tebal hingga mereka mendarat di database Oracle.
• Kode kustom di Salesforce – Validasi kustom, pemicu, alur kerja, aturan deteksi duplikasi, dan sebagainya – banyak di antaranya menonaktifkan pemuatan paralel atau massal.

Alhasil, kinerja beban bisa ribuan akun per jam.

Itu bisa kurang, atau bisa lebih, tergantung pada hal-hal, seperti jumlah bidang, validasi, dan pemicu. Tapi ini beberapa tingkat lebih lambat dari beban database langsung.

Penurunan kinerja, yang bergantung pada volume data di Salesforce, juga harus dipertimbangkan.

Hal ini disebabkan oleh indeks dalam RDBMS (Oracle) yang mendasari yang digunakan untuk memeriksa kunci asing, bidang unik, dan evaluasi aturan duplikasi. Rumus dasarnya adalah perlambatan sekitar 50 persen untuk setiap grade 10, yang disebabkan oleh O(logN) porsi kompleksitas waktu dalam operasi sortir dan B-tree.

Selain itu, Salesforce memiliki banyak batasan penggunaan sumber daya.

Salah satunya adalah batas API Massal yang ditetapkan ke 5.000 batch dalam jendela bergulir 24 jam, dengan maksimum 10.000 catatan di setiap batch.

Jadi, maksimum teoritis adalah 50 juta catatan yang dimuat dalam 24 jam.

Dalam proyek nyata, maksimumnya jauh lebih rendah karena ukuran kumpulan terbatas saat menggunakan, misalnya, pemicu khusus.

Ini memiliki dampak yang kuat pada pendekatan migrasi data.

Bahkan untuk kumpulan data berukuran sedang (dari 100.000 hingga 1 juta akun), pendekatan big bang tidak mungkin dilakukan, jadi kita harus membagi data menjadi gelombang migrasi yang lebih kecil.

Ini, tentu saja, berdampak pada seluruh proses penerapan dan meningkatkan kompleksitas migrasi karena kami akan menambahkan penambahan data ke dalam sistem yang sudah diisi oleh migrasi sebelumnya dan data yang dimasukkan oleh pengguna.

Kita juga harus mempertimbangkan data yang ada ini dalam transformasi dan validasi migrasi.

Selanjutnya, beban yang lama dapat berarti kami tidak dapat melakukan migrasi selama gangguan sistem.

Jika semua pengguna berada di satu negara, kami dapat memanfaatkan pemadaman delapan jam pada malam hari.

Tetapi untuk perusahaan, seperti Coca-Cola, dengan operasi di seluruh dunia, itu tidak mungkin. Setelah kami memiliki AS, Jepang, dan Eropa dalam sistem, kami menjangkau semua zona waktu, jadi Sabtu adalah satu-satunya opsi pemadaman yang tidak memengaruhi pengguna.

Dan itu mungkin tidak cukup, jadi, kita harus memuat saat online , ketika pengguna bekerja dengan sistem.

7. Hormati Kebutuhan Migrasi dalam Pengembangan Aplikasi

Komponen aplikasi, seperti validasi dan pemicu, harus mampu menangani aktivitas migrasi data. Penonaktifan validasi secara paksa pada saat pemuatan migrasi bukan merupakan opsi jika sistem harus online. Sebagai gantinya, kita harus menerapkan logika yang berbeda dalam validasi untuk perubahan yang dilakukan oleh pengguna migrasi data.

• Bidang tanggal tidak boleh dibandingkan dengan tanggal sistem yang sebenarnya karena itu akan menonaktifkan pemuatan data historis. Misalnya, validasi harus mengizinkan memasukkan tanggal mulai akun yang lalu untuk data yang dimigrasikan.
• Bidang wajib, yang mungkin tidak diisi dengan data historis, harus diimplementasikan sebagai tidak wajib, tetapi dengan validasi yang sensitif terhadap pengguna, sehingga memungkinkan nilai kosong untuk data yang berasal dari migrasi, tetapi menolak nilai kosong yang berasal dari pengguna biasa melalui GUI .
• Pemicu, terutama yang mengirim catatan baru ke integrasi, harus dapat diaktifkan/dinonaktifkan untuk pengguna migrasi data untuk mencegah integrasi dengan data yang dimigrasikan.

Trik lainnya adalah menggunakan bidang Legacy ID atau Migration ID di setiap objek yang dimigrasikan. Ada dua alasan untuk ini. Yang pertama sudah jelas: Untuk menjaga ID dari sistem lama untuk backtracking; setelah data ada di sistem baru, orang mungkin masih ingin mencari akun mereka menggunakan ID lama, yang ditemukan di tempat-tempat seperti email, dokumen, dan sistem pelacakan bug. Kebiasaan buruk? Mungkin. Tetapi pengguna akan berterima kasih jika Anda mempertahankan ID lama mereka. Alasan kedua adalah teknis dan berasal dari fakta bahwa Salesforce tidak menerima ID yang diberikan secara eksplisit untuk catatan baru (tidak seperti Microsoft Dynamics) tetapi menghasilkannya selama pemuatan. Masalah muncul ketika kita ingin memuat objek anak karena kita harus menetapkan mereka ID dari objek induk. Karena kita akan mengetahui ID itu hanya setelah memuat, ini adalah latihan yang sia-sia.

Mari kita gunakan Akun dan Kontaknya, misalnya:

1. Hasilkan data untuk Akun.
2. Muat Akun ke Salesforce, dan terima ID yang dihasilkan.
3. Masukkan ID Akun baru dalam data Kontak.
4. Hasilkan data untuk Kontak.
5. Muat Kontak di Salesforce.

Kita dapat melakukan ini lebih sederhana dengan memuat Akun dengan ID Legacy mereka yang disimpan di bidang eksternal khusus. Bidang ini dapat digunakan sebagai referensi induk, jadi saat memuat Kontak, kita cukup menggunakan ID Legacy Akun sebagai penunjuk ke Akun induk:

1. Hasilkan data untuk Akun, termasuk Legacy ID.
2. Hasilkan data untuk Kontak, termasuk ID Legacy Akun.
3. Muat Akun ke Salesforce.
4. Muat Kontak di Salesforce, menggunakan ID Legacy Akun sebagai referensi induk.

Hal yang menyenangkan di sini adalah kami telah memisahkan generasi dan fase pemuatan, yang memungkinkan paralelisme yang lebih baik, mengurangi waktu pemadaman, dan sebagainya.

8. Waspadai Fitur Khusus Tenaga Penjualan

Seperti sistem apa pun, Salesforce memiliki banyak bagian rumit yang harus kita waspadai untuk menghindari kejutan yang tidak menyenangkan selama migrasi data. Berikut adalah beberapa contoh:

• Beberapa perubahan pada Pengguna aktif secara otomatis menghasilkan pemberitahuan email ke email pengguna. Jadi, jika kita ingin bermain dengan data pengguna, kita perlu menonaktifkan pengguna terlebih dahulu dan mengaktifkannya setelah perubahan selesai. Di lingkungan pengujian, kami mengacak email pengguna sehingga notifikasi tidak diaktifkan sama sekali. Karena pengguna aktif menggunakan lisensi yang mahal, kami tidak dapat membuat semua pengguna aktif di semua lingkungan pengujian. Kita harus mengelola subset pengguna aktif, misalnya, untuk mengaktifkan hanya mereka yang berada di lingkungan pelatihan.
• Pengguna tidak aktif, untuk beberapa objek standar seperti Akun atau Kasus, hanya dapat ditetapkan setelah memberikan izin sistem "Perbarui Catatan dengan Pemilik Tidak Aktif", tetapi mereka dapat ditetapkan, misalnya, ke Kontak dan semua objek kustom.
• Saat Kontak dinonaktifkan, semua bidang penyisihan diaktifkan secara diam-diam.
• Saat memuat duplikat Anggota Tim Akun atau objek Berbagi Akun, rekaman yang ada akan ditimpa secara diam-diam. Namun, saat memuat Mitra Peluang duplikat, catatan hanya ditambahkan sehingga menghasilkan duplikat.
• Bidang sistem, seperti Created Date Dibuat , Created By ID , Last Modified Date , Last Modified By ID , dapat ditulis secara eksplisit hanya setelah memberikan izin sistem baru "Tetapkan Bidang Audit pada Pembuatan Catatan."
• Perubahan nilai histori bidang tidak dapat dimigrasikan sama sekali.
• Pemilik artikel pengetahuan tidak dapat ditentukan selama pemuatan tetapi dapat diperbarui nanti.
• Bagian yang sulit adalah penyimpanan konten (dokumen, lampiran) ke Salesforce. Ada beberapa cara untuk melakukannya (menggunakan Lampiran, File, lampiran Feed, Dokumen), dan setiap cara memiliki pro dan kontra, termasuk batas ukuran file yang berbeda.
• Bidang daftar pilihan memaksa pengguna untuk memilih salah satu nilai yang diizinkan, misalnya, jenis akun. Namun saat memuat data menggunakan Salesforce API (atau alat apa pun yang dibangun di atasnya, seperti Apex Data Loader atau konektor Informatica Salesforce), nilai apa pun akan diteruskan.

Daftarnya terus berlanjut, tetapi intinya adalah: Kenali sistemnya, dan pelajari apa yang dapat dilakukan dan apa yang tidak dapat dilakukan sebelum Anda membuat asumsi. Jangan menganggap perilaku standar, terutama untuk objek inti. Selalu riset dan uji.

9. Jangan Gunakan Salesforce sebagai Platform Migrasi Data

Sangat menggoda untuk menggunakan Salesforce sebagai platform untuk membangun solusi migrasi data, terutama untuk pengembang Salesforce. Ini adalah teknologi yang sama untuk solusi migrasi data seperti untuk kustomisasi aplikasi Salesforce, GUI yang sama, bahasa pemrograman Apex yang sama, infrastruktur yang sama. Salesforce memiliki objek yang dapat bertindak sebagai tabel, dan sejenis bahasa SQL, Salesforce Object Query Language (SOQL). Namun, tolong jangan menggunakannya; itu akan menjadi cacat arsitektur yang mendasar.

Salesforce adalah aplikasi SaaS yang luar biasa dengan banyak fitur bagus, seperti kolaborasi lanjutan dan kustomisasi yang kaya, tetapi pemrosesan data massal bukanlah salah satunya. Tiga alasan yang paling signifikan adalah:

• Kinerja – Pemrosesan data di Salesforce beberapa tingkat lebih lambat daripada di RDBMS.
• Kurangnya fitur analitis – Salesforce SOQL tidak mendukung kueri kompleks dan fungsi analitis yang harus didukung oleh bahasa Apex, dan akan semakin menurunkan kinerja.
• Arsitektur * – Menempatkan platform migrasi data di dalam lingkungan Salesforce tertentu sangat tidak nyaman. Biasanya, kami memiliki beberapa lingkungan untuk tujuan tertentu, sering kali dibuat ad hoc sehingga kami dapat meluangkan banyak waktu untuk sinkronisasi kode. Selain itu, Anda juga akan mengandalkan konektivitas dan ketersediaan lingkungan Salesforce tertentu.

Sebagai gantinya, buat solusi migrasi data dalam instans terpisah (bisa berupa cloud atau lokal) menggunakan platform RDBMS atau ETL. Hubungkan dengan sistem sumber dan targetkan lingkungan Salesforce yang Anda inginkan, pindahkan data yang Anda butuhkan ke dalam staging area dan proses di sana. Ini akan memungkinkan Anda untuk:

• Manfaatkan kekuatan dan kemampuan penuh bahasa SQL atau fitur ETL.
• Simpan semua kode dan data di satu tempat sehingga Anda dapat menjalankan analisis di semua sistem.
  • Misalnya, Anda dapat menggabungkan konfigurasi terbaru dari lingkungan Salesforce pengujian terbaru dengan data nyata dari lingkungan Salesforce produksi.
• Anda tidak begitu bergantung pada teknologi sumber dan sistem target dan Anda dapat menggunakan kembali solusi Anda untuk proyek berikutnya.

10. Mengawasi Metadata Tenaga Penjualan

Di awal proyek, kami biasanya mengambil daftar bidang Salesforce dan memulai latihan pemetaan. Selama proyek, sering terjadi bahwa bidang baru ditambahkan oleh tim pengembangan aplikasi ke Salesforce, atau beberapa properti bidang diubah. Kami dapat meminta tim aplikasi untuk memberi tahu tim migrasi data tentang setiap perubahan model data, tetapi tidak selalu berhasil. Agar aman, kita perlu memiliki semua perubahan model data di bawah pengawasan.

Cara umum untuk melakukannya adalah mengunduh, secara teratur, metadata yang relevan dengan migrasi dari Salesforce ke beberapa repositori metadata. Setelah kami memiliki ini, kami tidak hanya dapat mendeteksi perubahan dalam model data, tetapi kami juga dapat membandingkan model data dari dua lingkungan Salesforce.

Metadata apa yang harus diunduh:

• Daftar objek dengan label dan nama teknis serta atributnya seperti updatable dibuat atau creatable .
• Daftar bidang dengan atributnya (lebih baik mendapatkan semuanya).
• Daftar nilai daftar pilihan untuk bidang daftar pilihan. Kami akan membutuhkan mereka untuk memetakan atau memvalidasi data masukan untuk nilai yang benar.
• Daftar validasi, untuk memastikan validasi baru tidak menimbulkan masalah untuk data yang dimigrasikan.

Bagaimana cara mengunduh metadata dari Salesforce? Yah, tidak ada metode metadata standar, tetapi ada beberapa opsi:

• Hasilkan Enterprise WSDL – Dalam aplikasi web Salesforce, navigasikan ke menu Setup / API dan unduh Enterprise WSDL yang diketik dengan kuat, yang menjelaskan semua objek dan bidang di Salesforce (tetapi bukan nilai daftar pilihan atau validasi).
• Hubungi Salesforce describeSObjects layanan webSObjects, secara langsung atau dengan menggunakan Java atau pembungkus C# (lihat Salesforce API). Dengan cara ini, Anda mendapatkan apa yang Anda butuhkan, dan ini adalah cara yang disarankan untuk mengekspor metadata.
• Gunakan salah satu dari banyak alat alternatif yang tersedia di internet.

Bersiaplah untuk Migrasi Data Selanjutnya

Solusi cloud, seperti Salesforce, siap secara instan. Jika Anda puas dengan fungsionalitas bawaan, cukup masuk dan gunakan. Namun, Salesforce, seperti solusi CRM cloud lainnya, membawa masalah khusus ke topik migrasi data yang harus diperhatikan, khususnya, terkait batas kinerja dan sumber daya.

Memindahkan data lama ke dalam sistem baru selalu merupakan perjalanan, terkadang perjalanan ke sejarah yang tersembunyi dalam data dari tahun-tahun sebelumnya. Dalam artikel ini, berdasarkan selusin proyek migrasi, saya telah menyajikan sepuluh kiat tentang cara memigrasikan data lama dan berhasil menghindari sebagian besar jebakan.

Kuncinya adalah memahami apa yang diungkapkan data. Jadi, sebelum Anda memulai migrasi data, pastikan tim pengembangan Salesforce Anda sudah siap menghadapi potensi masalah yang mungkin ada pada data Anda.