Hiện đại hóa hệ thống cũ: giữ, thay dần hay viết lại?

Đăng ngày 25/10/2026

Tóm tắt và điều cần nhớ

Hiện đại hóa hệ thống cũ là quyết định thay đổi phần nào để công việc tiếp tục chạy được với rủi ro chấp nhận được. Không nên bắt đầu bằng lời hứa viết lại toàn bộ. Một ứng dụng lâu năm có thể giữ những quy tắc nghiệp vụ quan trọng chưa được ghi chép; bỏ mã cũ trước khi hiểu chúng có thể làm mất cả khả năng vận hành.

• Phân biệt tuổi hệ thống với rủi ro và hạn chế đang gây ra.
• Chọn giữa giữ, bao bọc, thay thế và ngừng dùng theo từng phần việc.
• Dùng strangler fig như một mẫu thực hành thay dần, không xem đó là bảo đảm thành công.
• Kiểm dữ liệu, quy tắc ngoại lệ và đường quay lại trước khi chuyển người dùng.
• AI có thể hỗ trợ tìm hiểu mã nhưng kết quả vẫn cần người hiểu nghiệp vụ kiểm tra.

Hệ thống cũ: cũ ở tuổi đời hay ở khả năng phục vụ?

Một hệ thống được xây từ lâu chưa tự động cần bỏ. Câu hỏi quan trọng hơn là còn hỗ trợ được công việc, sửa được khi có lỗi và được vận hành an toàn không. Ngược lại, phần mềm mới triển khai cũng có thể tạo gánh nặng nếu thiếu người hiểu, thiếu tài liệu hoặc lệ thuộc vào thành phần không còn được hỗ trợ. Đánh giá cần bắt đầu từ biểu hiện quan sát được.

Chính phủ Anh có tài liệu định nghĩa legacy IT mới, cập nhật ngày 17/08/2026; phần mở đầu nêu nó thay các định nghĩa trước trong khung đánh giá rủi ro. Điều này nhắc rằng ngay cả cách gọi hệ thống cũ cũng có phiên bản. Bài không sao chép tiêu chí chi tiết chưa đọc đủ và không đưa một ngưỡng của khu vực công Anh thành quy tắc bắt buộc cho doanh nghiệp Việt Nam [1].

Tín hiệu nào cần được ưu tiên kiểm tra?

Mẫu tín hiệu sau do bài viết đề xuất để mở cuộc rà soát, không phải phép chấm điểm đã kiểm định. Mỗi tín hiệu phải có bằng chứng và người chịu trách nhiệm xác minh. Đừng gộp thành một điểm trung bình khiến một rủi ro nghiêm trọng bị che bởi nhiều mục đang ổn. Khi thiếu thông tin, ghi chưa biết thay vì tự điền mức rủi ro thấp.

• Hỗ trợ: thành phần nào không còn được bảo trì hoặc không rõ đầu mối xử lý?
• Hiểu biết: quy tắc nào chỉ một người nhớ, chưa có tài liệu kiểm tra lại?
• Thay đổi: sửa một phần có làm nhiều phần khác phải kiểm lại không?
• Công việc: thao tác nào khiến nhân viên phải nhập lại hoặc làm ngoài phần mềm?
• Dữ liệu: có sai khác nào chưa giải thích được giữa báo cáo và giao dịch gốc?
• Phục hồi: đã thử đưa hệ thống trở lại sau lỗi, hay mới chỉ lưu bản sao?

Tài liệu hướng dẫn khung đánh giá rủi ro legacy của Anh cho thấy một cách tổ chức việc rà soát ở cấp khu vực công. Nó không phải danh mục giải pháp mua sẵn. Trong bài, tài liệu chỉ là tham chiếu về việc cần một cơ chế nhìn rủi ro có cấu trúc; không áp ngưỡng đánh giá của một cơ quan nước ngoài vào trường hợp doanh nghiệp chưa được khảo sát [2].

Nợ kỹ thuật có thể được nhìn từ công việc nào?

