Hiện Đại Hóa Phần Mềm Cũ: Sửa Dần, Thay Dần Hay Làm Lại?

Phần mềm quản lý do một đơn vị bên ngoài viết từ nhiều năm trước vẫn chạy mỗi ngày, nhưng đơn vị đó không còn hỗ trợ, người hiểu hệ thống đã nghỉ, và thêm một tính năng nhỏ cũng mất nhiều tuần. Doanh nghiệp không thể dừng vận hành để làm lại, cũng không thể tiếp tục phụ thuộc vào một hệ thống ngày càng khó sửa. Bài viết này giúp giám đốc, trưởng IT và chủ doanh nghiệp chọn đúng hướng hiện đại hóa hệ thống cũ, tiếp quản từ đơn vị cũ và di chuyển dữ liệu với ít rủi ro.

Tóm tắt nhanh

Hiện đại hóa phần mềm cũ không đồng nghĩa với làm lại từ đầu. Hệ thống ổn định, ít thay đổi thì nên giữ; mã nguồn còn đọc được thì sửa dần; hệ thống lớn, không được dừng thì thay từng phần qua lớp định tuyến; nghiệp vụ phổ biến thì chuyển sang gói có sẵn; chỉ làm lại khi các hướng trên không khả thi. Dù chọn hướng nào, doanh nghiệp cũng cần tiếp quản mã nguồn, tài liệu, quyền máy chủ trước, rồi chuẩn bị đối soát dữ liệu và phương án quay lại.

1. Legacy system là gì?

Legacy system là hệ thống phần mềm cũ mà doanh nghiệp vẫn phụ thuộc trong vận hành hằng ngày, nhưng ngày càng khó sửa, khó kết nối và khó tìm người hiểu. Phần mềm trở thành legacy vì rủi ro khi duy trì tăng dần, không đơn thuần vì đã được dùng nhiều năm.

Tại doanh nghiệp Việt Nam, hệ thống cũ có thể là phần mềm bán hàng, kho hoặc sản xuất viết bằng Visual Basic, FoxPro hay Access, ứng dụng web chạy trên phiên bản đã hết hạn hỗ trợ, hoặc ERP bị sửa nhiều đến mức không thể cập nhật lên bản mới. Ngược lại, phần mềm đã dùng hơn mười năm nhưng ổn định, có tài liệu và có người hiểu rõ thì chưa phải là vấn đề.

Hiện đại hóa hệ thống cũ là đưa phần mềm về trạng thái doanh nghiệp kiểm soát được: sửa được khi cần, kết nối được với hệ thống khác và không phụ thuộc vào vài cá nhân. Có trường hợp chỉ cần nhận bàn giao đầy đủ, có trường hợp phải thay toàn bộ. Thước đo nên là lợi ích kinh doanh, không phải độ mới của công nghệ.

2. Dấu hiệu nào cho thấy đã đến lúc hiện đại hóa phần mềm cũ?

Đã đến lúc hiện đại hóa khi phần mềm cũ cản trở kinh doanh hoặc tạo rủi ro vận hành: đơn vị làm ban đầu không còn hỗ trợ, người hiểu hệ thống đã nghỉ, thêm tính năng ngày càng lâu, không kết nối được hệ thống mới, hoặc nền tảng không còn bản vá bảo mật.

Ba dòng đầu là rủi ro đến đột ngột: hệ thống vẫn chạy bình thường cho tới ngày có sự cố. Các dòng còn lại là chi phí ngầm tăng dần, đo được bằng công sức nhập tay và những yêu cầu kinh doanh phải chờ. Một dấu hiệu riêng lẻ chưa đủ để kết luận phải thay hệ thống, nhưng gặp một dấu hiệu thuộc nhóm đầu thì doanh nghiệp đã nên làm ngay việc tiếp quản ở mục 5.

3. Nên giữ, sửa dần, thay từng phần, làm lại hay chuyển sang gói có sẵn?

Hướng đi phụ thuộc vào ba câu hỏi: chức năng đó còn tạo khác biệt cho doanh nghiệp không, mã nguồn còn kiểm soát được không, và hệ thống có được phép dừng không. Doanh nghiệp không nhất thiết chọn một hướng cho toàn hệ thống; mỗi nhóm chức năng có thể đi theo một hướng riêng.

