Hiện đại hóa hệ thống lõi: chọn lift & shift, re-platform hay rebuild, và đi theo thứ tự nào

Ngày 30/10/2026

Ba phương án lift & shift, re-platform và rebuild thường được đặt lên bàn như ba lựa chọn loại trừ nhau. Trên thực tế, đó là ba mức thay đổi với rủi ro và giá trị tăng dần. Vì vậy, nhiều ngân hàng kết hợp cả ba phương án theo từng lớp của hệ thống lõi. Bài viết có sử dụng số liệu từ các case study của McKinsey, AWS, Accenture, BCG cùng các case CBA, TSB, VPBank và Sacombank để trả lời nên bắt đầu từ đâu và đi theo thứ tự nào.

Tham khảo thêm các bài viết cùng chủ đề:

Multi-core strategy

Multi-core strategy: Khi nào ngân hàng cần nhiều core?

Vì sao các ngân hàng cần hiện đại hóa hệ thống lõi?

Các tổ chức đo chi phí duy trì hệ thống cũ theo định nghĩa và mẫu khác nhau, nên các con số dưới đây không gộp được thành một mức chung. Theo báo cáo Banking Trends 2026 của Accenture, khoảng 70% ngân sách CNTT của ngân hàng chỉ dành để bảo trì nợ kỹ thuật. Trên Business Standard ngày 1/8/2024, ông Vipin V của BCG cho biết khoảng 80% ngân sách CNTT dành cho vận hành. BCG cũng ước tính các ngân hàng Ấn Độ cần 1 tỷ USD trong 5 đến 10 năm để nâng cấp core. Tại Anh, một khảo sát 150 lãnh đạo đổi mới ngân hàng mà Financial IT đăng ngày 19/9/2025 ghi nhận mức chi 3,3 tỷ bảng mỗi năm chỉ để duy trì core, trung bình chiếm 24% ngân sách CNTT.

Tại Việt Nam, theo ông Eric Vũ Châu của CIMB, kênh số hiện xử lý 95 đến 98% giao dịch ở đa số ngân hàng, so với khoảng 70% trước đại dịch. Các mốc thay core của ngành ngân hàng Việt Nam đã diễn ra như sau. Đợt đầu trong 2000 đến 2004 với Sacombank và Techcombank, mở rộng trong 2005 đến 2010, nhóm theo sau trong 2011 đến 2015. Đợt thay lần hai bắt đầu từ khoảng năm 2020 và lan ra toàn ngành từ năm 2025. Vì vậy câu hỏi lúc này là phạm vi và thứ tự thay đổi, không còn là có nên thay hay không.

Ba phương án khác nhau

Khung 7R của AWS gồm retire, retain, rehost, relocate, repurchase, replatform và refactor/re-architect, trong đó ba phương án trên liên quan trực tiếp đến core. AWS Prescriptive Guidance định nghĩa rehost, còn gọi là lift & shift, là chuyển ứng dụng lên cloud mà không thay đổi gì ở ứng dụng. Replatform, hay lift, tinker and shift, là chuyển lên cloud kèm một mức tối ưu để vận hành hiệu quả hơn hoặc giảm chi phí. Refactor hay re-architect là sửa kiến trúc để dùng tối đa tính năng cloud-native.

Khi áp vào core ngân hàng, có thể hiểu như sau: Re-host chỉ đổi hạ tầng chạy core. Re-platform đổi nền tảng chạy, cơ sở dữ liệu hoặc nâng lên phiên bản mới. Rebuild đổi kiến trúc hoặc thay hẳn lõi.

Hình 1. So sánh ba phương án Lift & shift (rehost), Re-platform và Rebuild theo mức thay đổi, chi phí, thời gian, rủi ro và giá trị thu về. Mức đánh giá mang tính định tính do bài viết diễn giải. Nguồn định nghĩa: khung 7R của AWS Prescriptive Guidance.

Ưu và nhược điểm của mỗi phương pháp hiện đại hóa hệ thống lõi

Lift & shift là cách nhanh nhất. AWS cho rằng chuyển workload lên AWS giúp giảm tối thiểu 30 đến 40% tổng chi phí sở hữu (TCO). Đây là tuyên bố của một nhà cung cấp cloud trong tài liệu tháng 6/2021, cập nhật đến tháng 9/2022. Cũng tài liệu đó cho biết phương án này không hỗ trợ tính đàn hồi hay tái kiến trúc, và chạy nguyên trạng trên cloud có thể đắt hơn replatform hoặc refactor về dài hạn. Vì thế doanh nghiệp ưu tiên tốc độ có thể rehost trước rồi cân nhắc replatform sau.