Trong phạm vi bài này, nợ kỹ thuật được dùng như cách mô tả phần việc sửa chữa bị để lại và làm thay đổi sau đó khó hơn. Đây là định nghĩa làm việc phục vụ quyết định, không phải phép quy mọi đoạn mã khó đọc thành tiền. Một khoản cần được mô tả bằng hệ quả: lỗi lặp, thời gian kiểm dài hoặc yêu cầu nghiệp vụ bị chặn.

Tornhill và Borg đưa bản nghiên cứu Code Red lên arXiv tháng ba năm 2022, phân tích 39 cơ sở mã sản xuất độc quyền bằng công cụ CodeScene. Tóm tắt báo cáo việc xử lý issue trong nhóm mã chất lượng thấp cần thêm trung bình 124% thời gian phát triển. Đây là so sánh quan sát theo cách phân loại của nghiên cứu, không chứng minh cứ làm đẹp mã là thời gian của mọi nhóm sẽ giảm theo tỷ lệ ấy [3].

Khi dùng kết quả này, phải giữ giới hạn mẫu và phương pháp. Bài chưa kiểm toán lại dữ liệu doanh nghiệp trong nghiên cứu và chỉ đọc tóm tắt, không nhận đã tái lập kết quả. Nghiên cứu dùng một công cụ cụ thể, nên khả năng áp dụng theo cách đo khác còn cần kiểm tra. Do đó, số liệu là lý do nên đo vấn đề chất lượng mã trong bối cảnh của mình, không phải hệ số để tính sẵn lợi tức đầu tư.

Cây quyết định: giữ, bao bọc, thay hay bỏ?

Cây quyết định dưới đây là công cụ riêng của bài, dùng cho một phần chức năng đã xác định. Câu hỏi đầu tiên là công việc ấy còn cần không. Nếu không còn nhu cầu, xem điều kiện ngừng dùng và giữ hồ sơ cần thiết. Nếu còn, hỏi phần hiện tại có đáp ứng được với công sức bảo trì hợp lý không, rồi mới xem lựa chọn giữ hay thay.

• Giữ: công việc còn cần, vận hành đáp ứng và rủi ro được kiểm soát; bổ sung tài liệu, kiểm thử hoặc nâng cấp cần thiết.
• Bao bọc: phần lõi còn dùng được nhưng cách truy cập hoặc kết nối cần tách ra để đổi từng bước.
• Thay: phần hiện tại không đáp ứng, có phương án mới kiểm chứng được và có cách chuyển dữ liệu, người dùng.
• Bỏ: công việc không còn cần hoặc đã được thay hoàn toàn; xác nhận trách nhiệm lưu giữ và ngừng vận hành.

Không được chọn bỏ chỉ vì ít người đăng nhập. Một hệ thống có thể chỉ được dùng vào kỳ chốt số liệu nhưng vẫn quan trọng. Cũng không chọn giữ chỉ vì chưa xảy ra sự cố trong thời gian quan sát ngắn. Người quyết định cần hỏi bằng chứng về khả năng hỗ trợ, phục hồi và đáp ứng công việc, cùng thời điểm xem lại kết luận khi điều kiện thay đổi.

Strangler fig: thay dần hành vi thay vì chỉ chia mã

Trong cách trình bày của Martin Fowler, strangler fig chỉ quá trình đổi từng phần: phần mới được xây tách khỏi mã cũ rồi nhận dần hành vi trước đó do hệ thống cũ đảm nhiệm. Bài viết trên trang của ông mang ngày 22/08/2024. Đây là kinh nghiệm và mẫu thực hành của tác giả trong lĩnh vực tư vấn phần mềm, không phải nghiên cứu có nhóm đối chứng xác lập tỷ lệ thành công [4].

Một cách áp dụng giả định là tách chức năng tra cứu trạng thái đơn trước khi thay phần ghi nhận giao dịch. Phần mới có thể đọc từ nguồn dữ liệu được thống nhất trong khi hệ thống cũ vẫn xử lý công việc chính. Sau khi kết quả tra cứu được kiểm, nhóm mới xem xét bước tiếp theo. Ví dụ này minh họa cách chia phạm vi, không phải công thức áp dụng nguyên trạng cho mọi phần mềm.

