Merancang Migrasi Data Tanpa Kehilangan (atau Mempercayai) Perkara yang Salah

Skrip ialah bahagian yang mudah

Projek migrasi data jarang menang atau kalah pada skrip migrasi itu sendiri. Menulis kod yang memindahkan satu rekod daripada satu bentuk kepada bentuk lain, sebaik sahaja setiap keputusan sebelum itu telah benar-benar dibuat, adalah kerja mekanikal yang difahami dengan baik. Apa yang menentukan sama ada migrasi berjalan lancar ialah set keputusan yang dibuat sebelum satu-satu rekod pun bergerak: apa yang sebenarnya ada dalam sistem lama, apa yang tidak patut dibawa masuk langsung, bagaimana makna satu medan dalam satu sistem dipetakan kepada medan berbentuk berbeza dalam sistem baharu, dan bagaimana untuk membuktikan selepas itu bahawa tiada apa yang hilang atau senyap-senyap rosak sepanjang proses.

Inventori dan profiling dahulu

Sebelum apa-apa dipetakan, ia perlu diukur dahulu. Ini bermakna menyemak sistem sumber jadual demi jadual, atau helaian demi helaian, dan menentukan apa yang sebenarnya ada di sana: berapa banyak rekod, berapa banyak daripadanya yang benar-benar aktif berbanding tidak aktif atau telah digantikan, medan mana yang konsisten diisi dan mana yang kebanyakannya kosong, dan di mana pendua (duplicate) sudah wujud di bawah ejaan atau format yang sedikit berbeza. Ini kedengaran seperti formaliti tetapi jarang sekali begitu — sudah biasa untuk sesebuah perniagaan mendapati semasa profiling bahawa jadual "pelanggan" yang semua orang anggap menyimpan beberapa ribu rekod aktif sebenarnya kebanyakannya kemasukan sekali sahaja bertahun-tahun lamanya yang tiada siapa sentuh sejak dicipta, dengan set yang benar-benar aktif hanya sebahagian kecil daripada jumlah keseluruhan. Pelan migrasi yang dibina atas saiz dan bentuk data yang diandaikan, bukan yang diukur sebenar, cenderung tersilap dalam cara yang hanya muncul apabila migrasi sebenar sudah pun berjalan.

Memutuskan apa yang TIDAK perlu dimigrasi

Bukan semua benda dalam sistem lama layak mendapat tempat dalam sistem baharu. Rekod ujian, kemasukan pendua, dan medan yang sudah lama tidak digunakan oleh perniagaan tidak menjadi lebih berguna hanya kerana dibawa masuk ke sistem baharu yang bersih — ia cuma memindahkan kekeliruan itu ke tempat lain. Pertimbangan yang lebih sukar berlegar di sekeliling data sejarah: sedekad pesanan yang sudah ditutup mungkin benar-benar tidak relevan kepada cara sistem baharu akan digunakan setiap hari, lebih baik disimpan sebagai eksport arkib berbanding diimport sebagai rekod hidup yang kini perlu diambil kira oleh sistem baharu dalam setiap laporan dan setiap pertanyaan (query). Walaupun begitu, sesetengah rekod mungkin tertakluk kepada obligasi penyimpanan berkanun (statutory retention) — cukai, pekerjaan, atau berkaitan audit — yang tidak memerlukan data itu berada di dalam sistem operasi baharu, tetapi memerlukan ia kekal boleh diakses di suatu tempat untuk tempoh tertentu. Rekod mana yang terkena obligasi itu, dan untuk berapa lama, patut disahkan bersama akauntan atau setiausaha syarikat perniagaan itu sendiri sebelum apa-apa dipadam atau dikecualikan, dan bukan diandaikan sama ada begitu atau tidak daripada penerangan umum seperti artikel ini.

Pemetaan medan (field mapping) dan pertimbangannya

Pemetaan medan kelihatan seperti latihan teknikal dan sangat kerap sebenarnya keputusan perniagaan yang berpakaian teknikal. Dua sistem jarang mentakrifkan konsep yang sama dengan cara yang sama. Sistem lama mungkin membawa lima belas status pesanan lama yang terkumpul sepanjang bertahun-tahun penambahan ad hoc; sistem baharu mungkin hanya mentakrifkan empat. Memutuskan bahawa "Dibatalkan – Dibayar Balik" dipetakan kepada "Dibatalkan" dan bukan kepada statusnya sendiri ialah keputusan tentang apa yang perniagaan anggap berbeza secara bermakna, bukan keputusan tentang skema pangkalan data — dan ia patut dibuat dan diluluskan oleh seseorang yang faham makna sebenar data itu dari segi operasi, bukan diserahkan kepada sesiapa yang kebetulan sedang menulis skrip migrasi di bawah tekanan tarikh akhir. Perkara yang sama terpakai kepada medan teks bebas yang dipaksa masuk ke dalam medan berstruktur, format nama yang tidak konsisten, dan nombor telefon yang disimpan dalam pelbagai format berbeza sepanjang bertahun-tahun kemasukan manual. Tiada satu pun daripada ini mempunyai jawapan yang "betul" secara teknikal; ia mempunyai jawapan yang sesuai dari segi perniagaan, dan ia perlu ditulis serta dipersetujui sebelum pemetaan dibina, bukan ditemui sebagai pengecualian di tengah-tengah proses.

Dry run terhadap data berbentuk production