Kết quả thường là một phương án kết hợp, chẳng hạn chuyển kế toán sang gói có sẵn, sửa dần phần tính giá đặc thù và làm mới phần giao tiếp với khách hàng. Khi đó việc nối các phần với nhau trở thành một hạng mục riêng: bài cách kết nối kế toán, bán hàng, kho và CRM trình bày cả tình huống phần mềm cũ không có API, còn khái niệm, phân loại và cách tiếp cận tích hợp hệ thống giúp trưởng IT chọn kiểu kết nối.

Khi nào không nên hiện đại hóa?

Không nên hiện đại hóa khi phần mềm chỉ phục vụ việc phụ, mảng kinh doanh liên quan sắp thu hẹp, rủi ro khi giữ nguyên thấp hơn rủi ro khi thay đổi, hoặc doanh nghiệp chưa có mục tiêu kinh doanh cụ thể. Khi đó, việc đúng hơn là bảo vệ dữ liệu và ghi lại tài liệu.

• Lý do chỉ là công nghệ đã cũ: không nói được vấn đề kinh doanh cần giải quyết thì dự án khó có tiêu chí nghiệm thu.
• Phần mềm phụ trợ, ít người dùng: dừng vài ngày mà công việc vẫn xoay xở được thì chưa cần đầu tư lớn.
• Sắp có thay đổi lớn: doanh nghiệp đang sáp nhập, đổi mô hình kinh doanh hoặc sắp triển khai ERP thì nên chờ quyết định đó trước.
• Chưa có người theo dự án: thiếu đầu mối nghiệp vụ đủ quyền quyết định, mọi hướng đi đều dễ đình trệ.

Mức tối thiểu vẫn là sao lưu, thử khôi phục và giữ mã nguồn cùng tài khoản quản trị trong tay doanh nghiệp. Savvycom là đơn vị làm phần mềm theo yêu cầu, nhưng khi hệ thống còn chạy tốt hoặc gói có sẵn đã đáp ứng được bài toán thì doanh nghiệp chưa cần làm riêng.

6R, 7R khác gì với các hướng đi trên?

6R hay 7R là cách phân loại hướng xử lý ứng dụng cũ khi chuyển lên cloud. Khung 7R của AWS gồm retire, retain, rehost, relocate, replatform, repurchase và refactor. Nói gần đúng, retain tương ứng giữ nguyên, refactor tương ứng sửa dần hoặc làm lại, repurchase tương ứng chuyển sang gói có sẵn, retire là bỏ hẳn.

Chuyển phần mềm lên cloud mà không sửa gì chỉ đổi nơi chạy, còn mã nguồn khó sửa vẫn nguyên như cũ. Loại bỏ là một lựa chọn hợp lệ, vì kiểm kê có thể cho thấy những chức năng không còn ai dùng.

4. Thay từng phần hoạt động thế nào để không phải dừng hệ thống?

Thay từng phần là đặt một lớp định tuyến trước hệ thống cũ, rồi chuyển dần từng chức năng sang hệ thống mới. Cũ và mới chạy song song nên người dùng thường ít bị gián đoạn. Khi chức năng mới gặp lỗi, lớp định tuyến đưa yêu cầu trở lại hệ thống cũ.

Giới kỹ thuật gọi cách làm này là strangler fig, theo tên một loài cây sung bám trên cây chủ rồi dần thay thế cây chủ. Lớp định tuyến giống người điều phối đứng ở cửa: chức năng đã có bản mới thì sang hệ thống mới, phần còn lại vẫn vào hệ thống cũ. Tài liệu hướng dẫn của AWS về mẫu strangler fig mô tả cách làm này cho việc tách ứng dụng nguyên khối thành các dịch vụ nhỏ, gồm xây phần mới song song, cho cũ và mới cùng tồn tại, rồi loại bỏ phần cũ. Diễn giải cho phần mềm doanh nghiệp nói chung, ba giai đoạn như sau:

1. Đặt lớp định tuyến: người dùng vẫn làm việc như bình thường, mọi yêu cầu đi qua một điểm chung và mọi chức năng vẫn do hệ thống cũ xử lý.
2. Chuyển từng chức năng: mỗi đợt làm mới một chức năng hoặc một nhóm nhỏ, chạy song song, đối soát dữ liệu rồi mới chuyển tiếp. Chức năng mới gặp lỗi thì luồng được đưa về hệ thống cũ, vì phần cũ vẫn đang chạy.
3. Tắt phần cũ: khi không còn chức năng nào đi qua hệ thống cũ, doanh nghiệp lưu trữ dữ liệu rồi tắt hẳn.

