Mempermudah Kesulitan Migrasi Data

By July 2, 2014 Blog No Comments
twittergoogle_pluslinkedinmail

Untuk, banyak eksekutif lessor, dan CIO di khususnya, apa yang kita akan membahas menyamakan, mungkin, untuk mimpi terburuk mereka – migrasi data. Namun, dalam pengalaman penulis ketakutan tersebut dapat dihadapkan, diselesaikan dan migrasi sukses dicapai dengan penerapan beberapa berpikir ke depan dan perencanaan metodis.

Realitas di dunia intensif data hari ini adalah bahwa sebagian besar proyek implementasi software mengharuskan migrasi data yang dilakukan. Di sektor kami, apakah Anda penggelaran Sistem baru Kontrak Manajemen, atau dalam berbicara teknis sebuah (OLTP) sistem online Transaksional Pengolahan, atau jenis solusi data warehouse, lagi dalam berbicara teknis Online Analytical Processing (OLAP) sistem, Anda akan paling mungkin perlu melakukan migrasi data.

Untuk satu belum tahu bisa dimaafkan bila berpikir bahwa setiap dua sistem yang mempertahankan jenis yang sama dari data harus melakukan hal-hal yang sangat mirip dan, karena itu, harus peta dari satu ke yang lain dengan mudah – sayangnya ini hampir tidak pernah terjadi. sistem warisan secara historis terbukti jauh terlalu lunak terhadap menegakkan integritas pada tingkat atom data. Bidang yang harus diisi dari daftar nilai yang valid cenderung mengharuskan nilai dimasukkan, tapi jarang memvalidasi nilai aktual yang dimasukkan oleh pengguna.

Untuk alasan di atas, dan banyak lagi selain, terdapat kebutuhan yang jelas dan mutlak untuk pendekatan metodologis suara, dimana organisasi harus mendekati proyek migrasi data. Meskipun tidak ada cara untuk menghindari kejutan menyenangkan, salah satu pasti bisa siap untuk menghadapi dan mengatasinya.

Fase dari Migrasi Data

Rencana proyek migrasi data harus dipecah menjadi fase, yang mencerminkan proyek secara keseluruhan. Fase dapat didefinisikan sebagai Analisis, Data Pemetaan, Build, Transfer Rekonsiliasi, Revisi, Migrasi Rekonsiliasi dan Pemeliharaan.

1. ANALISIS

Tahap analisis biasanya dimulai dengan mendefinisikan proyek secara keseluruhan. Sebagaimana telah diamati proyek transfer data biasanya terjadi melalui pengenalan sistem baru, maka manajer proyek akan memiliki banyak prioritas yang bersaing, tidak sedikit yang akan menjadi persyaratan rinci bahwa sistem baru harus alamat. Di sinilah kesalahan kritis dapat terjadi. Dengan fokus diarahkan ke sistem baru tim proyek kurang memperhatikan, atau benar-benar menghadap persyaratan transfer data. Pada kenyataannya sebagian besar proyek transfer data baik dalam OLTP atau ruang OLAP memerlukan rencana proyek rinci terpisah, mereka yang hanya mencakup entri satu baris pada grafik Gantt “Migrasi Data” membohongi diri mereka sendiri.

Elemen kedua dalam tahap analisis adalah untuk menciptakan tim migrasi data. Tantangan ini biasanya menyajikan adalah bahwa orang yang sama diharapkan untuk melakukan peran dalam proyek implementasi sistem serta menjadi bagian dari tim migrasi. Hal ini menyebabkan perhatian segera atas prioritas. Karena tidak jelas ada jawaban benar atau salah untuk teka-teki ini manajer proyek perlu membuat prioritas yang tepat panggilan yang sesuai dengan kebutuhan bisnis.

Tambahan satu poin patut dicatat di sini adalah bahwa tim proyek harus didedikasikan untuk proyek. Proyek yang paling sukses adalah mereka yang memiliki sponsor eksekutif aktif dan 100% dedikasi dari tim proyek. Seharusnya tidak diharapkan bahwa anggota tim proyek terus melaksanakan mereka “pekerjaan hari” serta melakukan sebagai bagian dari tim proyek. komunikasi yang jelas dari kekritisan proyek, bersama dengan prioritas dan tanggung jawab anggota tim proyek, berarti bahwa kesenjangan dibenarkan dibuat pada hari-hari kebutuhan bisnis yang akan ditimbun oleh rekan-rekan lain yang mengerti mengapa mereka diminta untuk melangkah ke mengisi kekosongan.