Replatform nằm ở giữa. Theo Vietnam Investment Review ngày 14/11/2025, VPBank nâng core lên phiên bản mới nhất chạy cloud-native trên nền tảng container, với hơn 18 triệu tài khoản khách hàng, với thời gian chuyển đổi hệ thống (cutover) dưới 24 giờ. Ngân hàng nêu lợi ích là ra sản phẩm nhanh hơn, nhưng không công bố chi phí. Sacombank, theo Thị trường Tài chính Tiền tệ ngày 4/5/2026, nâng cấp core cùng lúc với hơn 20 hệ thống vệ tinh cho hơn 19 triệu khách hàng, chạy trên cloud nội bộ tự mở rộng. Các kết quả này là tuyên bố của từng ngân hàng, và chưa có số liệu độc lập về mức tiết kiệm của replatform so với rehost.

Rebuild có giá trị lớn nhất nhưng rủi ro cũng cao nhất. McKinsey đánh giá việc thay toàn bộ core hoặc xây mới hoàn toàn (greenfield) là hướng đi tốn kém và nhiều rủi ro. Trong bài đăng ngày 17/2/2022, dựa trên hơn 50 dự án chuyển đổi core banking trong 7 năm, McKinsey cho biết chỉ khoảng 30% hoàn tất đầy đủ việc chuyển sổ cái và sản phẩm. Các ngân hàng thường đánh giá thấp thời gian chuyển đổi tới 75%, có ngân hàng chi vượt 100%, và tiến độ kéo dài thêm 50 đến 100%.

Hình 2. Ba chỉ số rủi ro của dự án thay hệ thống lõi ngân hàng: khoảng 30% dự án hoàn tất đầy đủ việc chuyển sổ cái và sản phẩm, thời gian bị đánh giá thấp tới 75%, chi phí vượt tới 100% ở một số ngân hàng. Ba chỉ số đo ba nội dung khác nhau. Nguồn: McKinsey, “How to get a core banking transformation right: eight mistakes to avoid”, 17/02/2022 (phân tích hơn 50 dự án trong 7 năm).

Ca CBA là bài học lịch sử cho quy mô rủi ro này. Theo Finextra, ngân sách ban đầu là 580 triệu AUD cho chương trình 4 năm công bố tháng 4/2008, sau đó tăng thêm 150 triệu AUD năm 2009 và kéo dài thêm một năm do độ phức tạp tăng. Đến tháng 10/2012, iTnews cho biết CBA tuyên bố hoàn tất sau hơn 1 tỷ AUD và 5 năm, khi toàn bộ khách hàng bán lẻ và doanh nghiệp đã có tài khoản trên nền tảng mới.

Hoàn toàn có thể kết hợp nhiều giải pháp hiện đại hóa hệ thống

McKinsey nêu ba cách hiện đại hóa core: thay toàn bộ, greenfield, hoặc cải tạo rồi tách rời core hiện có. Hướng thứ ba dựa trên quan sát rằng chỉ 10% tùy biến trên core hiện có là do quy định hoặc thiết yếu cho nghiệp vụ. Từ đó McKinsey đề xuất bảy đòn bẩy tách core, bao gồm rút gọn tùy biến, tách master data, dùng microservices và tách front end khỏi core. Một ngân hàng được McKinsey dẫn ví dụ đã rút thời gian hiện đại hóa từ khoảng 4 năm xuống 2 năm nhờ cách tách rời này.

Hai kỹ thuật liên quan đến hệ thống lõi ngân hàng thường đi cùng hướng này. Hollowing out the core là rút logic nghiệp vụ, dịch vụ và quy trình ra khỏi khối nguyên khối cũ sang các lớp phù hợp của kiến trúc cloud, theo định nghĩa của Backbase (nguồn của nhà cung cấp). Strangler fig, theo Microsoft Learn, là thay dần từng phần chức năng bằng ứng dụng và dịch vụ mới vì khó thay cả hệ thống phức tạp trong một lần. Khảo sát của EY UK (công bố tháng 10/2025) cũng ghi nhận hollow the core là một hướng được nhiều ngân hàng chọn, với sidecar là xu hướng mới nổi.