Lợi ích với người điều hành là rủi ro được chia nhỏ theo từng chức năng thay vì dồn vào một ngày chuyển đổi duy nhất, và mỗi đợt đều mang lại phần giá trị dùng được ngay.

Nên chuyển chức năng nào trước?

Nên chuyển trước chức năng ít phụ thuộc vào phần khác, tách được dữ liệu, đang gây áp lực rõ và dễ đo kết quả, chẳng hạn tra cứu hoặc báo cáo. Phần gắn với tiền, công nợ và tồn kho nên để sau, khi đội dự án đã quen quy trình chuyển đổi.

Với phần mềm quản lý bán hàng, có thể bắt đầu từ tra cứu đơn hàng vì chỉ đọc dữ liệu, sau đó đến tạo đơn, cuối cùng mới đến công nợ. Một điểm khó thường gặp là dữ liệu dùng chung: ở mỗi giai đoạn phải xác định loại dữ liệu nào lấy hệ thống nào làm bản gốc, nếu không số liệu sẽ lệch ngay trong lúc chuyển đổi.

Thay từng phần có những giới hạn gì?

Theo hướng dẫn của AWS, thay từng phần không hợp với hệ thống nhỏ, ít phức tạp và không dùng được khi không chặn, chuyển hướng được yêu cầu. Lớp định tuyến thiết kế kém có thể thành điểm nghẽn hiệu năng hoặc làm dừng cả hệ thống, và mỗi chức năng đều cần phương án quay lại.

• Không có điểm để chặn yêu cầu: phần mềm cài trên từng máy và nối thẳng vào cơ sở dữ liệu là tình huống điển hình. Khi đó có thể chuyển theo từng bộ phận hoặc chi nhánh thay vì từng chức năng.
• Lớp định tuyến thành điểm yếu mới: mọi yêu cầu đều đi qua lớp này, nên nó cần đủ tải, có giám sát và có phương án dự phòng ngay từ đầu.

Một rủi ro về quản trị cần tính trước: dự án có thể dừng ở giai đoạn hai vì phần dễ đã chuyển xong và áp lực đã giảm, khiến doanh nghiệp phải duy trì cả hai hệ thống trong thời gian dài. Ngay từ đầu cần chốt điều kiện tắt phần cũ và người chịu trách nhiệm cho mốc đó.

5. Tiếp quản hệ thống từ đơn vị cũ cần nhận những gì?

Doanh nghiệp cần nhận mã nguồn mới nhất, cơ sở dữ liệu, tài liệu, quyền máy chủ, tên miền, tài khoản dịch vụ bên thứ ba và khóa truy cập. Bàn giao chỉ thật sự hoàn tất khi một đội khác dựng lại và chạy được hệ thống từ những gì đã nhận.

Nên làm theo thứ tự: sao lưu dữ liệu và thử khôi phục trước; đọc lại hợp đồng để xác định quyền sở hữu và nghĩa vụ bàn giao; gửi danh mục trên bằng văn bản, có thời hạn; dựng thử từ những gì đã nhận rồi mới xác nhận hoàn tất; cuối cùng đổi mật khẩu, khóa API và gỡ tài khoản cũ.

Sau bàn giao là bước kiểm kê để các lựa chọn phía sau có căn cứ: chức năng nào còn được dùng, hệ thống đang nối với những gì, tác vụ nào chạy ban đêm, file Excel nào đang vận hành song song, và quy tắc tính toán nào chỉ nằm trong mã nguồn hoặc trong đầu kế toán lâu năm.

Đơn vị cũ không bàn giao hoặc đã giải thể thì làm thế nào?

Khi không nhận được mã nguồn, doanh nghiệp vẫn còn dữ liệu đang chạy, hành vi của phần mềm và kinh nghiệm của người dùng. Việc đầu tiên là sao lưu dữ liệu và bảo vệ quyền truy cập, sau đó giữ hệ thống chạy tạm trong lúc chuẩn bị làm lại hoặc chuyển sang gói có sẵn.

