Lift-and-shift vs re-platform: 2 chiến lược migrate lên cloud

"Bê nguyên hệ thống lên cloud là xong, nhanh gọn" — hay "tranh thủ cải tiến kiến trúc luôn cho đáng công migrate"? Đây là ngã rẽ đầu tiên và quan trọng nhất của mọi dự án chuyển đổi lên cloud, và chọn sai ở đây thì trả giá bằng tháng ngày vật vã sau đó: hệ thống "bê nguyên" lên cloud chạy đắt gấp đôi mà chẳng nhanh hơn, hoặc dự án "cải tiến" kéo dài 8 tháng vẫn chưa xong vì đụng đâu sửa đó. Lift-and-shift vs re-platform là hai chiến lược migrate phổ biến nhất — hiểu đúng bản chất, chi phí và rủi ro của từng hướng sẽ giúp bạn chọn đúng ngay từ đầu.

Bài viết so sánh chi tiết hai chiến lược, đưa ra khung quyết định theo từng loại hệ thống, và những bài học thực tế từ các dự án migrate của doanh nghiệp Việt Nam.

Lift and shift vs replatform: lift-and-shift là gì? Re-platform là gì?

Lift-and-shift (nâng và đặt — còn gọi là rehosting) là chiến lược migrate giữ nguyên kiến trúc ứng dụng, chỉ chuyển nơi chạy từ server vật lý/on-prem sang cloud. Một máy chủ vật lý chạy Windows + SQL Server được "bê" thành một VM tương đương trên cloud, cấu hình y hệt, ứng dụng không đổi một dòng code. Nhanh, ít rủi ro kỹ thuật, nhưng cũng ít tận dụng được lợi thế của cloud.

Re-platform (tái định vị nền tảng — còn gọi là "lift-tinker-and-shift") là migrate có điều chỉnh: giữ nguyên lõi ứng dụng nhưng thay đổi một số thành phần để phù hợp cloud hơn. Ví dụ: giữ nguyên code nhưng chuyển database tự quản sang dịch vụ database có quản lý (managed DB), chuyển file lưu local sang object storage, hoặc container hóa ứng dụng để dễ scale. Tốn công hơn lift-and-shift nhưng khai thác được nhiều lợi ích cloud hơn.

Để dễ hình dung: lift-and-shift như chuyển nhà — bê nguyên đồ đạc sang nhà mới, kể cả cái tủ đã ọp ẹp. Re-platform như chuyển nhà kèm "tân trang": vẫn là đồ của mình nhưng thay cái tủ hỏng, lắp thêm điều hòa cho hợp nhà mới.

(Còn một chiến lược thứ ba là re-architect/refactor — viết lại kiến trúc theo hướng cloud-native/microservices. Mạnh nhất nhưng tốn kém và rủi ro nhất, thường chỉ dành cho hệ thống lõi cần hiện đại hóa sâu — ngoài phạm vi so sánh của bài này.)

Lift and shift vs replatform: so sánh lift-and-shift vs re-platform

Quy luật đánh đổi cốt lõi: lift-and-shift thắng ở tốc độ và độ an toàn, re-platform thắng ở hiệu quả dài hạn. Không có chiến lược nào "đúng" tuyệt đối — chỉ có chiến lược phù hợp với từng hệ thống và bối cảnh.

Lift and shift vs replatform: khi nào nên chọn lift-and-shift?

Lift-and-shift là lựa chọn đúng trong 5 tình huống:

1. Deadline gấp — datacenter cũ sắp "chết". Hợp đồng thuê chỗ đặt máy chủ hết hạn, phòng server ngập nước, hoặc phần cứng quá cũ không còn linh kiện thay. Khi thời gian là tất cả, bê nguyên lên cloud trong 2–4 tuần rồi tối ưu sau là phương án khôn ngoan.

2. Hệ thống legacy ít tài liệu. Ứng dụng cũ 10 năm, người viết đã nghỉ, không ai dám đụng vào code. Lift-and-shift không động đến ứng dụng nên rủi ro gần như bằng không — "đừng sửa cái đang chạy".

3. Mục tiêu ban đầu chỉ là "thoát khỏi phần cứng". Ban lãnh đạo chỉ cần hết gánh nặng bảo trì server vật lý, chưa đặt mục tiêu tối ưu chi phí cloud. Migrate nhanh, ổn định, rồi tính tiếp.

4. Làm bước đệm cho hiện đại hóa sau. Chiến lược "migrate trước, tối ưu sau" rất phổ biến: bê lên cloud cho chạy ổn định 3–6 tháng, có số liệu thực tế, rồi mới re-platform từng phần. An toàn hơn làm một lèo.

5. Workload ổn định, ít biến động. Hệ thống chạy đều 24/7, không cần auto-scale, không cần tính năng cloud đặc biệt — lift-and-shift lên VM cloud cho chi phí dễ dự toán, vận hành quen thuộc.

