COBOL Được Chú Ý, Nhưng VB6 và PowerBuilder Mới Là Cuộc Khủng Hoảng Legacy Không Ai Để Ý

Hệ Thống Legacy Hiếm Khi Chỉ Có COBOL

Khi nói đến “hiện đại hóa hệ thống legacy”, câu chuyện gần như luôn mặc định xoay quanh COBOL trên mainframe — các batch job, bộ lập lịch JCL, trình giám sát giao dịch CICS, những lõi ngân hàng đã chạy hàng chục năm. Cách nhìn đó không sai, nhưng chưa đầy đủ. Bước vào hầu hết các tổ chức đủ “lâu đời” để có một hệ thống COBOL, bạn thường sẽ thấy thêm một vấn đề legacy thứ hai, âm thầm hơn, nằm ở một lớp cao hơn trong stack: các ứng dụng client-server thời Windows được viết bằng VB6 hoặc PowerBuilder vào khoảng cuối thập niên 1990 đến giữa thập niên 2000, vẫn đang chạy như công cụ nội bộ mà không ai muốn đụng vào.

Hai nhóm mã nguồn legacy này thường bị hầu hết các công cụ xử lý như hai vấn đề tách biệt — một bên là parser cho mainframe, bên kia là các đơn vị tư vấn di trú sang .NET — dù rằng, trong sơ đồ tổ chức của chính công ty đang vận hành chúng, đây thường là cùng một vấn đề với cùng một nguyên nhân: logic nghiệp vụ chưa từng được tài liệu hóa đầy đủ, do những người đã nghỉ hưu viết ra, nằm trong một ngôn ngữ mà đội kỹ thuật hiện tại không đọc thành thạo. Legacy Dragon phân tích cả hai, trên cùng một đồ thị AST, cùng một file nhị phân đơn lẻ, một cách có chủ đích — bởi vì tách công cụ theo thập kỷ ra đời của mã nguồn không phản ánh đúng cách rủi ro thực sự xuất hiện bên trong một hệ thống CNTT thật.

VB6 Năm 2026: Vẫn Chạy, Nhưng Ngày Càng Bị Dồn Vào Chân Tường

VB6 ra mắt năm 1998, và theo mọi lẽ thông thường, nó đáng lẽ đã bị khai tử từ nhiều năm trước. Nhưng thực tế không như vậy. Các bài viết trong năm 2026 vẫn liên tục đi đến cùng một kết luận: hàng nghìn doanh nghiệp vẫn phụ thuộc vào các ứng dụng VB6 trong môi trường sản xuất, và lập trường của Microsoft là tiếp tục giữ cho runtime VB6 hoạt động trên các phiên bản Windows hiện tại đối với những ứng dụng đã tồn tại, mà không mở rộng điều đó sang phát triển mới, vá lỗi bảo mật, hay hỗ trợ 64-bit.

Việc duy trì tình trạng đó đang ngày càng khó khăn hơn. Các phân tích gần đây về việc chạy VB6 trên Windows 11 chỉ ra rằng khả năng tương thích đã suy giảm qua từng phiên bản Windows lớn kể từ Windows 10 phiên bản 21H2, một phần do Windows 64-bit ngừng hỗ trợ các thành phần COM 32-bit mà nhiều ứng dụng VB6 phụ thuộc vào cho các control giao diện và tích hợp — những thành phần mà trong nhiều trường hợp, trình cài đặt gốc của chúng không còn tồn tại hoặc không còn chạy được nữa. Một đợt nâng cấp phần cứng vốn dĩ bình thường đối với hầu hết mọi ứng dụng khác lại có thể là sự kiện cuối cùng khiến một công cụ VB6 đã âm thầm chạy suốt hai mươi năm bị gãy.

Ở đây còn có khía cạnh tuân thủ, không chỉ là tương thích: PCI DSS v4.0 trở thành bắt buộc từ ngày 31 tháng 3 năm 2025, và yêu cầu quản lý lỗ hổng bảo mật trên toàn bộ các thành phần hệ thống nằm trong phạm vi áp dụng — một yêu cầu khó đáp ứng đối với phần mềm xây dựng trên nền runtime đã hơn một thập kỷ không nhận được bản vá bảo mật nào. Một ứng dụng không cần phải đặc biệt để trở thành gánh nặng tuân thủ. Nó chỉ cần vẫn đang chạy.

PowerBuilder: Chính Nhà Cung Cấp Đang Cho Thấy Quy Mô Của Nền Tảng Cài Đặt

