Lộ trình 30 ngày đổi sang SaaS mã nguồn mở không gián đoạn

Lộ trình 30 ngày chuyển đổi sang open source SaaS alternative không gián đoạn

Doanh nghiệp dùng SaaS vì nhanh: đăng ký, trả tiền, chạy. Nhưng sau vài năm, chi phí tăng, dữ liệu bị khóa, quyền kiểm soát giảm, quy trình phụ thuộc vendor. Khi đó, open source SaaS alternative trở thành lựa chọn đáng cân nhắc: tự host, kiểm soát dữ liệu, tùy biến sâu, tránh lock-in.

Vấn đề: chuyển đổi sai cách → gián đoạn vận hành, mất dữ liệu, người dùng phản kháng, đội IT quá tải. Vì vậy, mục tiêu không phải “chuyển thật nhanh”, mà là chuyển có kiểm soát, đo được, rollback được.

Dưới đây là lộ trình 30 ngày thực tế để thay thế SaaS thương mại bằng giải pháp open source tương đương mà không làm đứt mạch công việc.

Nguyên tắc trước khi bắt đầu

Không thay mọi thứ cùng lúc

Đừng chuyển CRM, chat, email marketing, project management, helpdesk trong một đợt. Rủi ro cộng dồn rất lớn.

Chọn một hệ thống SaaS có phạm vi rõ, ví dụ:

– Notion → AppFlowy / Outline – Slack → Mattermost / Zulip / Rocket.Chat – Trello / Asana → Plane / OpenProject – Airtable → NocoDB / Baserow – Zendesk → Zammad / FreeScout – Google Analytics → Matomo / Plausible self-hosted

Ưu tiên công cụ có:

– Dữ liệu xuất được. – Ít tích hợp phức tạp. – Nhóm người dùng nhỏ nhưng đại diện. – Tác động kinh doanh vừa phải.

“Không gián đoạn” nghĩa là gì?

Không gián đoạn không có nghĩa là không ai thấy thay đổi. Nó nghĩa là:

– Dữ liệu quan trọng không mất. – Người dùng vẫn làm việc được. – Có kế hoạch rollback. – Có thời gian chạy song song. – Có người hỗ trợ trong giai đoạn chuyển. – Không cutover vào ngày cao điểm.

Open source không đồng nghĩa miễn phí

Bạn có thể tiết kiệm license SaaS, nhưng sẽ phát sinh:

– Hosting. – Backup. – Monitoring. – Bảo mật. – Nâng cấp. – Thời gian vận hành.

Vì vậy, hãy tính TCO: tổng chi phí sở hữu, không chỉ phí phần mềm.

Tuần 1: Đánh giá, chọn giải pháp, chốt phạm vi

Ngày 1-2: Kiểm kê SaaS hiện tại

Lập bảng đơn giản:

Kết quả cần có: bản đồ phụ thuộc. Đây là thứ quyết định chuyển đổi dễ hay khó.

Ngày 3: Chọn ứng viên open source

Đánh giá theo checklist:

– Dự án còn hoạt động không? – Release gần nhất khi nào? – Có Docker image chính thức không? – Có tài liệu backup/restore không? – Có phân quyền không? – Có API không? – Có SSO/LDAP/OIDC nếu cần không? – Có cộng đồng, issue tracker, bản enterprise tùy chọn không? – License có phù hợp không?

Không chọn chỉ vì giao diện đẹp. Chọn vì dễ vận hành, dễ cứu khi lỗi, dễ thoát nếu cần.

Ngày 4-5: Dựng môi trường thử nghiệm

Dùng cách đơn giản nhất:

– Docker Compose nếu team nhỏ. – VM riêng nếu cần tách biệt. – Managed PostgreSQL/MySQL nếu muốn giảm vận hành DB. – Reverse proxy với TLS. – Backup ngay từ đầu.

Mục tiêu chưa phải production hoàn hảo. Mục tiêu là trả lời:

– App chạy ổn không? – Import dữ liệu được không? – Quy trình chính làm được không? – Performance đủ không?

Ngày 6-7: Chốt phạm vi MVP

Viết rõ:

Sẽ chuyển:

– Dữ liệu nào. – Nhóm người dùng nào. – Quy trình nào. – Tích hợp nào.

Chưa chuyển:

– Tính năng phụ. – Báo cáo ít dùng. – Automation không quan trọng. – Customization “để sau”.

Đây là bước chống phình phạm vi. Không có nó, 30 ngày sẽ thành 90 ngày.

Tuần 2: Chuẩn bị hạ tầng, bảo mật, dữ liệu