Khó khăn thường nằm ở ranh giới nghiệp vụ. Hai màn hình khác nhau có thể cùng sửa một loại dữ liệu hoặc cùng phụ thuộc một quy tắc mà đội chưa biết. Nếu chia theo màn hình trước khi hiểu quan hệ đó, phần chuyển tiếp có thể trở thành nơi phát sinh sai lệch. Hãy chọn phạm vi có thể nêu đầu vào, đầu ra, người sử dụng và cách kiểm rõ ràng.

Kiến trúc chuyển tiếp cũng cần ngân sách và ngày xem lại. Phần mã chỉ dùng để hai hệ thống cùng tồn tại không tự biến mất khi tính năng mới chạy được. Doanh nghiệp cần biết ai chịu trách nhiệm gỡ phần chuyển tiếp, điều kiện nào xác nhận không còn dùng và tài liệu nào phải cập nhật. Không nên coi việc thay từng phần là lý do để giữ cả hai hệ thống vô thời hạn.

Khi nào viết lại hoặc mua mới đáng xem xét?

Viết lại có thể được đưa ra xem xét nếu phần hiện tại không thể đáp ứng yêu cầu quan trọng với rủi ro và chi phí chấp nhận được. Tuy nhiên, cần mô tả yêu cầu ấy bằng công việc, không bằng sự yêu thích ngôn ngữ lập trình. Một phương án mới phải chứng minh cả dữ liệu, chức năng và khả năng chuyển đổi; màn trình diễn giao diện chưa trả lời được các điều kiện đó.

Mua sản phẩm có sẵn phù hợp khi nghiệp vụ có thể dùng những chức năng đã được kiểm và doanh nghiệp chấp nhận thay cách làm tương ứng. Nếu phải sửa rất nhiều để tái tạo mọi ngoại lệ cũ, hãy xem lại lý do mua. Bài không so nhãn sản phẩm hay chọn ERP; trọng tâm là xác định phần nào thực sự đặc thù và phần nào chỉ được giữ vì thói quen.

Dữ liệu và quy tắc ngoại lệ phải đi qua phép kiểm

Trước khi chuyển người dùng, cần thống nhất dữ liệu nào được chuyển, dữ liệu nào chỉ cần tra cứu và ai xác nhận kết quả. Không chỉ đếm số dòng. Một tập dữ liệu có thể đủ dòng nhưng sai liên hệ giữa đơn hàng và thanh toán, hoặc thiếu cách diễn giải mã trạng thái. Người hiểu nghiệp vụ cần kiểm các tình huống có ý nghĩa, gồm cả trường hợp hủy, sửa và ghi nhận muộn.

NIST giới thiệu SSDF phiên bản 1.1 vào tháng hai năm 2022 như nhóm thực hành phát triển phần mềm an toàn ở cấp cao, có thể tích hợp vào vòng đời phát triển. Trang tóm tắt còn nêu vai trò tạo ngôn ngữ chung khi trao đổi với nhà cung cấp. Bài chỉ dùng phần giới thiệu này, không diễn giải điều khoản bên trong hay coi SSDF là yêu cầu pháp lý bắt buộc tại Việt Nam [5].

Kế hoạch phải nói cả cách xử lý hệ thống cũ

Trong rà soát các hệ thống liên bang Mỹ công bố tháng bảy năm 2025, GAO nhận thấy chín trong mười một hệ thống được xem xét đã có kế hoạch hiện đại hóa. Chỉ ba trong chín kế hoạch có đủ cả mốc hoàn thành, mô tả công việc và hướng xử lý hệ thống cũ. Đây là nhóm hệ thống cụ thể do GAO đánh giá, không phải tỷ lệ đại diện cho dự án doanh nghiệp [6].