Mendapatkan kembali pada topik migrasi data, sebagai seorang eksekutif dari bisnis pembiayaan aset sewa guna usaha Anda akan tahu bahwa bisnis Anda didukung oleh lebih dari satu sistem. Dalam sebagian besar proyek migrasi data kita menemukan diri kita dihadapkan dengan segudang sistem yang berbeda, atau aku harus mengatakan lebih akurat sumber data, di mana campuran data yang akan ditransfer berada. Hal ini tidak biasa bagi bisnis data penting untuk disimpan di sekitar organisasi di terpisah meja-top database, spreadsheet dan kadang-kadang dalam file teks datar. Akurasi, visibilitas, kontrol dan masalah keamanan segera dibawa pulang untuk bisnis, sehingga mau tidak mau sumber-sumber data tambahan perlu dimasukkan dalam migrasi data.
Bagian penting berikutnya dari tahap analisis melibatkan berkenalan dengan data aktual Anda berencana untuk bermigrasi. Ingat, pada saat ini proyek, Anda hanya memiliki minimal informasi yang Anda sedang mengembangkan rencana migrasi data. Untuk mendapatkan rasa yang lebih baik dari tugas penting untuk mendapatkan beberapa visibilitas untuk kualitas dan kuantitas data yang akan bermigrasi. Memperoleh ekstrak data memberikan panduan yang baik sebagai tingkat pembersihan data yang mungkin dan kuantitas data.

Sejauh ini kita telah tidak dianggap apa pilihan mungkin untuk benar-benar migrasi data. Dalam kasus migrasi data OLAP, dan terutama di mana ada kebutuhan untuk refresh data biasa, di misalnya menyegarkan konten dalam data warehouse, ada sedikit pilihan selain mengikuti strategi migrasi otomatis. Namun, dalam kasus migrasi OLTP, yang biasanya waktu satu- melaksanakan opsi dari pendekatan manual mungkin layak dipertimbangkan. Umumnya jumlah data akan menjadi indikator membimbing. Dalam industri kami transfer data lebih dari 1.000 perjanjian poin terhadap transfer otomatis, dengan mungkin sejumlah kecil anomali sedang ditangani secara manual. Kurang dari 1.000 itu biasanya penilaian biaya risiko dan sebagai hasilnya Anda mungkin menemukan bahwa biaya keseluruhan migrasi elektronik mahal relatif terhadap jumlah data yang perlu ditransfer.

Sepotong lebih lanjut dari saran yang patut dicatat adalah untuk mempertimbangkan pentahapan proyek migrasi. Besar migrasi data volume dapat mengambil beberapa bulan untuk menyelesaikan dan karena itu membawa biaya yang signifikan. Hal ini sering menyebabkan kecemasan dan risiko tekanan membangun, serta biaya yang sedang berlangsung untuk yang tampaknya tidak ada hasil yang terlihat. Saran untuk mengatasi ini akan mempertimbangkan membangun rencana migrasi data Anda berdasarkan pada jumlah transfer bijaksana kecil. Ini akan menunjukkan kemajuan, membenarkan biaya dan sangat de-risiko “all-in-one” pendekatan transfer. Anda juga dapat menemukan ini secara signifikan mengurangi kecemasan yang CIO Anda terasa!

2. DATA PEMETAAN

Setelah Anda telah memutuskan pada sumber data warisan, langkah berikutnya adalah untuk menentukan data yang perlu bermigrasi; maka elemen data yang dipetakan ke dalam bidang sistem baru. Ini melibatkan akan melalui daftar elemen data dari setiap sumber data, dan memutuskan apakah akan bermigrasi dan membandingkan dengan yang di sistem baru.
Selama latihan ini sampel ekstrak lebih lanjut dari data yang akan diperlukan untuk membantu menjelaskan anomali terminologi. Sebagai hasil dari latihan ini Anda akan dapat menentukan sejauh mana data yang hilang atau perlu dibersihkan.

Tahap pemetaan tidak dimaksudkan untuk benar-benar mengidentifikasi aturan transformasi dimana data historis akan bermigrasi ke sistem baru; bukan, itu pada dasarnya adalah tindakan membuat daftar dari elemen data yang harus bermigrasi.