Ngày 8-9: Thiết kế kiến trúc tối thiểu

Một kiến trúc tốt cho giai đoạn đầu:

– App container. – DB riêng. – Volume/persistent storage. – Reverse proxy. – TLS. – Backup tự động. – Monitoring cơ bản. – Log tập trung mức tối thiểu.

Không cần Kubernetes nếu chỉ có một app nhỏ. Không cần service mesh. Không cần HA phức tạp nếu downtime vài phút chấp nhận được. Nhưng backup và restore thì bắt buộc.

Ngày 10: Chính sách truy cập

Thiết lập:

– Admin ít nhất có 2 người. – Không dùng chung tài khoản admin. – Bật MFA nếu có. – SSO nếu tổ chức đã có IdP. – Phân quyền theo nhóm. – Tắt đăng ký tự do nếu app public internet. – Kiểm tra quyền guest/external user.

Sai phân quyền là lỗi phổ biến khi tự host. SaaS thường mặc định an toàn hơn. Self-host thì bạn phải tự chịu trách nhiệm.

Ngày 11-12: Xuất dữ liệu từ SaaS cũ

Ưu tiên export chính thức:

– CSV cho bảng. – JSON cho cấu trúc phức tạp. – File đính kèm tải riêng. – Metadata như owner, timestamp, status. – Danh sách user/group. – Audit log nếu cần compliance.

Lưu bản export ở nơi an toàn. Ghi lại:

– Thời điểm export. – Ai export. – Tổng số record. – Hash/checksum nếu dữ liệu quan trọng. – Cấu trúc file.

Đây là “bảo hiểm” nếu import lỗi.

Ngày 13-14: Import thử và đối soát

Import vào môi trường staging. Sau đó kiểm tra:

– Số lượng bản ghi. – File đính kèm. – Quan hệ giữa dữ liệu. – Quyền truy cập. – Link nội bộ. – Ký tự tiếng Việt. – Timezone. – Trạng thái workflow.

Tạo một bảng đối soát đơn giản:

| Loại dữ liệu | SaaS cũ | Hệ mới | Lệch | |—|—:|—:|—:| | User | 120 | 120 | 0 | | Project | 45 | 45 | 0 | | Task | 8.230 | 8.198 | 32 | | Attachment | 1.400 | 1.400 | 0 |

Không cần hoàn hảo tuyệt đối cho mọi metadata, nhưng phải biết rõ cái gì mất, cái gì giữ.

Tuần 3: Pilot có kiểm soát

Ngày 15: Chọn nhóm pilot

Chọn 5-15% người dùng, gồm:

– Người dùng thường xuyên. – Một power user. – Một người ít kỹ thuật. – Một trưởng nhóm có quyền quyết định. – Một người từ IT/support.

Không chọn toàn người “dễ tính”. Pilot cần phát hiện vấn đề thật.

Ngày 16: Đào tạo ngắn, đúng việc

Đừng tổ chức buổi training 3 giờ. Làm tài liệu ngắn:

– Cách đăng nhập. – 5 thao tác hay dùng nhất. – Điểm khác so với SaaS cũ. – Cách báo lỗi. – Quy tắc dùng trong tuần pilot.

Một video 5 phút + checklist là đủ cho phần lớn trường hợp.

Ngày 17-20: Chạy song song

Trong giai đoạn pilot:

– Hệ cũ vẫn là nguồn chính. – Hệ mới dùng cho nhóm pilot hoặc dữ liệu mẫu/thật có kiểm soát. – Ghi nhận lỗi hằng ngày. – Không sửa tùy biến lớn ngay. – Phân loại issue: blocker, quan trọng, khó chịu, nice-to-have.

Ví dụ phân loại:

– Blocker: không đăng nhập, mất dữ liệu, không gửi notification. – Quan trọng: import thiếu field cần cho báo cáo. – Khó chịu: UI nhiều bước hơn. – Nice-to-have: đổi màu, thêm shortcut.

Chỉ blocker và lỗi quan trọng được xử lý trước cutover.

Ngày 21: Quyết định go/no-go

Chỉ go nếu:

– Import đạt mức chấp nhận. – Backup/restore đã test. – Nhóm pilot hoàn thành việc chính. – Không còn blocker. – Có người trực hỗ trợ ngày cutover. – Rollback plan rõ.

Nếu chưa đạt, kéo dài pilot. Đừng cố chuyển chỉ vì “đã lên lịch”.

Tuần 4: Cutover, ổn định, tối ưu

Ngày 22-23: Chuẩn bị cutover

Thông báo trước cho người dùng:

– Thời điểm đóng băng dữ liệu. – Thời điểm chuyển hệ mới. – Việc người dùng cần làm. – Link hệ mới. – Kênh hỗ trợ. – Hạn chế trong 24-48 giờ đầu.

Chọn thời điểm ít rủi ro:

– Cuối ngày làm việc. – Cuối tuần nếu đội support sẵn sàng. – Tránh kỳ chốt sale, chạy campaign, deadline tài chính.

Ngày 24: Đóng băng dữ liệu

Tùy SaaS, có thể:

– Chuyển hệ cũ sang read-only. – Tạm dừng tạo mới. – Export lần cuối. – Đồng bộ delta từ lần export trước. – Ghi lại mốc thời gian cutover.

Không cho vừa sửa hệ cũ vừa sửa hệ mới nếu chưa có cơ chế sync hai chiều. Đây là nguồn mất dữ liệu phổ biến.

Ngày 25: Import cuối và kiểm tra

Sau import cuối:

– Đếm record. – Kiểm tra user quan trọng. – Mở file đính kèm mẫu. – Kiểm tra permission. – Gửi notification thử. – Kiểm tra backup sau cutover. – Kiểm tra dashboard/log.

Chỉ mở cho toàn bộ người dùng khi checklist đạt.

Ngày 26: Mở hệ mới

Trong ngày đầu:

– Có kênh hỗ trợ riêng. – Có người trực xử lý quyền truy cập. – Ghi issue công khai. – Cập nhật FAQ liên tục. – Không nâng cấp version ngay. – Không đổi cấu hình lớn nếu không cần.

Mục tiêu ngày đầu: ổn định, không tối ưu.

Ngày 27-28: Theo dõi và sửa lỗi

Theo dõi:

– Lỗi đăng nhập. – Hiệu năng. – Dung lượng disk. – CPU/RAM. – Lỗi DB. – Email notification. – Backup job. – Log 500/timeout.

Hỏi người dùng 3 câu:

1. Việc chính có làm được không? 2. Chỗ nào chậm hoặc khó hơn trước? 3. Nếu quay lại SaaS cũ, lý do là gì?

Câu 3 giúp tìm vấn đề thật, không phải góp ý bề mặt.

Ngày 29: Khóa hệ cũ, giữ bản lưu

Không xóa SaaS cũ ngay. Làm theo thứ tự:

– Giữ read-only 2-4 tuần. – Tải toàn bộ export cuối. – Lưu hóa đơn/license nếu cần audit. – Thu hồi token/API key không dùng. – Tắt integration cũ. – Lên lịch hủy subscription sau giai đoạn an toàn.

Nếu SaaS tính phí theo tháng, đừng tiếc vài ngày. Chi phí nhỏ hơn nhiều so với mất dữ liệu.

Ngày 30: Tổng kết và chuẩn hóa

Tạo báo cáo ngắn:

– Mục tiêu ban đầu. – Kết quả đạt được. – Sự cố đã gặp. – Dữ liệu đã chuyển. – Chi phí mới. – Việc còn nợ. – Quy trình backup/restore. – Chủ sở hữu hệ thống.

Đây là tài liệu nền cho lần chuyển đổi tiếp theo.

Checklist tối thiểu để không gián đoạn

Trước khi cutover, phải có:

– Backup tự động. – Restore đã thử ít nhất một lần. – Export cuối từ SaaS cũ. – Đối soát dữ liệu. – Danh sách admin và owner. – Kênh hỗ trợ người dùng. – Kế hoạch rollback. – Thông báo người dùng. – Hệ cũ read-only trong thời gian chuyển. – Monitoring/log cơ bản.

Thiếu một trong các mục trên → chưa nên go-live.

Kết luận thực tế

Chuyển sang open source SaaS alternative không phải dự án “cài phần mềm thay phần mềm”. Nó là dự án dữ liệu, vận hành, bảo mật, con người.

Lộ trình 30 ngày khả thi nếu bạn giữ phạm vi nhỏ, chạy pilot, test restore, đối soát dữ liệu, truyền thông rõ, cutover có kiểm soát. Đừng cố biến lần đầu thành cuộc cách mạng toàn công ty. Hãy chọn một SaaS, chuyển tốt, rút kinh nghiệm, rồi nhân rộng.

Cách chuyển đổi tốt nhất là cách người dùng gần như không phải hỏi: “Hôm nay hệ thống có bị đổi không?” Họ chỉ mở link mới, đăng nhập, tiếp tục làm việc. Open source khi đó không còn là khẩu hiệu tiết kiệm chi phí, mà là năng lực kiểm soát hạ tầng số của chính doanh nghiệp.