Một báo cáo khác của GAO về IRS, đề ngày 16/09/2025, ghi cơ quan này tạm dừng các chương trình hiện đại hóa từ tháng ba để đánh giá lại ưu tiên. Bài dùng sự kiện trong phạm vi thời điểm báo cáo, không suy rằng chương trình vẫn dừng ở hiện tại. Nó cho thấy kế hoạch kỹ thuật còn chịu ảnh hưởng của quyết định ưu tiên tổ chức, điều cần được ghi vào giả định triển khai [7].

Với doanh nghiệp, kế hoạch gọn vẫn cần trả lời ba câu: phần việc nào được chuyển, bằng chứng nào cho phép chuyển và chuyện gì xảy ra với phần cũ sau đó. Phải có người được quyền xác nhận ngừng hệ thống, cùng cách giữ thông tin còn cần tra cứu. Nếu chưa có quyền quyết định này, dự án có thể giao được phần mềm mới nhưng vẫn tiếp tục gánh toàn bộ chi phí phần cũ.

Theo quy mô: doanh nghiệp vừa, lớn và tập đoàn

Doanh nghiệp vừa có thể bắt đầu từ một danh mục ứng dụng và những người đang nắm kiến thức. Nếu phụ thuộc đơn vị triển khai ngoài, ưu tiên lấy lại tài liệu, quyền quản trị phù hợp và quy trình khôi phục. Chọn một phần việc đủ nhỏ để hoàn thành vòng kiểm, tránh mở dự án thay toàn bộ chỉ vì một báo cáo khó sửa.

Doanh nghiệp lớn cần làm rõ ảnh hưởng giữa các bộ phận trước khi thay một hệ thống dùng chung. Một thay đổi được đơn vị này coi là cải tiến có thể làm đơn vị khác mất dữ liệu cần đối chiếu. Nên có cơ chế giải quyết khác biệt về ưu tiên, không chỉ một danh sách yêu cầu do bên kỹ thuật tổng hợp. Trách nhiệm phê duyệt nghiệp vụ phải đi cùng trách nhiệm kỹ thuật.

Ở nhóm tập đoàn, kể cả doanh nghiệp lớn thuộc Nhà nước, nên phân tiếp theo cách vận hành: đơn vị có đội phát triển riêng và đơn vị thuê dịch vụ. Nhóm tự phát triển cần giữ kiến thức về mã, phụ thuộc và kiểm thử. Nhóm thuê cần chú trọng điều kiện bàn giao, trách nhiệm chuyển dữ liệu và hỗ trợ sau thay đổi. Bài chỉ đề xuất cách tổ chức câu hỏi, không kết luận quy trình mua sắm hay cấp phê duyệt của bất kỳ đơn vị nào.

Ở cả ba nhóm, nên dành thời gian của người thực sự sử dụng hệ thống để kiểm chức năng. Không thể giao toàn bộ hiểu biết nghiệp vụ cho bên viết mã. Mức tài liệu có thể khác theo quy mô, nhưng tối thiểu người tiếp nhận cần biết hệ thống làm việc gì, giới hạn nào đang tồn tại và cách báo lỗi khi kết quả không phù hợp.

Góc nhìn AI có thể giúp đọc mã cũ, nhưng hiệu quả cần được đo

AI có thể được thử ở nhiệm vụ tạo bản nháp tài liệu, tìm vị trí xử lý một quy tắc hoặc gợi ý trường hợp kiểm thử. Đề xuất của bài là yêu cầu công cụ chỉ ra tệp và đoạn mã liên quan, rồi để người hiểu hệ thống đối chiếu. Một lời giải thích trôi chảy không thay cho bằng chứng rằng mô tả khớp hành vi ứng dụng đang chạy.

Thử nghiệm ngẫu nhiên của METR với công cụ đầu năm 2025 gồm mười sáu lập trình viên làm 246 tác vụ trên dự án nguồn mở đã quen thuộc. Nhóm được dùng AI cần thời gian hoàn thành dài hơn 19%. Đây là kết quả trong bối cảnh cụ thể với công cụ và người tham gia được nghiên cứu, không phải kết luận rằng mọi lập trình viên hay mọi dự án dùng AI đều chậm hơn [8].