3. BUILD

Tahap membangun adalah di mana pengalaman, pengetahuan dan keterampilan dari pasangan migrasi Anda, NETSOL dalam hal ini, benar-benar datang ke kedepan. Seorang mitra dengan pengalaman industri dari banyak dan beragam migrasi data, akan memberikan jaminan proyek dengan campuran bisnis dan keahlian teknis yang diperlukan untuk mencapai kegiatan ini.

Untuk memberikan awal yang cepat untuk proses ini NETSOL telah membangun alat transformasi migrasi data ke mana sumber data dan pemetaan yang tepat sementara berada. Ini pada dasarnya merupakan database pementasan, yang digunakan untuk memverifikasi pemetaan data dan mendukung pembersihan dan transformasi data yang akan dilakukan, semua tanpa dampak baik donor atau penerima database.

Sementara alat transformasi bukan satu-satunya metode yang tersedia, itu adalah yang paling efisien dan efektif. Alternatif cenderung spreadsheet, yang selalu gagal ketika Anda perlu untuk memetakan elemen data satu sumber untuk satu atau lebih elemen sasaran. Spreadsheet biasanya mencegah lebih dari satu orang dari membuat modifikasi pada satu waktu, sehingga banyak overhead administratif yang tidak perlu. Spreadsheet adalah alat dua dimensi, dan pemetaan adalah tanpa pertanyaan multi-dimensi.

Pementasan penyimpanan data pasca menjadi sangat penting ketika melakukan jenis migrasi data warehouse, di mana kebutuhan untuk mengubah dan merasionalisasi data ke tabel baru akan menjadi persyaratan untuk menyediakan akses cepat ke analitik online secara real time.

4. TRANSFER / REKONSILIASI

Dua fase berikutnya transfer / rekonsiliasi dan merevisi yang berulang.
Biasanya ini akan melibatkan sejumlah sub-set data dan ekstrak data penuh data akhir bulan klien ditarik melalui database pementasan dengan skrip untuk mengubah dan peta yang diperlukan untuk database penerima.
Fase ini akan menjawab semacam berikut pertanyaan;

  • Berapa banyak catatan yang kita harapkan script ini untuk membuat?
  • Apakah jumlah yang benar dari catatan bisa dibuat?
  • Apakah data dimuat ke dalam bidang yang benar?
  • Apakah data telah diformat dengan benar?
  • Apakah mendamaikan?

Selalu fase ini menyoroti untuk pengguna elemen data historis yang harus bermigrasi yang tidak jelas bagi mereka selama sesi analisis.
Yang benar adalah bahwa pemetaan data tidak mudah untuk mendapatkan hak pertama kalinya. Kebanyakan orang tidak menyadari bahwa elemen data yang hilang sampai mereka menyadari itu sudah tidak ada lagi. Untuk alasan ini tahap revisi harus mengikuti untuk memperbaiki anomali ini dan transfer fase / rekonsiliasi harus dijalankan melalui lagi.
Hal ini penting untuk mencapai titik ini dalam proyek migrasi sesegera mungkin, karena akan menyoroti masalah yang mungkin mengharuskan sistem penerima \ ‘model data tweak untuk mengakomodasi kebutuhan klien berasal tertentu.

Aspek rekonsiliasi dari tahap ini adalah penting untuk migrasi sukses. Bersama dengan mitra migrasi Anda Anda harus menentukan kriteria dan proses yang diperlukan untuk memverifikasi rekonsiliasi sukses. Ingat ini adalah bisnis Anda, data Anda dan akhirnya Anda bertanggung jawab untuk menandatangani -off hasil rekonsiliasi migrasi.

5. REVISI

Luasnya tahap revisi sepenuhnya tergantung pada hasil dari fase perpindahan / rekonsiliasi dijelaskan sebelumnya. Dalam teori itu harus mungkin untuk melewati fase ini sama sekali dengan transfer dan rekonsiliasi fase sepenuhnya berdamai dan berhasil scripted, tapi sayangnya ini tidak pernah terjadi, anomali yang selalu muncul.