Menguji migrasi terhadap sampel kecil yang bersih membuktikan skrip itu berjalan. Ia hampir tidak membuktikan apa-apa tentang sama ada ia akan bertahan terhadap data sebenar, kerana masalah yang merosakkan migrasi — isu encoding, kunci pendua (duplicate key) yang tidak dijangka, aksara multibait (multibyte) dalam nama Melayu, Cina, atau Tamil yang dikendalikan secara tidak konsisten oleh sistem yang menciptanya, medan yang null dalam cara yang tiada siapa dokumenkan — cenderung cukup jarang sehingga sampel yang dipilih tangan terus melangkauinya. Dry run yang betul bermaksud menjalankan skrip migrasi sebenar terhadap salinan penuh data production, dalam persekitaran yang bukan production, dan memerhatikan apa yang benar-benar rosak pada skala sebenar dan dalam bentuk sebenar data itu, bukan versi yang kemas. Ia juga memberikan jawapan jujur kepada satu soalan praktikal berasingan: berapa lama migrasi sebenarnya mengambil masa untuk berjalan, yang menentukan berapa panjang tetingkap cutover perlu sebenarnya.

Rekonsiliasi: mengira, bukan menganggap

Mengesahkan bahawa migrasi memindahkan, katakan, 1,240 rekod pelanggan daripada sistem lama kepada 1,240 dalam sistem baharu ialah satu semakan yang perlu tetapi lemah dengan sendirinya — dua jumlah yang sepadan boleh menyembunyikan rekod yang berpindah ke kategori yang salah, atau pendua yang saling meniadakan dalam kiraan secara kebetulan. Rekonsiliasi yang lebih jujur menyemak mengikut kategori berbanding satu jumlah besar sahaja: pelanggan aktif berbanding pelanggan aktif, arkib berbanding arkib; jumlah nilai setiap invois sebelum migrasi berbanding jumlah yang sama selepas migrasi; dan sampel yang disemak secara manual dibandingkan medan demi medan dengan sumber asal, bukan sekadar disahkan wujud. Rekonsiliasi yang hanya menyemak sama ada rekod itu sampai di suatu tempat, tanpa menyemak sama ada ia sampai dengan betul, cenderung menemui masalah beberapa bulan kemudian dan bukan pada hari migrasi, ketika ia jauh lebih mahal untuk dibaiki.

Pelan rollback

Pelan rollback perlu menjawab satu soalan khusus secara jujur: jika sesuatu tersilap selepas cutover, bolehkah perniagaan itu benar-benar kembali kepada sistem lama, dan untuk berapa lama itu kekal benar? Jawapannya biasanya bukan "ya, tanpa had." Sebaik sahaja transaksi baharu mula berlaku hanya dalam sistem baharu, rollback yang bersih berhenti menjadi mungkin sebaik sahaja transaksi itu wujud di mana-mana pun dalam sistem lama — kembali semula bermakna kehilangan transaksi itu. Titik tiada-jalan-pulang itu perlu ditentukan dan dimaklumkan sebelum cutover, bukan ditemui selepas itu apabila seseorang minta untuk rollback dan baru tahu ia bukan lagi satu pilihan. Pelan rollback yang tidak menamakan detik itu secara jelas bukan benar-benar satu pelan; ia satu andaian bahawa akan sentiasa ada masa untuk berubah fikiran.

Apa yang selalu didedahkan oleh migrasi

Elok dijujurkan tentang ini berbanding melayannya sebagai nota kaki: migrasi sangat kerap mendedahkan masalah kualiti data yang perniagaan sendiri tidak sedar ia ada. Rekod pelanggan pendua di bawah nama yang sedikit berbeza, pesanan tanpa pelanggan yang dipautkan, invois yang jumlah tersimpannya tidak sepadan dengan jumlah item barisnya sendiri — ini bukan bukti sesiapa buat sesuatu yang salah. Ia jenis perkara yang terkumpul senyap-senyap sepanjang bertahun-tahun kemasukan manual sepanjang hayat sesuatu sistem dan jarang dipaksa kelihatan sehinggalah setiap rekod perlu melalui satu set peraturan konsisten sekali gus, dan bukan disemak satu demi satu mengikut keperluan. Keputusan berguna untuk dibuat lebih awal ialah sama ada projek itu akan membersihkan semua ini sebelum cutover, yang menambah masa di peringkat awal, atau memigrasikan data seadanya dengan pembersihan berjadual selepas itu — kedua-duanya pilihan yang sah. Menemui pilihan ini wujud di tengah-tengah migrasi, berbanding memutuskannya terlebih dahulu, biasanya apa yang menukar garis masa yang dirancang kepada satu yang terbuka tanpa penghujung.

Sebelum komited kepada tarikh cutover

Migrasi yang telah diinventorikan, dipetakan dengan pertimbangan yang didokumenkan, dry-run terhadap data sebenar, dan direkonsiliasi mengikut kategori berbanding satu jumlah sahaja, ialah satu usaha yang secara asasnya berbeza daripada satu di mana skrip ditulis dan semua orang berharap yang terbaik pada malam itu. Fixed-Scope Project JagaWeb (bermula daripada RM30,000, tidak termasuk SST) merangkumi kerja migrasi seperti ini sepenuhnya dari hujung ke hujung; di mana data sumber itu sendiri memerlukan profiling dan penerangan jujur tentang keadaannya sebelum skop atau harga boleh ditetapkan langsung, Essential System Review (RM1,500, dikurangkan kepada RM999 sehingga 16 September 2026, tidak termasuk SST) dibina untuk pandangan pertama itu.