Tại Việt Nam, ông Lưu Duy Đức của Sacombank cho rằng core chỉ nên giữ ba chức năng là khách hàng, sản phẩm và giao dịch, còn quản lý nguồn vốn, tài trợ thương mại và quản trị vận hành nên tách thành module độc lập. Lựa chọn giữa các hướng phụ thuộc vào mức tùy biến và nợ kỹ thuật của core hiện tại, cũng như tốc độ thay đổi sản phẩm mà ngân hàng cần.

Hình 3. Ma trận gợi ý chọn hướng hiện đại hóa theo mức tùy biến và nợ kỹ thuật của lõi, và tốc độ thay đổi sản phẩm cần thiết. Đây là khung gợi ý của bài viết, không phải số liệu từ nguồn nghiên cứu.

Quản trị, đối tác và cách cutover quyết định kết quả

Bên cạnh công nghệ, cách quản trị chương trình và lựa chọn đối tác cũng quyết định kết quả của dự án thay core. McKinsey liệt kê tám sai lầm thường gặp, trong đó có việc giữ thành phần cũ mà không có kế hoạch tắt, chọn đối tác theo giá và không tích hợp core với nền tảng rộng hơn. Ở các dự án kém thành công, sau hơn 5 năm hệ thống cũ vẫn chạy 10 đến 20% chức năng.

TSB minh họa rủi ro quản trị. Ngày 20/12/2022, FCA phạt TSB tổng cộng 48,65 triệu bảng cùng với PRA vì thất bại về vận hành và quản trị. Đợt di chuyển tháng 4/2018 ảnh hưởng đến 5,2 triệu khách hàng, hoạt động trở lại bình thường vào tháng 12/2018 và ngân hàng phải bồi hoàn 32,7 triệu bảng. FCA nhận định TSB không tổ chức và kiểm soát chương trình đầy đủ, đồng thời không quản lý tốt rủi ro từ việc thuê ngoài CNTT.

Cách cutover cũng ảnh hưởng đến rủi ro. McKinsey khuyến nghị lên lịch go-live mỗi một đến hai năm và đánh giá kết quả sau từng đợt. Sacombank chọn dịp nghỉ lễ 30/4 đến 1/5 để giảm tác động lên khách hàng doanh nghiệp, còn VPBank hoàn tất cutover trong chưa đến 24 giờ.

Lộ trình bốn giai đoạn và khuyến nghị

Từ các dữ kiện trên, bài viết đề xuất lộ trình bốn giai đoạn (khung gợi ý của bài, không phải số liệu nguồn). Giai đoạn một là khảo sát danh mục ứng dụng và mức tùy biến, để xác định phần 10% tùy biến thực sự cần giữ. Giai đoạn hai là ổn định bằng rehost hoặc replatform. Giai đoạn ba là tách lớp và áp dụng strangler fig theo từng miền nghiệp vụ. Giai đoạn bốn là thay lõi khi điều kiện về dữ liệu, đối tác và năng lực quản trị đã đủ. Mỗi giai đoạn nên có mốc go-live riêng cách nhau một đến hai năm.

Hình 4. Lộ trình bốn giai đoạn: khảo sát danh mục ứng dụng và mức tùy biến, ổn định bằng rehost hoặc replatform, tách lớp và thay dần từng miền nghiệp vụ (strangler fig), thay lõi khi đủ điều kiện, với go-live theo từng đợt khoảng mỗi 1 đến 2 năm. Nguồn: McKinsey (02/2022 và 01/2021); cách chia giai đoạn là khung tổng hợp của bài viết.

Lift & shift nhanh nhưng không hiện đại hóa, re-platform cân bằng giữa tốc độ và lợi ích, còn rebuild có giá trị cao nhất và rủi ro lớn nhất. Doanh nghiệp nên bắt đầu từ danh mục ứng dụng, chọn phương án theo từng lớp của hệ thống và đo kết quả sau mỗi đợt.

Tác giả: Ông Lương Ngọc Bình – Chuyên gia công nghệ ngân hàng – FPT IS – Tập đoàn FPT

Nguồn tham khảo

FPT IS

Đăng ký nhận tin tức mới nhất từ FPT IS