Data Migration ERP: Quy trình chuyển dữ liệu, rehearsal và reconciliation

Data Migration ERP không phải là thao tác export từ hệ thống cũ rồi import vào hệ thống mới. Đây là workstream phải quyết định dữ liệu nào được chuyển, nguồn nào là authoritative, field nào map sang đâu, dữ liệu nào cần làm sạch, cách kiểm tra số liệu sau load và điều kiện nào cho phép cutover.

Một migration tốt không cố mang toàn bộ lịch sử sang ERP mới bằng mọi giá. Mục tiêu là đưa đúng dữ liệu cần thiết sang đúng cấu trúc, có owner nghiệp vụ xác nhận và có bằng chứng reconciliation trước go-live. Nếu bạn đang nhìn toàn bộ chương trình, xem quy trình triển khai ERP để đặt migration đúng vị trí trong stage-gate.

Sơ đồ Data Migration ERP: từ nguồn dữ liệu đến cutover gate

Điểm kiểm soát quan trọng: migration chỉ đi tiếp khi bước trước có evidence. “Load thành công” chưa đủ; dữ liệu phải được reconcile theo logic nghiệp vụ trước khi mở hệ thống cho giao dịch thật.

Data Migration ERP gồm những loại dữ liệu nào?

Nhóm dữ liệu	Ví dụ	Câu hỏi quyết định
Master data	Customer, vendor, item, BOM, chart of accounts	Ai là owner? Record nào active? Duplicate xử lý thế nào?
Open transaction	Đơn hàng mở, PO mở, invoice chưa thanh toán	Chuyển nguyên trạng hay tạo opening position?
Balance	Tồn kho, AR/AP, GL opening balance	Reconcile theo nguồn nào và ngưỡng nào?
Historical transaction	Đơn hàng, invoice, movement cũ	Cần trong ERP mới hay lưu ở archive/reporting?
Reference/config data	UoM, tax code, payment term, warehouse	Giữ mã cũ hay chuẩn hóa theo target model?

Bước 1: Lập data inventory và xác định source of truth

Trước mapping, hãy liệt kê tất cả nguồn có thể chứa dữ liệu: ERP cũ, CRM, phần mềm kế toán, WMS, file Excel, database riêng và hệ thống của chi nhánh. Với mỗi domain, cần chọn một nguồn authoritative thay vì lấy “bản mới nhất” theo cảm tính.

• Domain dữ liệu: customer, vendor, item, BOM, GL, inventory…
• Source system và owner nghiệp vụ.
• Primary key hoặc business key.
• Volume record và mức tăng trưởng.
• Data quality issue đã biết.
• Retention/compliance requirement.
• Quyết định: migrate, transform, archive hay retire.

Danh sách này cũng là cầu nối sang Master Data ERP: migration xử lý chuyển đổi trong dự án, còn master data governance quyết định cách dữ liệu được tạo, sửa và duy trì sau go-live.

Bước 2: Data profiling trước khi cleansing

Data profiling nhằm đo tình trạng thực tế thay vì chỉ dựa vào nhận xét của người dùng. Với từng bảng hoặc domain, nên kiểm tra duplicate, null ở field bắt buộc, format không nhất quán, orphan record, giá trị ngoài domain, mã đã ngừng dùng và record không có owner.

Rule	Ví dụ lỗi	Owner quyết định
Uniqueness	Một vendor có nhiều mã	Procurement/Finance
Completeness	Customer thiếu tax code	Sales/Finance
Validity	UoM không nằm trong danh mục chuẩn	Operations
Referential integrity	Invoice trỏ tới customer không tồn tại	Data owner + IT
Lifecycle	SKU không phát sinh giao dịch nhiều năm	Product/Inventory owner

Bước 3: Thiết kế source-to-target mapping

Mapping không chỉ là “cột A sang cột B”. Một field trong hệ thống cũ có thể phải tách thành nhiều field mới, nhiều nguồn có thể hợp nhất vào một target field hoặc một mã cũ phải đổi sang taxonomy mới.

Source field	Target field	Transformation	Validation	Owner
Customer_Code	customer_external_id	Giữ nguyên và kiểm tra unique	Không null, không duplicate	Sales Ops
Full_Name	name	Trim/normalize	Không rỗng	Sales
Old_Tax	tax_code	Map theo bảng crosswalk	Chỉ nhận code hợp lệ	Finance

Mọi transformation có tác động nghiệp vụ cần người sở hữu dữ liệu phê duyệt. IT có thể xây rule nhưng không nên tự quyết định hai customer có phải cùng một pháp nhân hay một account cũ phải map sang account mới nào.

Bước 4: Cleansing và deduplication có log quyết định

Làm sạch nên thực hiện theo rule có thể lặp lại, không chỉnh thủ công từng file mà không có audit trail. Các nhóm xử lý thường gồm normalize text, chuẩn hóa mã, merge duplicate, retire record cũ, bổ sung field bắt buộc và xử lý orphan.