Lúc này sửa dần và thay từng phần thường không còn khả thi. Doanh nghiệp nên chụp lại màn hình, mẫu báo cáo và ghi lại quy tắc tính toán qua trao đổi với kế toán, thủ kho. Nếu có tranh chấp về quyền sở hữu mã nguồn, doanh nghiệp nên nhờ luật sư xem xét; nội dung bài viết này không thay tư vấn pháp lý.

6. Di chuyển dữ liệu thế nào để không sai lệch và có đường quay lại?

Nên chạy thử di chuyển dữ liệu nhiều lần trên bản sao, đối soát số lượng và số tổng giữa cũ và mới, rồi mới chọn thời điểm chuyển thật. Trước ngày chuyển, doanh nghiệp cần có bản sao lưu đã thử khôi phục, phương án quay lại đã diễn tập và người có quyền quyết định.

Phần tốn công thường không nằm ở việc chép dữ liệu, mà ở những lỗi hệ thống cũ vẫn chấp nhận được: khách hàng trùng mã, trường bắt buộc bị bỏ trống, tiếng Việt lưu bằng bảng mã TCVN3 hoặc VNI thay vì Unicode.

Phương án quay lại có hạn sử dụng: càng nhiều giao dịch phát sinh trên hệ thống mới, việc quay về càng khó. Do vậy kế hoạch cần ghi rõ lỗi nào thì kích hoạt quay lại, ai quyết định, và đến mốc nào thì chỉ còn sửa lỗi trên hệ thống mới. Hệ thống nhỏ chấp nhận được khoảng dừng ngắn có thể chuyển một lần; dữ liệu lớn hoặc nhiều chi nhánh thường nên chuyển theo đợt.

Trong dự án cho một ngân hàng thương mại tại Campuchia có 192 chi nhánh, yêu cầu đặt ra là không để mất dữ liệu và duy trì dịch vụ trong suốt quá trình chuyển đổi. Đội ngũ chuyên gia của Savvycom đã đồng hành di chuyển hơn 300.000 bản ghi, có kiểm tra đầy đủ và có phương án quay lại. Bảng trên là khung tham khảo chung, còn dự án này minh họa mức yêu cầu về dữ liệu.

7. Chi phí hiện đại hóa phần mềm cũ phụ thuộc vào những yếu tố nào?

Chi phí hiện đại hóa không có mức chung, vì phụ thuộc vào hướng đi đã chọn, độ đầy đủ của mã nguồn và tài liệu, số nghiệp vụ, số hệ thống phải kết nối, độ sạch của dữ liệu, thời gian chạy song song và yêu cầu bảo mật của ngành.

Vì vậy nên tách khảo sát và kiểm kê thành giai đoạn đầu, bởi chưa biết hiện trạng thì mọi báo giá cả dự án đều dựa trên phỏng đoán. Khi so sánh phương án, doanh nghiệp cũng nên tính chi phí của việc không làm gì: công nhập liệu lặp lại, yêu cầu kinh doanh phải chờ và thiệt hại nếu hệ thống dừng. Cách tách ngân sách có trong bài chi phí phát triển phần mềm theo yêu cầu và cách đọc báo giá, còn tiến độ được phân tích trong bài làm phần mềm theo yêu cầu mất bao lâu.

8. AI giúp được gì khi hiện đại hóa hệ thống cũ?

AI hỗ trợ đọc và tóm tắt mã nguồn cũ, phác thảo tài liệu còn thiếu, gợi ý tình huống kiểm thử và phát hiện dữ liệu bất thường, nhưng không thay được người hiểu nghiệp vụ. Mọi kết quả đều cần kỹ sư và người dùng nghiệp vụ kiểm tra lại trước khi áp dụng.

AI thường phát huy ở giai đoạn tiếp quản và kiểm kê, khi hệ thống thiếu tài liệu và không còn người để hỏi. Còn việc đưa tính năng AI vào sản phẩm, như đọc chứng từ hay trợ lý tra cứu nội bộ, nên làm sau khi dữ liệu đã sạch và các hệ thống đã kết nối.

9. Savvycom đã hiện đại hóa hệ thống cũ cho doanh nghiệp như thế nào?

