Migration là quá trình chuyển hệ thống hiện có sang môi trường mới, đồng thời rà soát và cải thiện khả năng bảo trì, khả năng mở rộng cũng như khả năng vận hành. Điều quan trọng là cần xem đây không chỉ là việc di chuyển máy chủ, mà là một hoạt động đổi mới có kế hoạch nhằm chuyển sang nền tảng vận hành tiếp theo mà không làm gián đoạn hoạt động kinh doanh.

Trong môi trường doanh nghiệp, ngày càng có nhiều trường hợp các hệ thống lõi và ứng dụng nghiệp vụ đã được sử dụng trong nhiều năm không còn đáp ứng được tốc độ vận hành hiện nay hoặc yêu cầu tích hợp giữa các hệ thống. Khi các vấn đề như quy trình vận hành chỉ một số nhân sự phụ trách mới nắm rõ, ngôn ngữ lập trình hoặc OS đã cũ, cùng áp lực kết nối với các hệ thống liên quan tích tụ theo thời gian, ngay cả việc cải tiến hằng ngày cũng trở nên khó khăn. Đây là lúc doanh nghiệp cần cân nhắc migration.

Lý do cần thực hiện migration không chỉ là vì hệ thống đã cũ, mà còn vì chi phí của việc tiếp tục trì hoãn ngày càng lớn, xét trên cả hai khía cạnh: duy trì hoạt động kinh doanh và cải thiện quy trình nghiệp vụ.

Chẳng hạn, những tình huống sau đang xuất hiện ở nhiều doanh nghiệp.

• Đang sử dụng máy chủ hoặc middleware sắp hết thời hạn bảo trì
• Mỗi lần chỉnh sửa, khó xác định phạm vi ảnh hưởng
• Phụ thuộc quá nhiều vào nhà cung cấp hoặc một số nhân sự phụ trách nhất định
• Khó bổ sung các yêu cầu nghiệp vụ mới
• Khó kết nối với cloud và các dịch vụ bên ngoài

AWS mô tả di chuyển ứng dụng là “quá trình chuyển từ môi trường này sang môi trường khác”, đồng thời nêu các lợi ích chính như tính linh hoạt, hiệu quả chi phí, khả năng tiếp cận công nghệ tiên tiến và cải thiện vận hành. Microsoft cũng nhấn mạnh rằng chiến lược di chuyển cần được lựa chọn dựa trên mục tiêu kinh doanh và yêu cầu kỹ thuật.

Nói cách khác, migration không chỉ là vấn đề của riêng bộ phận IT, mà còn là một bài toán quản trị liên quan đến vận hành doanh nghiệp và quyết định đầu tư trong tương lai.

Khi cân nhắc migration, ba phương án thường được so sánh là rehost, rewrite và rebuild. Mỗi phương án khác nhau về mục tiêu, mức độ linh hoạt, thời gian triển khai và chi phí.

Rehost

Rehost là phương pháp chuyển nền tảng vận hành sang môi trường mới mà không thay đổi lớn đối với ứng dụng. Đây là cách tiếp cận gần với khái niệm “Lift and Shift”, với đặc điểm là dễ triển khai chuyển đổi trong thời gian ngắn.

Ví dụ, trường hợp chuyển một hệ thống hiện có đang chạy trên máy chủ on-premises sang môi trường ảo hóa hoặc cloud IaaS thuộc nhóm này.

Phù hợp trong các trường hợp:

Lưu ý:

• Các vấn đề nội tại của ứng dụng thường vẫn còn tồn tại
• Dễ trì hoãn việc xử lý nợ kỹ thuật
• Nếu cần làm mới lại trong vài năm tới, doanh nghiệp dễ phải đầu tư hai lần

Rewrite

Rewrite là phương pháp viết lại chương trình hoặc một phần cấu trúc để phù hợp với ngôn ngữ và môi trường mới, trong khi không thay đổi đáng kể các chức năng nghiệp vụ. Ví dụ, đây có thể là trường hợp tái triển khai một hệ thống nghiệp vụ được xây dựng bằng ngôn ngữ phát triển cũ trên nền tảng phát triển hiện tại.

Phù hợp trong các trường hợp:

Lưu ý:

• Ngay cả khi giao diện trông tương tự, khối lượng làm lại cũng không hề nhỏ
• Nếu yêu cầu kỹ thuật không rõ ràng, chất lượng viết lại dễ bị suy giảm
• Khối lượng kiểm thử dễ tăng lên

