Mở đầu — vì sao bài này quan trọng
Ngày 15/02/2024, Atlassian chính thức "khai tử" dòng sản phẩm Jira Server (end-of-life). Nghĩa là gì? Nghĩa là kể từ mốc đó, không còn bản vá bảo mật, không còn hỗ trợ kỹ thuật, không còn mua thêm license mới cho phiên bản Server. Nếu công ty bạn vẫn đang chạy một con Jira cài trên máy chủ vật lý đặt trong phòng server, hay trên một VPS thuê ngoài, thì về mặt kỹ thuật bạn đang chạy một hệ thống "hết bảo hành" — mỗi lỗ hổng bảo mật mới phát hiện đều là một quả bom hẹn giờ.
Atlassian đưa ra hai lối thoát: chuyển sang Cloud (Jira do Atlassian vận hành, bạn chỉ việc dùng) hoặc chuyển sang Data Center (bản self-hosted quy mô lớn, đắt hơn nhiều, thường chỉ dành cho tổ chức từ vài nghìn user trở lên hoặc có ràng buộc pháp lý bắt buộc dữ liệu phải nằm trong nội bộ).
Với đại đa số công ty ở Việt Nam và Đông Nam Á — startup, agency, team sản phẩm vài chục đến vài trăm người — con đường thực tế là Server → Cloud. Và đây chính là chỗ nhiều PM bị bất ngờ: họ tưởng migration là việc của IT/DevOps, "cắm điện là xong". Thực tế, migration là một dự án có rủi ро cao, đụng chạm trực tiếp đến dữ liệu công việc của cả team, và PM thường là người phải điều phối, kiểm thử nghiệm thu và truyền thông cho toàn đội.
Bài này giúp bạn hiểu bức tranh migration đủ sâu để không bị động: bạn sẽ biết chọn công cụ nào, chuẩn bị gì, những cái gì "không đi theo" sang Cloud, và cách tránh những cú vấp khiến cả công ty mất dữ liệu hoặc mất cả tuần không làm việc được.
Khái niệm cốt lõi
Ba mô hình triển khai Jira
- Server: cài trên hạ tầng của bạn, một node duy nhất. Đã EOL từ 02/2024. Đây là cái bạn cần thoát khỏi.
- Data Center (DC): cũng self-hosted nhưng chạy nhiều node, hỗ trợ high-availability, license tính theo tier user và khá đắt. Phù hợp tổ chức lớn hoặc có yêu cầu chủ quyền dữ liệu (ngân hàng, khối nhà nước).
- Cloud: Atlassian host toàn bộ, bạn truy cập qua
tên-công-ty.atlassian.net. Cập nhật tự động, không cần lo hạ tầng, tính phí theo user/tháng.
Công cụ migration chính thức: JCMA
Vũ khí trung tâm là Jira Cloud Migration Assistant (JCMA) — một app do Atlassian phát hành, cài trực tiếp vào Jira Server của bạn. JCMA cho phép bạn chọn từng phần dữ liệu (project, user, group, attachment...) và đẩy lên Cloud theo từng đợt. Nó có chế độ pre-migration checks để quét trước những vấn đề sẽ gây lỗi, và cho phép chạy migration theo lô (batch) thay vì phải "được ăn cả ngã về không".
Ngoài JCMA còn có hướng backup file import (xuất file XML backup rồi import lên Cloud) — nhưng cách này thô, dễ vỡ với dữ liệu lớn và Atlassian khuyến nghị ưu tiên JCMA cho gần như mọi trường hợp.
Điều quan trọng nhất: KHÔNG phải mọi thứ đều đi cùng
Đây là điểm khiến nhiều team "vỡ trận" sau migration vì không lường trước. Những thứ thường không tự động chuyển hoặc chuyển không nguyên vẹn:
- App/plugin của bên thứ ba: mỗi app trên Server chưa chắc có bản Cloud tương đương. Ví dụ một app tạo report tùy chỉnh trên Server có thể không tồn tại trên Cloud, hoặc tồn tại nhưng dữ liệu app không migrate được.
- Cấu hình nâng cao: một số workflow phức tạp, custom field kiểu đặc thù, hay các script (nếu bạn dùng ScriptRunner) cần làm lại thủ công.
- Cấu trúc phân quyền: permission scheme, notification scheme trên Cloud vận hành hơi khác Server.
- URL và link cũ: link trực tiếp đến issue theo domain cũ sẽ chết; cần redirect hoặc thông báo.
Cloud có mấy "hương vị"
Jira Cloud có Free, Standard, Premium, Enterprise. Với PM cần lưu ý: Advanced Roadmaps (Plans), automation với quota cao, sandbox và audit log chi tiết thường chỉ có từ Premium trở lên. Nếu team bạn đang dựa vào roadmap đa nhóm, đừng chọn nhầm gói Standard rồi mới ngã ngửa.
Tình huống thực tế
Tình huống 1 — Fintech Sài Gòn "chạy nước rút" quá muộn
Một công ty fintech ở Quận 1, TP.HCM (khoảng 180 nhân sự, 12 team dev) chạy Jira Server suốt 5 năm với hơn 40.000 issue tích lũy. Đến tháng 11/2023 ban lãnh đạo mới quyết định migrate — chỉ còn 3 tháng trước EOL. Team IT lao vào chạy JCMA lần đầu và... pre-migration check báo hơn 200 lỗi: trùng email user, custom field bị mồ côi, và 3 app quan trọng (một app quản lý test case, một app biểu đồ Gantt) không có bản Cloud.
Vì gấp, họ quyết định migrate luôn dữ liệu core, chấp nhận bỏ 2 app và tìm giải pháp thay thế sau. Kết quả: 2 tuần đầu sau go-live, team QA gần như tê liệt vì toàn bộ test case nằm trong app cũ không lên Cloud, phải chép tay lại 300+ case.
Bài học: Migration cần bắt đầu sớm ít nhất 3–6 tháng trước hạn. App bên thứ ba là rủi ро lớn nhất, phải audit và tìm phương án thay thế TRƯỚC khi bấm nút migrate, không phải sau.
Tình huống 2 — Agency Hà Nội migrate theo lô, đúng bài
Một digital agency ở Hà Nội (khoảng 60 người, 25 project khách hàng đang active) tiếp cận bài bản hơn. Họ dành 1 tháng chỉ để audit: liệt kê toàn bộ project, đánh dấu project nào còn sống, project nào đã đóng (client cũ). Kết quả họ phát hiện 9/25 project là "xác chết" — dự án đã kết thúc, không cần lên Cloud. Họ archive luôn, giảm 36% khối lượng dữ liệu cần migrate.
Sau đó họ dùng JCMA chạy migration thử trên môi trường Cloud sandbox, đo thời gian, sửa hết lỗi pre-check. Đến cuối tuần go-live thật, họ migrate theo 2 lô: lô 1 gồm các project nội bộ (ít rủi ро) vào tối thứ Sáu, kiểm thử thứ Bảy; lô 2 gồm project khách hàng vào Chủ nhật. Sáng thứ Hai cả công ty vào Cloud mượt mà, downtime gần như bằng 0 trong giờ làm việc.
Bài học: Dọn rác trước khi chuyển nhà. Archive project chết, chạy thử trên sandbox, migrate theo lô vào cuối tuần — đó là công thức downtime thấp và ít drama.
Tình huống 3 — Startup Singapore và cái bẫy "user email trùng"
Một startup SaaS ở Singapore (khoảng 45 người) tưởng migration sẽ đơn giản vì dữ liệu nhỏ. Nhưng JCMA liên tục báo lỗi user. Nguyên nhân: trên Server, nhiều tài khoản cũ dùng email dạng nội bộ (admin@localhost, hoặc email cá nhân gmail của nhân viên đã nghỉ), và một số user bị trùng email do lịch sử tạo tài khoản lộn xộn. Trên Cloud, danh tính người dùng gắn chặt với Atlassian account = một email duy nhất, nên mọi trùng lặp đều bị chặn.
Họ mất gần 1 tuần chỉ để dọn dẹp directory người dùng: gộp tài khoản trùng, cập nhật email hợp lệ, vô hiệu hóa (deactivate) tài khoản của nhân viên cũ. Sau khi dữ liệu user sạch, migration chạy trơn tru trong vài giờ.
Bài học: Vấn đề số một khiến migration đình trệ thường không phải dung lượng dữ liệu mà là chất lượng dữ liệu user. Dọn danh sách người dùng (email hợp lệ, không trùng, deactivate người đã nghỉ) là việc cần làm sớm nhất.
Hướng dẫn từng bước
Dưới đây là quy trình migration Server → Cloud mà một PM nên nắm để điều phối, kể cả khi phần kỹ thuật do IT thực thi.
Bước 1 — Đánh giá và lập kế hoạch (assess). Liệt kê toàn bộ: số project, số user, số app đang dùng, dung lượng attachment. Xác định phạm vi: migrate tất cả hay chỉ project còn sống. Chốt gói Cloud phù hợp (Standard/Premium) dựa trên nhu cầu (có cần Advanced Roadmaps, sandbox, automation cao không).
Bước 2 — Audit app bên thứ ba. Với mỗi app trên Server, kiểm tra trên Atlassian Marketplace xem có bản Cloud không, và app đó có công cụ migrate dữ liệu riêng không. Lập danh sách "có tương đương / cần thay thế / bỏ hẳn". Đây là bước hay bị bỏ quên nhất nhưng gây hậu quả nặng nhất.
Bước 3 — Dọn dẹp dữ liệu (cleanup). Archive project đã đóng. Dọn user directory: sửa email không hợp lệ, gộp/xóa tài khoản trùng, deactivate nhân viên đã nghỉ. Xóa custom field, workflow, scheme không còn dùng. Dữ liệu càng sạch, migration càng nhanh và ít lỗi.
Bước 4 — Tạo site Cloud và cài JCMA.
Đăng ký site tên-công-ty.atlassian.net. Cài Jira Cloud Migration Assistant vào Jira Server. Nếu có gói Premium, tạo sandbox để chạy thử.
Bước 5 — Chạy pre-migration checks. Để JCMA quét toàn bộ và báo lỗi tiềm ẩn. Sửa từng lỗi cho đến khi sạch. Đừng bao giờ bỏ qua cảnh báo với suy nghĩ "chắc không sao".
Bước 6 — Migrate thử (test run) trên sandbox. Chạy toàn bộ quy trình lên môi trường thử, đo thời gian, và cực kỳ quan trọng: kiểm thử nghiệm thu — mở vài issue, kiểm tra comment, attachment, người assign, link, workflow còn đúng không. Đây là lúc PM vào cuộc mạnh nhất.
Bước 7 — Migrate thật theo lô. Chọn thời điểm ít ảnh hưởng (tối thứ Sáu / cuối tuần). Migrate theo lô nếu dữ liệu lớn: lô nội bộ/ít rủi ро trước, lô quan trọng sau. Trong lúc migrate, "đóng băng" (freeze) thay đổi trên Server để tránh lệch dữ liệu.
Bước 8 — Nghiệm thu và go-live. Đối chiếu số lượng issue, kiểm tra mẫu ngẫu nhiên, xác nhận user đăng nhập được, automation và board hiển thị đúng. Sau khi ổn, chuyển toàn bộ team sang Cloud, khóa Server ở chế độ chỉ đọc một thời gian ngắn phòng khi cần đối chiếu.
Bước 9 — Truyền thông và đào tạo. Gửi thông báo URL mới, hướng dẫn đăng nhập bằng Atlassian account, nêu rõ những thay đổi (giao diện Cloud, app nào đã thay). Đây là phần "con người" mà PM không được bỏ qua.
Lỗi thường gặp & mẹo
- Bắt đầu quá muộn. Nghĩ "migrate nhanh thôi" rồi dồn vào phút chót. Migration nghiêm túc cần 3–6 tháng. Mẹo: lùi ngày go-live về trước hạn thật ít nhất 1 tháng để có đệm.
- Quên audit app. Migrate xong mới phát hiện app chủ chốt không có trên Cloud, team mất công cụ đang phụ thuộc. Mẹo: audit app là việc TUẦN ĐẦU TIÊN, không phải việc cuối.
- Bỏ qua pre-migration checks. Cố migrate khi còn cảnh báo → dữ liệu lỗi, phải làm lại. Mẹo: coi mỗi cảnh báo là bắt buộc phải xử lý.
- Không chạy test run. Migrate thẳng lên production lần đầu. Mẹo: luôn thử trên sandbox (Premium) trước, dù chỉ với vài project mẫu.
- Migrate giữa giờ làm việc. Team đang chạy sprint thì hệ thống downtime. Mẹo: chọn cuối tuần, và freeze thay đổi trên Server trong lúc migrate.
- Bỏ quên dữ liệu user bẩn. Email trùng/không hợp lệ làm migration đứng. Mẹo: dọn user directory sớm, mỗi user = một email duy nhất, hợp lệ.
- Không truyền thông. Sáng thứ Hai cả team ngơ ngác không biết vào đâu. Mẹo: gửi thông báo trước, kèm URL mới và hướng dẫn đăng nhập.
- Không giữ Server để đối chiếu. Xóa Server ngay → mất đường lui khi phát hiện lệch dữ liệu. Mẹo: giữ Server ở chế độ read-only vài tuần sau go-live.
Bài tập thực hành
- Lập bảng audit (30 phút). Giả định bạn là PM một công ty 80 người đang chạy Jira Server. Lập bảng liệt kê 3 cột: (a) danh sách project với trạng thái còn-sống/đã-đóng, (b) danh sách app bên thứ ba với ghi chú "có bản Cloud / cần thay / bỏ", (c) rủi ро dữ liệu user cần dọn. Bảng này chính là "bản đồ" migration của bạn.
- Chọn gói Cloud (15 phút). Với team cần Advanced Roadmaps cho 5 nhóm và automation nhiều, hãy lập luận nên chọn Standard hay Premium và giải thích tại sao. Nêu ít nhất 2 tính năng quyết định.
- Viết kế hoạch downtime (20 phút). Soạn một lịch migration cuối tuần theo lô: lô nào đi trước, giờ nào, ai nghiệm thu, thông báo gửi khi nào. Mục tiêu: downtime trong giờ làm việc bằng 0.
- Soạn email truyền thông (15 phút). Viết email 150–200 từ gửi toàn công ty thông báo chuyển sang Cloud: URL mới, cách đăng nhập bằng Atlassian account, hai thay đổi đáng chú ý, và kênh hỗ trợ khi gặp sự cố.
Tóm tắt
Jira Server đã EOL từ 02/2024, và với đa số công ты Việt Nam/Đông Nam Á, con đường thực tế là chuyển sang Cloud. Công cụ chính là JCMA với ba trụ cột: pre-migration checks, chạy thử trên sandbox, và migrate theo lô. Ba rủi ро lớn nhất cần chặn từ sớm là: app bên thứ ba không có bản Cloud, dữ liệu user bẩn (email trùng/không hợp lệ), và bắt đầu quá muộn. Công thức an toàn: audit sớm → dọn rác (archive project chết, dọn user) → test trên sandbox → migrate cuối tuần theo lô → nghiệm thu kỹ → truyền thông rõ ràng và giữ Server read-only làm đường lui. Là PM, vai trò của bạn không phải cắm dây kỹ thuật, mà là điều phối phạm vi, dẫn dắt nghiệm thu và bảo đảm cả team hạ cánh mượt mà trên Cloud mà không mất một issue nào.