• Không merge duplicate chỉ vì tên gần giống; cần business key và owner xác nhận.
• Không tự động “sửa” mã kế toán hoặc tax mapping nếu chưa có rule nghiệp vụ.
• Không migrate inactive master chỉ để “cho đủ lịch sử” nếu không có use case.
• Giữ log record trước/sau và lý do transform cho các rule quan trọng.

Bước 5: Xây migration pipeline và kiểm soát lỗi

Pipeline thường gồm extract → staging → transform → validate → load → reconcile. Với dữ liệu lớn hoặc nhiều nguồn, staging giúp tách logic nguồn khỏi cấu trúc target và tạo điểm kiểm tra trước khi load vào ERP.

Mỗi batch nên có run ID, timestamp, số record đầu vào, số record thành công, số record bị reject và nguyên nhân reject. Nếu rerun, pipeline phải tránh tạo duplicate hoặc ghi đè ngoài dự kiến.

Bước 6: Rehearsal nhiều vòng thay vì một lần import cuối

Migration rehearsal là chạy quy trình gần giống cutover thật trong môi trường kiểm thử. Mục tiêu không phải đạt một số vòng cố định mà chứng minh dữ liệu, thời lượng và reconciliation đã đủ ổn định.

• Rehearsal sớm: bắt lỗi mapping, format, duplicate và volume.
• Rehearsal giữa: kiểm tra dependency giữa master, transaction và integration.
• Rehearsal gần go-live: chạy theo cutover runbook, owner thật và cửa sổ thời gian gần thực tế.

Bước 7: Reconciliation — load thành công chưa có nghĩa dữ liệu đúng

API hoặc import job báo thành công chỉ chứng minh hệ thống nhận dữ liệu. Reconciliation phải chứng minh dữ liệu sau load khớp logic kinh doanh.

Đối tượng	Kiểm tra
Master	Số record active, duplicate, key mapping, field bắt buộc
Inventory	Quantity/value theo warehouse, item, lot nếu có
AR/AP	Open item, aging, currency, total balance
GL	Opening balance theo account/dimension
Open order	Quantity còn lại, status, customer/vendor, giá trị

Ngưỡng chấp nhận phải được định nghĩa theo domain. Với các số dư tài chính trọng yếu, business owner cần sign-off theo rule của doanh nghiệp thay vì dùng một tỷ lệ “chuẩn” chung.

Bước 8: Cutover data plan

Cutover plan phải chỉ rõ thời điểm freeze, extract cuối, transformation, load, reconciliation, smoke test, quyền mở hệ thống và điều kiện no-go/rollback. Các dependency với integration cũng phải có thứ tự bật/tắt rõ ràng.

• Ai quyết định freeze nguồn cũ?
• Dữ liệu phát sinh trong cửa sổ cutover được xử lý thế nào?
• Batch nào phải chạy theo thứ tự?
• Ai sign-off inventory, AR/AP và GL?
• Nếu quá cutover window thì trigger no-go ở điểm nào?
• Hệ thống cũ chuyển read-only hay tiếp tục nhận giao dịch nếu rollback?

Có nên migrate toàn bộ dữ liệu lịch sử?

Không mặc định. Hãy phân loại lịch sử thành dữ liệu cần cho giao dịch đang mở, dữ liệu cần cho báo cáo/compliance và dữ liệu chỉ cần tra cứu. Một phần lịch sử có thể phù hợp hơn với archive hoặc data warehouse miễn là người dùng vẫn truy cập được theo yêu cầu và chính sách lưu trữ.

Quyết định này ảnh hưởng trực tiếp TCO, thời gian migration và test. Có thể đối chiếu với chi phí triển khai ERP để đưa migration scope vào cùng mô hình ngân sách.

Checklist exit gate cho Data Migration ERP

• Data inventory và source of truth đã được duyệt.
• Mapping có owner và version control.
• Cleansing rule có audit trail.
• Migration pipeline có reject/error handling.
• Rehearsal gần go-live nằm trong cutover window.
• Master và opening position đã reconcile.
• Known data issue có owner và quyết định rõ.
• Cutover/no-go/rollback criteria đã thống nhất.
• Business owner đã sign-off dữ liệu trọng yếu.

Kết luận

Data Migration ERP là bài toán ownership và validation trước khi là bài toán ETL. Hãy quản trị nó như một workstream có inventory, mapping, cleansing, rehearsal, reconciliation và cutover gate riêng. Nếu đang chọn vendor, đưa migration scope vào RFP ERP; nếu hệ thống còn phải kết nối nhiều ứng dụng, xem tiếp tích hợp ERP.

Khi migration gắn với Odoo upgrade hoặc chuyển hệ thống

Nếu migration là một phần của chuyển phiên bản, chuyển deployment hoặc đưa dữ liệu từ hệ thống cũ vào Odoo, data workstream cần được ghép với custom/addon compatibility, integration regression và cutover của target version. Owner thương mại cho tình huống này là dịch vụ nâng cấp và migration Odoo; bài hiện tại tiếp tục giữ intent Data Migration ERP vendor-neutral.