Cái giá của lift-and-shift: hệ thống bê nguyên thường chạy đắt hơn 20–40% so với on-prem nếu không tối ưu sau đó — vì bạn trả giá cloud cho kiến trúc thiết kế theo kiểu "mua đứt phần cứng" (server luôn bật full, storage dư thừa, không dùng được giảm giá cam kết). Lift-and-shift mà dừng lại ở đó thì chỉ là "đổi chỗ đắt hơn".

Khi nào nên chọn re-platform?

Re-platform xứng đáng với công sức bỏ thêm trong các trường hợp:

1. Database là điểm nghẽn vận hành. SQL Server/MySQL tự quản tốn công backup, patch, HA. Chuyển sang managed database (RDS, Cloud SQL hoặc dịch vụ tương đương) — team trút được gánh nặng vận hành lớn nhất, đổi lại là chi phí dịch vụ cao hơn một chút nhưng ổn định hơn nhiều.

2. Lưu trữ file tăng trưởng nhanh. Ứng dụng lưu file trên ổ local của server — lên cloud thì chuyển sang object storage (S3-tương thích). Rẻ hơn, bền hơn (replication tự động), và là tiền đề để scale nhiều server sau này.

3. Cần khả năng co giãn (scale). Hệ thống TMĐT mùa sale, tuyển sinh, khai thuế — lưu lượng gấp 5–10 lần ngày thường. Re-platform để tách tầng stateless, đưa vào auto-scaling group hoặc container — điều lift-and-shift thuần không làm được.

4. Muốn giảm gánh vận hành dài hạn. Mỗi thành phần chuyển sang managed service là một việc ít phải trực đêm hơn: hết lo patch OS database, hết lo disk đầy vì log, hết lo backup thủ công. Với team IT 1–2 người, giá trị này rất lớn.

5. Có thời gian và ngân sách cho dự án 2–4 tháng. Re-platform cần test kỹ từng thay đổi — không dành cho deadline "tuần sau phải xong".

Nguyên tắc vàng của re-platform: mỗi lần chỉ thay đổi một thành phần và kiểm thử kỹ trước khi sang thành phần tiếp theo. Đổi database + đổi cách lưu file + container hóa cùng lúc mà sự cố thì không biết lỗi từ đâu.

Các thay đổi re-platform phổ biến nhất

Dưới đây là 6 "món" re-platform hay gặp, xếp theo độ khó tăng dần:

Với SME, combo "lift-and-shift + chuyển DB sang managed + file sang object storage" đã giải quyết 80% vấn đề với 20% công sức — được gọi vui là "re-platform nhẹ".

Khung quyết định: chọn chiến lược theo từng hệ thống

Đừng chọn một chiến lược cho cả công ty. Đánh giá từng hệ thống theo 5 câu hỏi:

1. Hệ thống có thay đổi trong 2 năm tới không? Không (legacy ổn định) → lift-and-shift. Có (đang phát triển) → re-platform để khỏi làm hai lần.

2. Database có phải gánh nặng không? Team mất nhiều giờ/tuần cho DB → re-platform DB sang managed. DB nhỏ, ít việc → giữ nguyên.

3. Có cần chịu tải đỉnh không? Có (sale, mùa vụ) → re-platform hướng scale. Không → lift-and-shift đủ.

4. Deadline thế nào? Dưới 1 tháng → lift-and-shift, không bàn cãi. Trên 3 tháng → cân nhắc re-platform.

5. Team có kỹ năng cloud không? Chưa → lift-and-shift trước, học dần. Có → re-platform ngay từ đầu.

Ma trận quyết định nhanh:

Chi phí thực tế: so sánh 3 năm

Lấy ví dụ một hệ thống web + database vừa (minh họa):

Nhận xét: lift-and-shift đắt hơn on-prem nếu dừng lại ở đó — đây là "cú sốc hóa đơn" nhiều doanh nghiệp gặp phải và đổ lỗi cho cloud. Re-platform nhẹ tốn dự án ban đầu nhưng tổng 3 năm rẻ nhất nhờ giảm nhân công vận hành và tối ưu tài nguyên. Bài học: đừng đánh giá migrate bằng chi phí tháng đầu, hãy nhìn tổng 3 năm.

Bài học từ dự án migrate thực tế

Bài học 1: Kiểm kê đầy đủ trước khi migrate. 70% dự án chậm tiến độ vì "phát hiện thêm" hệ thống phụ thuộc lúc đang làm: con VM quên tắt 2 năm vẫn chạy cron quan trọng, database có job chạy đêm không ai nhớ. Dành 2 tuần chỉ để kiểm kê và vẽ sơ đồ phụ thuộc — rẻ hơn nhiều so với rollback giữa chừng.