Ngày 24/02/2026, METR thông báo đổi thiết kế thử nghiệm. Nhóm nghiên cứu cho rằng dữ liệu mới chưa cho tín hiệu đáng tin về hiệu quả hiện tại, do lựa chọn tham gia và cách đo thời gian khi dùng nhiều tác tử. Vì vậy, không kéo tỷ lệ của thử nghiệm cũ sang công cụ mới, cũng không lấy cảm nhận dùng nhanh hơn làm bằng chứng định lượng chắc chắn [9].

Khi áp dụng, có thể chọn vài tác vụ tương đương để so thời gian hoàn thành đạt yêu cầu, gồm cả đọc lại và sửa lỗi. Tài liệu do AI tạo cần gắn với phiên bản mã đã kiểm. Không đưa bí mật hoặc dữ liệu công việc vào công cụ khi chưa có quyền và điều kiện phù hợp. Người duyệt phải biết kết quả nào là suy đoán của AI chưa được xác nhận.

AI cũng không tự quyết được ngoại lệ nghiệp vụ nào còn cần. Nếu mô hình đề nghị xóa một nhánh mã hiếm chạy, phải kiểm ai dùng và trong tình huống nào. Phần có tác động lớn cần được thử trong môi trường thích hợp trước. Cách dùng hữu ích là giảm công sức tìm hiểu có kiểm soát, không biến một lần sinh mã thành lý do bỏ kiểm thử và phương án quay lại.

Hiện đại hóa hệ thống cũ tại Việt Nam: tách sản phẩm khỏi lời hứa

Tài liệu FPT Cloud giới thiệu các dịch vụ cơ sở dữ liệu được quản lý, container và giám sát. Đó là mô tả năng lực sản phẩm của nhà cung cấp trong nước, không phải bằng chứng rằng một hệ thống cũ cụ thể chuyển sang sẽ tốt hơn. Khi mua hạ tầng cho phần mới, doanh nghiệp vẫn phải kiểm phiên bản, dữ liệu và phụ thuộc ứng dụng của mình [10].

Điểm tham khảo từ SSDF của NIST là dùng ngôn ngữ thực hành chung để trao đổi với bên làm phần mềm. Với hợp đồng đang xem xét tại Việt Nam, có thể yêu cầu mô tả cách kiểm, tài liệu bàn giao và trách nhiệm sửa lỗi. Đây là gợi ý mua hàng của bài, không khẳng định nhà cung cấp đã tuân thủ khung hoặc một hợp đồng đã đáp ứng quy định trong nước [5].

Sai lầm và giới hạn khi hiện đại hóa ứng dụng cũ

Sai lầm đầu tiên là đặt mục tiêu chỉ bằng công nghệ mới rồi để nghiệp vụ tự thích nghi sau. Một dự án có thể thay toàn bộ ngôn ngữ lập trình nhưng giữ nguyên chỗ nghẽn trong cách làm việc. Hãy đặt kết quả cần quan sát được trước: thao tác nào tốt hơn, lỗi nào giảm hoặc thay đổi nào trước đây không làm được nay thực hiện được với kiểm soát phù hợp.

Sai lầm tiếp theo là dồn mọi yêu cầu mới vào bản thay thế, trong khi hệ cũ vẫn phải chạy. Khi phạm vi không có cửa chốt, thời điểm chuyển cứ lùi mà hai phía đều cần bảo trì. Ngược lại, cắt quá nhỏ nhưng không có hướng xử lý phần cũ cũng tạo kéo dài. Mỗi phần cần có giá trị sử dụng cùng điều kiện kết thúc rõ.

Giới hạn của bài là chưa khảo sát mã hoặc nghiệp vụ của một doanh nghiệp Việt Nam cụ thể. Nghiên cứu quan sát, thực nghiệm AI và rà soát cơ quan công có đối tượng khác nhau. Cây quyết định cùng tín hiệu chỉ giúp chuẩn bị cuộc đánh giá. Muốn chọn giữ hay thay, phải có bằng chứng từ hệ thống thực tế và người được quyền chấp nhận thay đổi.