Savvycom đã đồng hành cùng một ngân hàng, một nền tảng nội dung số, một công ty thuế và một trường đào tạo hiện đại hóa hệ thống đang vận hành. Mỗi dự án đi một hướng khác nhau, từ làm lại ứng dụng và tách backend đến chuyển dữ liệu sang hệ thống may đo hoặc thay nền tảng quản trị.

• Một ngân hàng thương mại tại Campuchia: ứng dụng di động cũ không còn đáp ứng kỳ vọng của khách hàng, phía sau là kiến trúc nguyên khối và các hệ thống rời rạc. Savvycom đã đồng hành làm lại ứng dụng, tách backend thành microservices, tích hợp WSO2 làm cổng API và di chuyển dữ liệu sang hệ thống mới. Ứng dụng mới đã được triển khai trên 192 chi nhánh (dự án làm lại ứng dụng mobile banking tại Campuchia).
• YES24 Channel YES, Hàn Quốc: nợ kỹ thuật tích tụ khiến giao diện lỗi thời và hiệu năng giảm, trong khi việc làm mới không được gián đoạn vận hành. Dự án kéo dài 6 tháng, Savvycom làm mới cả frontend và backend của Channel YES; điểm hài lòng của khách hàng đạt trên 90% (làm mới nền tảng nội dung số YES24 Channel YES).
• Shinseung, một trong 10 công ty thuế hàng đầu Hàn Quốc: hợp đồng và thanh toán từng xử lý trên giấy và thủ công. Savvycom đã xây dựng hệ thống quản lý tài chính may đo, tích hợp thanh toán và chuyển hơn 4.000 hợp đồng từ hệ thống cũ sang nền tảng mới (số hóa quản lý hợp đồng và thanh toán cho Shinseung).
• KG KAIROS, Hàn Quốc: website trường đào tạo AI và robot chạy trên hạ tầng cũ, cập nhật nội dung thường ngày cũng phải nhờ lập trình viên. Savvycom đã thay bằng Strapi kết hợp cổng quản trị riêng, để nhân viên không chuyên kỹ thuật tự cập nhật nội dung (website và hệ thống quản trị nội dung mới của KG KAIROS).

Với doanh nghiệp cần đánh giá một hệ thống đang chạy, dịch vụ phát triển phần mềm theo yêu cầu của Savvycom bắt đầu từ đánh giá hiện trạng, rồi mới chốt phần nào giữ lại và phần nào cần thay.

Câu hỏi thường gặp về hiện đại hóa phần mềm cũ

1. Khi nào nên bắt đầu hiện đại hóa phần mềm cũ?
Nên bắt đầu trước khi có sự cố, lúc hệ thống còn chạy ổn và người hiểu hệ thống còn liên hệ được. Việc đầu tiên không phải viết mã mới mà là tiếp quản và đánh giá hiện trạng. Nếu đơn vị cũ sắp ngừng hỗ trợ, nên nhận bàn giao ngay dù chưa có ngân sách thay thế.

2. Làm sao nhận lại mã nguồn từ đơn vị phát triển cũ?
Hãy đọc lại hợp đồng để biết điều khoản về quyền sở hữu và bàn giao, rồi gửi danh mục cần nhận bằng văn bản. Sau khi nhận, cần dựng thử hệ thống từ mã nguồn trên môi trường riêng để xác nhận đúng bản đang chạy. Khi có tranh chấp về quyền, doanh nghiệp nên hỏi luật sư.

3. Hiện đại hóa có phải dừng hệ thống không?
Thường không phải dừng toàn bộ nếu thay từng phần hoặc chuyển dữ liệu theo đợt. Tuy vậy, thời điểm chốt dữ liệu cho các nghiệp vụ như công nợ hay tồn kho có thể cần một khoảng tạm ngưng ngắn, nên lên kế hoạch vào giờ ít giao dịch và thông báo trước cho người dùng.

4. Có nên làm lại phần mềm từ đầu không?
Chỉ nên làm lại khi công nghệ không còn sửa được, còn nghiệp vụ vẫn tạo khác biệt và đủ rõ để mô tả lại. Trước khi quyết định, hãy cân nhắc sửa dần, thay từng phần hoặc gói có sẵn, vì làm lại dễ bỏ sót những quy tắc nghiệp vụ nằm trong mã nguồn cũ.