Câu chuyện của PowerBuilder trông khác, nhưng chỉ ra cùng một sự thật nền tảng. Sybase (nay thuộc Appeon) đã phát hành PowerBuilder 2025 vào tháng 5 năm 2025 với các tính năng nhắm thẳng vào những tổ chức muốn hiện đại hóa tại chỗ thay vì viết lại từ đầu: tính năng làm mới giao diện không cần code (UI Theme) có thể cải tổ trực quan một màn hình legacy mà không cần viết lại, và tính năng tự động sinh REST API giúp phơi bày logic nghiệp vụ PowerBuilder hiện có cho các client di động và web mà không cần xây dựng lại. Một nhà cung cấp sẽ không đầu tư vào công cụ “hiện đại hóa mà không viết lại” trừ khi nền tảng người dùng vẫn đang chạy ứng dụng cũ đủ lớn, và đủ giá trị, để đáng được phục vụ trực tiếp thay vì bị bỏ mặc.

Những người có thể đọc và chỉnh sửa an toàn mã PowerBuilder đó cũng đang ngày càng khó tìm, vì cùng một lý do cấu trúc khiến nhân lực COBOL cạn kiệt: đó không phải là thứ các chương trình khoa học máy tính hiện nay giảng dạy, và những kỹ sư đã học nó ngay tại nơi làm việc trong thập niên 1990 và 2000 chính là thế hệ đang nghỉ hưu lúc này.

Vấn Đề Legacy Của Nhật Bản Không Chỉ Là Chuyện Mainframe

Đây là lúc bức tranh kết nối trở lại với lý do vì sao Legacy Dragon xử lý Shift-JIS, EBCDIC và DBCS ngay từ đầu thay vì mặc định dùng UTF-8. Bộ Kinh tế, Thương mại và Công nghiệp Nhật Bản (METI) đã thành lập một Ủy ban Hiện đại hóa Hệ thống Legacy hoạt động từ tháng 7 năm 2024 đến tháng 3 năm 2025, dựa trên một khảo sát xu hướng thị trường được thực hiện từ tháng 12 năm 2024 đến tháng 2 năm 2025, và công bố báo cáo toàn diện vào tháng 5 năm 2025. Các bài viết về báo cáo này, cũng như mối lo ngại rộng hơn mang tên “Vách Đá Kỹ Thuật Số 2025”, liên tục trích dẫn một con số khoảng 80% doanh nghiệp Nhật Bản vẫn phụ thuộc vào hệ thống legacy — một con số mà, xét về bản chất, bao trùm cả hệ thống COBOL mainframe lẫn công cụ client-server thời Windows, chứ không chỉ riêng một trong hai. Một parser chỉ đọc được COBOL, cùng lắm chỉ giải quyết được một nửa danh mục rủi ro đó.

Vì Sao Là Một Công Cụ Duy Nhất, Không Phải Hai

Điều đó không có nghĩa là VB6 và PowerBuilder cần cùng một lộ trình hiện đại hóa như COBOL và JCL — rủi ro về runtime, đường di trú, và bối cảnh kinh doanh thực sự khác nhau. Điểm chung của chúng là hình dạng thực sự của rủi ro: logic không được tài liệu hóa, những tác giả ngày càng lớn tuổi, và một hệ thống mà không ai muốn là người làm nó sụp đổ. Việc Legacy Dragon phân tích COBOL, JCL, PL/I, Assembly, SQL/DB2, CICS và REXX cùng với VB6, VB.NET và PowerBuilder — tổng cộng mười ngôn ngữ, trong một file nhị phân đơn lẻ, tạo ra cùng một đồ thị AST tương tác bất kể mã nguồn thuộc thập kỷ nào — là một canh cược rằng phần lớn tổ chức thực ra không cần một công cụ cho mainframe và một công cụ riêng cho legacy Windows. Họ cần một tấm bản đồ trung thực duy nhất cho tất cả những gì cũ kỹ mà doanh nghiệp vẫn đang phụ thuộc vào.

---

Đang phải quản lý cả hệ thống mainframe lẫn hệ thống client-server thời Windows? Xem cách Legacy Dragon phân tích cả mười ngôn ngữ tại dragon.aitytech.com, đọc thêm về điểm nghẽn phân tích mà nó được xây dựng để giải quyết hoặc vì sao nó được đóng gói dưới dạng file nhị phân đơn lẻ cho các môi trường bị khóa chặt, hoặc liên hệ với chúng tôi tại [email protected].