Trước khi tìm hiểu về migration, hãy cùng xem doanh nghiệp người dùng thường hình dung thế nào về một hệ thống lõi lý tưởng. Có lẽ họ kỳ vọng hệ thống lõi lý tưởng có thể kiểm soát chi phí, chuyển đổi ổn định từ hệ thống hiện tại và đồng thời đáp ứng các yêu cầu mới. Nói cách khác, doanh nghiệp muốn giữ lại những điểm mạnh của hệ thống hiện tại, chuyển đổi ổn định, đáp ứng yêu cầu mới và triển khai với chi phí thấp.

4 điểm doanh nghiệp người dùng thường yêu cầu trong migration

• Muốn tận dụng tài sản của hệ thống hiện tại.
• Di chuyển hệ thống ổn định
• Muốn giảm chi phí chuyển đổi.
• Muốn bổ sung yêu cầu mới và tăng lợi ích khi triển khai

Migration dựa trên hệ thống hiện tại nên có nhiều ràng buộc. Vì vậy, không phải lúc nào cũng có thể đáp ứng nhiều yêu cầu nghiệp vụ mới. Tuy nhiên, thực tế là doanh nghiệp vẫn muốn tối đa hóa lợi ích trong phạm vi có thể. Để cân bằng hai yếu tố này, migration có nhiều phương pháp khác nhau.

Vậy migration có những phương pháp nào? Trước hết, hãy tìm hiểu sự khác nhau giữa rehost, rewrite và rebuild. Đọc xong, bạn sẽ nắm được toàn cảnh ngay.

Trong các phương pháp migration, những thuật ngữ thường được nhắc đến là rehost, rewrite, rebuild và replatform. Hãy cùng tìm hiểu đặc điểm và sự khác nhau của từng phương pháp.

Rehost

Rehost là phương pháp thay thế nền tảng IT, gồm phần cứng và môi trường hạ tầng, mà không chỉnh sửa ứng dụng hoặc chương trình.

Phương pháp này áp dụng cho trường hợp thay mới phần cứng như máy chủ hoặc storage nhằm xử lý thiết bị hết hạn bảo trì hoặc nâng cao cấu hình. Ngoài ra, hình thức Lift & Shift, tức chuyển nguyên trạng từ môi trường on-premises lên môi trường cloud, cũng thuộc rehost.

Ít trường hợp migration hoàn tất chỉ bằng rehost. Đặc điểm phổ biến là phương pháp này thường được thực hiện như giai đoạn đầu của các dự án migration quy mô lớn.

Ngoài ra còn có thuật ngữ tương tự là “replace”, nhưng đây là cách diễn đạt rộng hơn. Nó có thể chỉ rehost, hoặc cũng có thể chỉ việc thay ứng dụng hiện tại bằng ứng dụng mới.

Replatform

Replatform là phương pháp tối ưu hóa nền tảng vận hành như OS, middleware và cơ sở dữ liệu cho môi trường mới, mà không thay đổi lớn cấu trúc ứng dụng hoặc logic nghiệp vụ.

Ví dụ, khi chuyển hệ thống đang chạy trong môi trường on-premises lên cloud, việc thay middleware hoặc DB bằng các thành phần hỗ trợ cloud, hoặc tối ưu hóa cấu hình, là trường hợp thuộc phương án này.

So với rehost, phương pháp này cần một số chỉnh sửa, nhưng đổi lại có thể kỳ vọng cải thiện hiệu năng, khả năng vận hành và tối ưu hóa chi phí. Mặt khác, do về cơ bản không thay đổi yêu cầu nghiệp vụ, mức độ linh hoạt không cao như rebuild.

Rewrite

Rewrite là phương pháp viết lại chương trình để phù hợp với môi trường hoặc công nghệ mới, trong khi vẫn giữ nguyên chức năng ứng dụng và đặc tả nghiệp vụ.

Ví dụ, việc viết lại chương trình hiện tại được viết bằng VB sang ngôn ngữ mới như Java hoặc C# được xem là Rewrite.

So với “Rebuild” được trình bày ở phần sau, phương án này có thể thực hiện trong thời gian ngắn và với chi phí thấp hơn, nhưng khó thay đổi lớn các yêu cầu nghiệp vụ và mức độ linh hoạt thấp hơn.

Thuật ngữ “conversion” cũng thường được sử dụng, nhưng có nghĩa khá rộng. Nó có thể chỉ chính hoạt động rewrite, hoặc cũng có thể chỉ toàn bộ việc chuyển đổi chương trình, dữ liệu và định dạng tệp.

Rebuild