Menariknya, pengalaman menunjukkan bahwa nilai ketidakseimbangan rekonsiliasi, atau mungkin fakta bahwa sejumlah besar perjanjian dengan ketidaksesuaian data yang ditemukan, tidak panduan yang baik untuk berapa banyak usaha ekstra migrasi akan membutuhkan untuk menyelesaikan. Sebuah portofolio besar dengan ketidakseimbangan rekonsiliasi besar kemungkinan akan dikoreksi, atau sebagian dari perbedaan yang ditemukan, dengan hanya satu atau dua penyesuaian, dan biasanya ini mudah untuk melacak, sedangkan ketidakseimbangan nilai rekonsiliasi lebih rendah, atau jumlah yang lebih kecil dari perjanjian dengan ketidakcocokan data yang lebih sulit untuk menemukan. Pesan di sini adalah don \ ‘t khawatir dengan hasil rekonsiliasi pertama. Dua atau tiga iterasi cukup norma.

Setelah fase perpindahan / rekonsiliasi dan merevisi telah diselesaikan secara memuaskan saatnya untuk menerapkan.

6. MIGRASI / REKONSILIASI

Sebagai langkah pertama dalam tahap migrasi / rekonsiliasi dianjurkan bahwa migrasi penuh \ “dry-run \” dilakukan. Jangka kering harus berlangsung pada set kode akhir dari sistem baru. Hal ini penting karena setiap perubahan lebih lanjut untuk struktur data yang mendasari dan / atau aturan dapat berdampak pada hasil transfer data. Data bermigrasi harus benar-benar pengguna diuji dan berdamai. Rekonsiliasi pada tahap ini sangat penting. Pasangan migrasi Anda akan melaksanakan rekonsiliasi rinci mengikuti kriteria Anda dan proses, tapi sekali lagi tanda-off sisa jawab akhir dengan Anda dan persetujuan dari auditor Anda.

Setelah berhasil didamaikan run kering migrasi penuh dapat berlangsung. Biasanya ini akan berlangsung pada data akhir bulan dan akan diatur untuk terjadi selama akhir pekan. Kegiatan ini cukup jelas akan melibatkan beberapa downtime dari sistem bisnis, sehingga sangat penting untuk memilih waktu yang meminimalkan gangguan bisnis dan juga memberikan waktu untuk menyelesaikan masalah apapun yang mungkin timbul.

7. MAINTENANCE

Tahap pemeliharaan hanya benar-benar berlaku dalam kasus melakukan migrasi sistem data warehouse (OLAP).

Dalam migrasi sistem sistem manajemen kontrak (OLTP), Anda bekerja di lingkungan migrasi satu kali. Tujuan untuk berhasil migrasi data warisan ke dalam sistem baru selesai maka kebutuhan untuk mempertahankan skrip migrasi dihapus.

Dalam migrasi data warehouse (OLAP), Anda kemungkinan besar akan reload sistem baru pada interval tepat waktu. Sebagai informasi baru dicatat dalam sistem manajemen kontrak Anda, Anda akan ingin mentransfernya ke gudang data (OLAP). Kinerja Script adalah masalah penting dalam migrasi data warehouse, data baru ditambahkan ke migrasi data script segar perlu ditinjau untuk memastikan kinerja puncak dipertahankan.

Kesimpulan

Untuk menyimpulkan, migrasi data, lebih sering daripada tidak, langkah yang diperlukan. Kunci kesuksesan adalah untuk mempersiapkan awal, memantau terus menerus dan memastikan bahwa antara tim proyek Anda dan pasangan migrasi Anda memiliki pendekatan yang saling mengerti dengan tanggung jawab yang ditetapkan, dan tim yang berdedikasi untuk melaksanakannya. Sayangnya tidak ada rumus ajaib selain persiapan, perencanaan, perhatian terhadap detail dan kerja keras, dan memastikan bahwa Anda memiliki pasangan yang sesuai berpengalaman dan terampil dalam latihan bisnis penting ini.

Oleh Tony Langford dan GrahamTarrant,
NETSOL Teknologi

twittergoogle_pluslinkedinmail

About admin

Top

Permintaan Demo

Mohon lengkapi rincian berikut ini dan kami akan hubungi untuk selanjutnya

Permintaan Demo untu:-  NFS Ascent NFS Mobility

Tipe Bisnis:-

Banyak kontrak/tahun:-

Tipe Leasing:-

Tipe Organisasi:-

Komentar:-

Unggah RFP/RFS:-

captcha