Rebuild

Rebuild là phương pháp tái xây dựng hệ thống dựa trên hệ thống hiện tại, đồng thời đáp ứng các yêu cầu mới và kiến trúc mới. Phương pháp này có mức độ linh hoạt cao, dễ phù hợp với việc khai thác cloud và thiết kế nghiệp vụ mới, nhưng thường đòi hỏi nhiều thời gian và chi phí hơn.

Phù hợp trong các trường hợp:

Lưu ý:

• Nếu việc làm rõ yêu cầu chưa đầy đủ, kế hoạch rất dễ bị phình to
• Cần thiết kế quá trình chuyển đổi bao gồm cả việc triển khai ổn định tại hiện trường
• Mất nhiều thời gian để sắp xếp việc di chuyển dữ liệu, phân quyền và tích hợp với các hệ thống liên quan

Đâu là phương pháp phù hợp không chỉ phụ thuộc vào tình trạng hệ thống, mà còn phụ thuộc vào điều doanh nghiệp ưu tiên. Nếu mục tiêu là chuyển đổi ổn định trong ngắn hạn, phương pháp lựa chọn sẽ khác với trường hợp cần rà soát lại cả khả năng mở rộng trong tương lai.

Theo cách phân loại của Microsoft, Rehost là phương án di chuyển rủi ro thấp, giúp hạn chế gián đoạn; Replatform là cách giảm tải vận hành với những thay đổi tối thiểu; còn Rebuild là lựa chọn khi cần một giải pháp cloud-native mới đáp ứng yêu cầu. Điều quan trọng không phải là quyết định dựa trên thuật ngữ kỹ thuật, mà là lựa chọn theo mức độ ưu tiên của doanh nghiệp và các ràng buộc tại hiện trường.

Trên thực tế, nhiều dự án không thể hoàn tất chỉ bằng một phương pháp duy nhất. Chẳng hạn, doanh nghiệp có thể triển khai theo từng giai đoạn: trước tiên giảm rủi ro về nền tảng bằng rehost, sau đó chỉ rewrite hoặc rebuild các chức năng quan trọng.

Cách triển khai này mang lại những lợi ích sau.

• Dễ hạn chế tác động đến nghiệp vụ vì không cần đổi mới toàn bộ cùng một lúc
• Dễ phân bổ ngân sách theo nhiều giai đoạn
• Có thể điều chỉnh thứ tự ưu tiên dựa trên tình hình vận hành hiện tại

Mặt khác, khi chia thành nhiều giai đoạn, định hướng thiết kế dễ bị thiếu nhất quán. Vì vậy, cần thống nhất kiến trúc tổng thể và chính sách dữ liệu ngay từ đầu.

Khi triển khai migration, nhiều doanh nghiệp thường gặp khó khăn ngay từ bước nắm bắt hiện trạng, trước cả khi lựa chọn phương pháp.

1. Không nắm rõ thông số kỹ thuật hiện tại

Ở các hệ thống cũ, thường dễ xảy ra tình trạng tài liệu thiết kế không còn được cập nhật, quy tắc nghiệp vụ bị ẩn trong mã nguồn hoặc chỉ nhân sự phụ trách mới hiểu rõ. Những vấn đề này có thể dẫn đến sai lệch trong ước tính và phát sinh việc phải làm lại.

2. Khối lượng kiểm thử lớn hơn dự kiến

Sau khi chuyển đổi, chỉ “chạy được” là chưa đủ. Cần xác nhận liệu hệ thống có cho ra kết quả giống với nghiệp vụ hiện tại hay không, các kết nối với hệ thống liên quan có gặp vấn đề không, và cả cách xử lý các trường hợp ngoại lệ. Đặc biệt với các hệ thống lõi, khối lượng kiểm thử so sánh và xác nhận nghiệm thu thường sẽ lớn hơn.

3. Dự án dễ bị kéo dài

Phạm vi triển khai càng rộng thì càng dễ chịu tác động từ các yếu tố bên ngoài như yêu cầu bổ sung, thay đổi quy định hoặc chỉnh sửa các hệ thống liên quan. Kết quả là tiến độ dễ bị kéo dài và chi phí cũng dễ tăng lên.

4. Khác biệt trong nhận thức với bộ phận nghiệp vụ