Bài học 2: Migrate thử với hệ thống ít quan trọng nhất. Đừng bắt đầu bằng ERP. Chọn website công ty hoặc hệ thống nội bộ ít người dùng — team học được quy trình, công cụ, và "đau" ở chỗ ít nguy hiểm nhất.

Bài học 3: Giữ hệ thống cũ chạy song song ít nhất 2 tuần. Đừng tắt server cũ ngay khi hệ thống mới "có vẻ chạy được". Chạy song song (với đồng bộ dữ liệu) là phao cứu sinh khi phát hiện lỗi chỉ xuất hiện dưới tải thật.

Bài học 4: Đo hiệu năng trước và sau. Chụp baseline: thời gian phản hồi, throughput, tỷ lệ lỗi của hệ thống cũ. Sau migrate so sánh — nếu chậm hơn 10% thì phải điều tra trước khi coi như xong. "Chạy được" khác với "chạy tốt".

Bài học 5: Tính toán license khi đổi nền tảng. Chuyển Windows sang Linux, SQL Server sang PostgreSQL trong lúc re-platform có thể tiết kiệm license lớn — nhưng cũng là thay đổi rủi ro cao. Tách riêng thành giai đoạn 2, đừng gộp vào dự án migrate.

Kết luận

Lift-and-shift thắng ở tốc độ và an toàn — lựa chọn đúng khi deadline gấp, hệ thống legacy, hoặc cần "thoát phần cứng" nhanh. Re-platform thắng ở hiệu quả dài hạn — xứng đáng khi database là gánh nặng, cần scale, hoặc team đã sẵn sàng. Và chiến lược khôn ngoan nhất với nhiều doanh nghiệp là kết hợp: lift-and-shift trước cho chạy ổn định, rồi re-platform từng phần theo thứ tự ưu tiên.

Dù chọn hướng nào, thành công của migrate nằm ở khâu chuẩn bị: kiểm kê đầy đủ, migrate thử hệ thống nhỏ trước, chạy song song, và đo lường sau triển khai. Làm tốt bốn việc này, dự án migrate của bạn đã nắm 80% chắc thắng.

SunCloud đồng hành cùng doanh nghiệp trong mọi chiến lược migrate: Cloud Server linh hoạt cho lift-and-shift nhanh, các dịch vụ managed và đội ngũ kỹ thuật hỗ trợ re-platform, cùng chính sách dùng thử 10 ngày để kiểm chứng trước khi quyết định. Liên hệ hotline 083 979 3434 hoặc truy cập suncloud.vn để được tư vấn lộ trình migrate phù hợp.

Câu hỏi thường gặp

Có thể lift-and-shift trước rồi re-platform sau không?

Được, và đây là chiến lược được khuyến nghị cho nhiều doanh nghiệp. Bê nguyên lên cloud cho chạy ổn định 3–6 tháng, thu thập số liệu thực tế, rồi re-platform từng thành phần theo thứ tự ưu tiên. Cách này chia rủi ro thành nhiều phần nhỏ, dễ quản lý.

Re-platform có làm gián đoạn dịch vụ không?

Nếu làm đúng thì không (hoặc downtime rất ngắn). Bí quyết: mỗi thay đổi triển khai song song — dựng thành phần mới, đồng bộ dữ liệu, kiểm thử kỹ, rồi mới chuyển traffic qua (blue-green). Đừng "đập đi xây lại" trực tiếp trên hệ thống đang chạy.

Hệ thống dùng Windows + SQL Server có re-platform được không?

Được, nhưng phạm vi hẹp hơn. Có thể chuyển SQL Server sang managed database tương thích, file sang object storage. Việc chuyển hẳn sang Linux/PostgreSQL để tiết kiệm license là một dự án riêng, rủi ro cao hơn nhiều — nên tách ra.

Migrate mất bao lâu?

Lift-and-shift một hệ thống vừa: 2–4 tuần. Re-platform nhẹ: 2–3 tháng. Con số này chưa tính giai đoạn kiểm kê (2 tuần) và chạy song song (2–4 tuần). Dự án migrate ERP lớn cho doanh nghiệp vừa thường kéo dài 4–8 tháng tổng thể.

Chi phí migrate thường bị đánh giá thấp ở khoản nào?

Ba khoản hay bị quên: băng thông truyền dữ liệu lần đầu (có thể hàng chục TB); nhân công làm thêm giờ của team trong giai đoạn chạy song song; và chi phí license tạm thời khi cả hai hệ thống cùng chạy. Cộng thêm 20–30% dự phòng vào dự toán.

Khi nào nên thuê đơn vị ngoài làm migrate?

Khi team nội bộ chưa từng migrate, hệ thống phức tạp nhiều phụ thuộc, hoặc deadline gấp mà team đang quá tải vận hành hàng ngày. Đơn vị có kinh nghiệm giúp tránh các bẫy phổ biến — chi phí thuê thường rẻ hơn chi phí của một lần migrate thất bại phải làm lại.