Hỏi đáp về hệ thống legacy và viết lại phần mềm

Có phải phần mềm lâu năm đều là nợ kỹ thuật không? Không nên dùng tuổi làm câu trả lời duy nhất. Cần biết nó đang đáp ứng công việc thế nào, có người hỗ trợ và sửa được không. Một hệ thống cũ được kiểm soát có thể tiếp tục sử dụng trong khi một phần khác cần thay. Hãy mô tả rủi ro cụ thể thay cho nhãn chung.

Strangler fig có bắt buộc dùng microservices không? Mẫu thực hành được dẫn tập trung vào chuyển dần hành vi khỏi hệ cũ, không biến một kiểu kiến trúc thành điều kiện bảo đảm thành công. Ranh giới chức năng và bằng chứng kiểm quan trọng hơn số dịch vụ được tách. Nếu phần tách làm tăng phụ thuộc khó hiểu, cần xem lại cách chia trước khi tiếp tục mở rộng.

Khi nào nên ngừng hệ thống cũ? Khi phần việc cần thiết đã có nơi đảm nhiệm, kết quả được kiểm và người có quyền xác nhận điều kiện lưu giữ, tra cứu đã được đáp ứng. Không lấy việc không còn lỗi được báo làm bằng chứng duy nhất. Nên ghi phần đã kiểm, người duyệt và cách xử lý nếu phát hiện thiếu thông tin sau chuyển đổi.

Có thể nhờ AI viết lại toàn bộ mã cũ không? Khả năng tạo mã chưa chứng minh ứng dụng mới giữ đúng các quy tắc cần thiết. AI có thể hỗ trợ một số nhiệm vụ, nhưng phải kiểm dữ liệu, chức năng và điều kiện vận hành. Với phần quan trọng, cần người hiểu nghiệp vụ cùng phép kiểm có ý nghĩa; không để lời giải thích của công cụ thay thế nghiệm thu.

Nếu không có đủ tài liệu cũ thì bắt đầu từ đâu? Chọn một luồng công việc đang được sử dụng, hỏi người thao tác và đối chiếu kết quả trên hệ thống. Ghi điều đã xác nhận riêng với suy đoán cần kiểm. Có thể làm bản mô tả ban đầu rồi bổ sung dần. Không nên đợi tài liệu hoàn hảo mới làm, cũng không nên xóa phần chưa hiểu.

Kết luận: đổi phần cần đổi và giữ được khả năng làm việc

Hiện đại hóa hệ thống cũ cần một ranh giới công việc, bằng chứng kiểm và người nhận trách nhiệm sau thay đổi. Bắt đầu từ lựa chọn giữ, bao bọc, thay hoặc bỏ cho từng phần giúp cuộc thảo luận rõ hơn. Dù dùng phương pháp thay dần hay chọn sản phẩm mới, hãy tính cả cách chuyển dữ liệu, xử lý phần cũ và điều kiện quay lại khi kết quả chưa đạt.

Nguồn và phương pháp

Bài được viết độc lập bằng tổng hợp có hỗ trợ AI, không phải bản dịch; nguồn đối chiếu ngày 25/10/2026. Nguồn gồm cơ quan công, tóm tắt nghiên cứu và thực hành chuyên gia. Fowler có bối cảnh tư vấn, Code Red dùng công cụ CodeScene, FPT bán dịch vụ. Chưa kiểm chứng hiệu quả cho hệ thống doanh nghiệp Việt Nam cụ thể. DORA năm 2025 không dùng vì chưa đọc đủ báo cáo; không lấy số từ phần tóm tắt tìm kiếm. Các tình huống tự dựng ghi giả định. Nội dung không thay tư vấn pháp lý, thuế hay tài chính; cần đọc tài liệu gốc trước khi áp dụng.