Rebuild là phương pháp loại bỏ hệ thống hiện tại và xây dựng lại hệ thống mới. Về cơ bản, phương pháp này tương đương phát triển từ đầu, nhưng cũng có trường hợp kế thừa đặc tả nghiệp vụ từ tài sản của hệ thống hiện tại hoặc chỉ chuyển đổi dữ liệu.

Vì bắt đầu lại từ bước định nghĩa yêu cầu, phương pháp này giúp dễ dàng rà soát và cải thiện yêu cầu nghiệp vụ, đồng thời có thể xem là cách tiếp cận có mức độ linh hoạt và tiềm năng phát triển cao nhất.

Mặt khác, cần lưu ý rằng phương án này đòi hỏi thời gian dự án và chi phí tương xứng. Ngoài ra, trường hợp triển khai mới hệ thống ERP đóng gói cũng có thể được xem là Rebuild theo nghĩa rộng.

Kết luận

Rehost, replatform, rewrite và rebuild có thể được phân loại theo góc nhìn “thay đổi đến mức nào”.

• Rehost: Chỉ thay đổi môi trường, rủi ro thấp nhất
• Replatform: tối ưu hóa nền tảng để chuyển đổi
• Rewrite: Đổi mới công nghệ trong khi vẫn duy trì nghiệp vụ
• Rebuild: đổi mới toàn diện nghiệp vụ và hệ thống

Hiểu rõ những khác biệt này sẽ giúp doanh nghiệp dễ xem xét chiến lược migration phù hợp hơn.

Tiếp theo, hãy đi sâu hơn vào các điểm cần cân nhắc khi triển khai migration.

Hãy nhớ lại “4 điểm mà doanh nghiệp người dùng mong muốn khi migration” đã nêu ở trên. Dù là Rehost, Rewrite hay Rebuild, không có phương pháp nào đáp ứng được tất cả yêu cầu. Do đó, cần cân nhắc kỹ việc chọn phương pháp nào, hoặc kết hợp các phương pháp ra sao, dựa trên sự đánh đổi giữa các yêu cầu. Với migration hệ thống lõi, số lượng stakeholder liên quan đến dự án sẽ rất lớn, khiến độ khó khi khởi động dự án tăng mạnh.

Trong quá trình triển khai dự án cũng tiềm ẩn nhiều vấn đề. Phần này sẽ đề cập đến các vấn đề và rủi ro thường gặp.

• Thông số kỹ thuật và yêu cầu của hệ thống hiện tại chưa rõ ràng.

Một vấn đề thường gặp ở hệ thống legacy là “không có đầy đủ tài liệu thiết kế phát triển”. Đồng thời, các thành viên từng tham gia xây dựng hệ thống hiện tại không còn ở lại, việc tìm người am hiểu hệ thống cũng khó khăn, khiến chính hệ thống hiện tại trở thành “hộp đen”. Đây là một trong những yếu tố cản trở lớn việc tận dụng tài sản hiện có.

• Chi phí phình to

Khi dự án tiến triển, các sự việc như yêu cầu bổ sung hoặc phản ánh thay đổi từ hệ thống hiện tại có thể phát sinh. Ngoài ra, chi phí xử lý cũng có thể tăng do các yếu tố bên ngoài như nâng cấp OS hoặc thay đổi thông số kỹ thuật của hệ thống liên quan. Dự án càng kéo dài, khả năng xảy ra những vấn đề này càng cao.

• Quản lý nguồn lực khó

Khi dự án có quy mô lớn, việc kiểm soát nguồn nhân lực đặc biệt khó khăn. Ngoài việc thu xếp nhân sự, tình trạng phụ thuộc vào cá nhân, nhất là project manager và người am hiểu hệ thống, cũng như tập trung gánh nặng vào một số vị trí, thường dễ xảy ra.

Do ảnh hưởng của các yếu tố trên, nhiều dự án bị gián đoạn hoặc hủy bỏ. Qua đó, có thể thấy migration là một dự án khó.

Nói ngắn gọn là “chuyển hệ thống hiện tại sang hệ thống mới” nghe có vẻ đơn giản, nhưng thực tế đây là một hoạt động rất phức tạp. Bên cạnh việc chuẩn bị và lập kế hoạch kỹ lưỡng, điều quan trọng là phải làm rõ thông số kỹ thuật của hệ thống hiện tại và quy trình nghiệp vụ. Một cách thực hiện là dùng công cụ system mining để nắm bắt thông số kỹ thuật và luồng xử lý của hệ thống hiện tại. Ngoài ra, đặc biệt ở giai đoạn kiểm thử, nơi khối lượng công việc thường dễ tăng mạnh, cũng cần cân nhắc xây dựng cơ chế xử lý thay vì chỉ dựa vào nhân lực.