Bộ phận IT thường chú trọng đổi mới công nghệ, trong khi các bộ phận nghiệp vụ ưu tiên duy trì hoạt động hằng ngày. Nếu không xử lý sự khác biệt trong nhận thức này, sau khi di chuyển rất dễ phát sinh các vấn đề như “khó sử dụng” hoặc “không đúng như kỳ vọng”.

Để migration thành công, cách triển khai quan trọng hơn bản thân phương pháp. Đặc biệt, quy trình sau đây là những bước nền tảng khó có thể bỏ qua.

1. Thực hiện khảo sát hiện trạng một cách kỹ lưỡng

Cần rà soát đầy đủ tài sản hiện có, quy trình nghiệp vụ, các tích hợp liên quan, cấu trúc dữ liệu và cả vai trò của người phụ trách vận hành. Hệ thống càng có nhiều phần chưa được làm rõ, thì càng đáng đầu tư thời gian cho khảo sát ban đầu.

2. Xác định rõ mức độ ưu tiên

Hãy xác định điều gì cần được ưu tiên cao nhất, chẳng hạn như “ổn định trong ngắn hạn”, “tối ưu hóa chi phí”, “nâng cao khả năng mở rộng” hoặc “cải cách nghiệp vụ”. Nếu thứ tự ưu tiên không rõ ràng, cả phương pháp lẫn phạm vi triển khai đều dễ bị thay đổi thiếu nhất quán.

3. Kiểm chứng ở quy mô nhỏ

Trước khi triển khai trên toàn bộ hệ thống, việc kiểm chứng trước với một số chức năng hoặc một phần hệ thống là một phương án hiệu quả. Cách này giúp xác nhận sớm khả năng chuyển đổi, hiệu năng, tính nhất quán của dữ liệu và phương pháp kiểm thử.

4. Lập kế hoạch kiểm thử trước

Trong các dự án chuyển đổi, nếu đến giai đoạn cuối phát triển mới tính đến kiểm thử thì rất dễ bị chậm tiến độ. Điều quan trọng là cần sớm xác định tiêu chí thành công, cách so sánh giữa hệ thống hiện tại và hệ thống mới, cũng như ai sẽ là người nghiệm thu.

5. Xác định triển khai theo từng giai đoạn ngay từ đầu

Khi khó chuyển đổi đồng loạt, cách thực tế hơn là chuyển đổi theo từng giai đoạn, bắt đầu từ những phạm vi ít ảnh hưởng đến nghiệp vụ. Việc xác định trước các điều kiện quay lại trạng thái cũ cũng giúp ra quyết định dễ dàng hơn.

Trong migration, thành công không chỉ phụ thuộc vào việc lựa chọn công nghệ, mà còn được quyết định bởi mức độ thấu hiểu nghiệp vụ, kế hoạch triển khai theo từng giai đoạn và năng lực đảm bảo chất lượng. SMILE hỗ trợ triển khai từng bước, từ việc hệ thống hóa các vấn đề nghiệp vụ, xem xét phương án số hóa, cho đến phát triển và vận hành hệ thống.

Ví dụ, doanh nghiệp có thể cân nhắc các hình thức hỗ trợ sau.

Điều quan trọng không phải là tái xây dựng quy mô lớn ngay từ đầu, mà là triển khai từng bước theo thứ tự phù hợp với doanh nghiệp của mình.

Q1. Migration và modernization có giống nhau không?

Hai thuật ngữ này đôi khi được dùng với cùng một nghĩa, nhưng về mặt chính xác vẫn có khác biệt nhất định. Migration thường chỉ bản thân quá trình chuyển đổi, trong khi modernization có thể bao gồm cả việc hiện đại hóa vận hành và cấu trúc hệ thống bên cạnh quá trình chuyển đổi.

Q2. Nếu phải chọn trước, rehost có phải là phương án an toàn không?

Đây là phương pháp dễ triển khai chuyển đổi trong ngắn hạn, nhưng các vấn đề của ứng dụng hiện tại có thể vẫn còn tồn tại. Nếu dự kiến sẽ phải làm mới lại trong vài năm tới, việc so sánh với các phương pháp khác ngay từ đầu sẽ hiệu quả hơn.

Q3. Rebuild có nhất thiết luôn tốn kém không?

Nhìn chung, phương án này thường đòi hỏi chi phí và thời gian lớn hơn, nhưng nếu hệ thống hiện tại có nhiều ràng buộc, tổng chi phí đôi khi có thể thấp hơn so với việc liên tục thực hiện các cải tiến từng phần.