Bạn vẫn xem được toàn bộ bài học mà không cần đăng nhập.
Một năm nữa có phải nâng cấp Odoo không, câu trả lời đúng không phải có hoặc không mà là ba câu hỏi về hạn hỗ trợ, phần ngoài chuẩn và người trả tiền.
Buổi nghiệm thu gần xong, mọi người đang gấp máy tính lại thì phía doanh nghiệp hỏi thêm một câu nghe rất nhẹ, rằng một năm nữa bên anh chị có phải nâng cấp không em. Câu trả lời quen thuộc thường rơi vào một trong hai vế, hoặc chưa cần đâu anh, hoặc có nhưng mình tính sau. Cả hai vế đều làm hỏng việc.
Doanh nghiệp chạy trên Odoo Online một ngày mở hệ thống lên thì thấy thông báo rằng database sẽ được tự động nâng cấp sau vài tuần, trong khi không ai bên phía dự án chuẩn bị gì. Doanh nghiệp ở đường còn lại thì nhận một báo giá cho phần việc họ tin là đã nằm trong hợp đồng, bởi từng nghe rằng nâng cấp Odoo là miễn phí, và câu đó chỉ đúng một nửa.
Năm nay câu hỏi ấy còn khó hơn, bởi Odoo 20 đã ra mắt ngày 24/09/2026, nghĩa là một dự án vừa nghiệm thu trên Odoo 19 tháng này đã không còn đứng trên phiên bản mới nhất ngay từ ngày go-live.
Câu trả lời tử tế cho câu hỏi kia không phải là có hoặc không, nó là ba câu hỏi khác.
Các mốc trong bài tôi lấy theo tài liệu chính thức của Odoo ở thời điểm cuối tháng mười năm 2026, và đây là loại nội dung bạn phải mở lại trước mỗi lần nói chuyện với khách chứ không nên tin theo trí nhớ.
Câu đầu tra được bằng tài liệu, câu thứ hai đếm được trên hệ thống, còn câu thứ ba phải thương lượng với người.
Odoo phát hành một phiên bản chính mỗi năm, và theo tài liệu chính thức thì mỗi phiên bản chính được hỗ trợ tiêu chuẩn trong ba năm kể từ ngày phát hành, gồm helpdesk, sửa lỗi và cập nhật bảo mật, trên cả Odoo Online, Odoo.sh lẫn on-premise.
Hết ba năm đó thì câu chuyện tách theo nền tảng. Hỗ trợ mở rộng phải trả thêm phí, chỉ có trên on-premise và trên Odoo.sh với một số phiên bản nhất định, còn Odoo Online thì không có giai đoạn này. Giai đoạn mở rộng vẫn có helpdesk và sửa lỗi trong chừng mực khả thi, nhưng không còn cập nhật bảo mật.
Con số ba năm ảnh hưởng thế nào tới chi phí phần đã customize là chuyện của bài về nợ kỹ thuật, ở đây nó chỉ là một cái mốc trên lịch.
Ở thời điểm tôi viết bài này, bảng vòng đời chính thức ghi Odoo 20 dự kiến hết hỗ trợ tiêu chuẩn vào tháng chín năm 2029, Odoo 19 phát hành tháng chín năm 2025 và dự kiến hết vào tháng chín năm 2028, còn Odoo 18 dự kiến hết vào tháng chín năm 2027.
Odoo 17 đã hết hỗ trợ tiêu chuẩn từ tháng chín năm 2026, nên hiện không còn được hỗ trợ trên Odoo Online mà chỉ còn hỗ trợ mở rộng có phí trên Odoo.sh và on-premise, cùng chỗ với Odoo 16 và Odoo 15.
Đọc bảng từ phía khách thì có hai điều phải nói ngay. Một dự án go-live trên Odoo 19 vào cuối năm 2026 chỉ còn khoảng hai năm hỗ trợ tiêu chuẩn chứ không phải ba, bởi đồng hồ chạy từ ngày Odoo phát hành chứ không từ ngày khách go-live. Đồng thời đích nâng cấp cũng có giới hạn, vì tài liệu chỉ cho nâng lên một phiên bản chính còn trong hỗ trợ tiêu chuẩn hoặc vừa hết hỗ trợ chưa quá sáu tháng.
Hạn hỗ trợ của phiên bản chỉ là một nửa câu chuyện, nửa còn lại nằm ở chỗ hệ thống được đặt ở đâu, và đây là phần nội dung tiếng Việt hay bỏ sót nhất.
Trên Odoo Online, tài liệu nói rằng nâng cấp là bắt buộc, với tần suất khác nhau giữa phiên bản chính và phiên bản trung gian. Với phiên bản chính thì bắt buộc hai năm một lần, tức sớm hơn cả mốc ba năm hỗ trợ ở trên. Với phiên bản trung gian, tức các bản SaaS mang số như 19.3 hay 19.4, thì bắt buộc vài tuần sau khi phiên bản kế tiếp được phát hành, mà các bản này thường ra khoảng hai tới ba tháng một lần.
Hai con số ba năm và hai năm thoạt nhìn có vẻ vênh nhau, nhưng ba năm là thời gian Odoo còn hỗ trợ một phiên bản, còn hai năm là nhịp Odoo Online buộc database của bạn phải đi tiếp. Khách dùng Odoo Online gần như không chạm tới mốc ba năm, nên đọc cho họ con số ba năm là nói thiếu.
Ghép nhịp đó với ràng buộc ở bài về ba lựa chọn hạ tầng, rằng phiên bản trung gian chỉ có trên Odoo Online, bạn có một hệ quả phải nói với khách từ sớm: họ vừa phải nâng cấp thường xuyên hơn, vừa chỉ rời Odoo Online được vào thời điểm do lịch phát hành của Odoo quyết định.
Tài liệu còn mô tả một cơ chế bạn nên phổ biến cho khách trước:
Trên Odoo.sh thì nhịp thoáng hơn, sau ba năm hỗ trợ tiêu chuẩn doanh nghiệp có thêm hai năm nữa để hoàn tất nâng cấp. Còn với on-premise thì tài liệu nói thẳng rằng bạn ở lại trên một phiên bản bao lâu cũng được, kèm câu khuyến nghị là không nên.
On-premise là ngoại lệ đáng nói với khách, bởi một doanh nghiệp có đội kỹ thuật riêng và chấp nhận không còn cập nhật bảo mật thì có quyền đứng yên nhiều năm; điều cần tránh là việc đó xảy ra do quên chứ không phải do quyết.
Câu hỏi thứ hai không tra được từ tài liệu, bạn phải đi đếm trên chính hệ thống, và trước khi đếm thì cần biết đếm cái gì. Tài liệu dành cho người phát triển của Odoo định nghĩa module tùy chỉnh là bất kỳ module nào mở rộng mã chuẩn của Odoo và không được tạo bằng Studio. Định nghĩa nghe khô khan, nhưng nó là đường ranh quyết định hóa đơn.
Ràng buộc đi kèm rất cứng. Database có cài module tùy chỉnh thì không nâng cấp được cho tới khi những module đó có bản chạy được trên phiên bản đích, và tài liệu khuyến nghị làm song song, tức vừa yêu cầu một bản database đã nâng cấp để thử, vừa cho đội kỹ thuật nâng mã nguồn module lên. Nói cách khác, đây là hai luồng việc chạy cạnh nhau chứ không nối tiếp, và luồng nào chậm thì cả lần nâng cấp chậm theo.
Danh sách phải đếm rộng hơn danh sách module, bởi nó gồm cả:
Câu nâng cấp Odoo là miễn phí mà khách hay nghe thì đúng ở phần đầu và thiếu ở phần đuôi, và vế đầu chỉ áp dụng cho bản Enterprise chứ không phải cho mọi cách dùng Odoo.
Tài liệu chính thức ghi rằng với Odoo Enterprise, việc nâng database lên phiên bản mới nhất là miễn phí, áp dụng cho cả Odoo Online, Odoo.sh lẫn on-premise, và phạm vi được bao gồm ba nhóm:
Tài liệu cũng liệt kê thẳng ba nhóm không được bao.
Có một câu nữa đáng nhắc lại với khách, rằng nếu một thay đổi ở phiên bản mới làm hỏng một tùy biến thì trách nhiệm làm cho nó tương thích trở lại thuộc về người bảo trì module ấy. Cách đặt vấn đề đó chuyển bài toán từ chỗ ai có lỗi sang chỗ ai đã nhận việc.
Từ đó suy ra một cách nói chuyện gọn gàng. Việc nâng cấp phần chuẩn thuộc về Odoo, việc nâng cấp phần anh chị làm riêng thuộc về đơn vị đang bảo trì nó, và câu hỏi còn lại là phần thứ hai được trả bằng hợp đồng bảo trì hằng năm hay bằng báo giá riêng mỗi lần nâng cấp.
Với database có phần ngoài chuẩn, quy trình chính thức đặt trước mọi thứ một bước mà khách ít khi được báo, đó là dừng phát triển và đóng băng mã nguồn trong suốt quá trình nâng cấp, chỉ trừ việc sửa lỗi, tức là mọi yêu cầu làm thêm trong khoảng đó đều phải xếp hàng chờ.
Tiếp theo là yêu cầu một bản database đã nâng cấp để thử, không phải để làm việc trên đó mà để xác nhận phần chuẩn chuyển đổi trót lọt. Bản thử này được trung hòa để không ảnh hưởng ra ngoài, cụ thể là tác vụ định kỳ bị tắt, máy chủ gửi thư bị thay bằng một máy chủ giả, cổng thanh toán và đơn vị vận chuyển bị đưa về môi trường thử, còn đồng bộ ngân hàng bị tắt.
Sau đó là kiểm thử, và đây là chỗ vai trò của bạn rõ nhất. Tài liệu đưa ra một danh sách kiểm rất đời thường, gồm:
Đặc biệt, tài liệu khuyến nghị chạy theo luồng nghiệp vụ đầu cuối, từ mua, nhận hàng, bán, giao hàng tới hóa đơn và credit note, chứ không chỉ mở từng màn hình, và diễn tập trọn vẹn một lần vào ngày trước ngày nâng cấp thật.
Ở ngày chạy thật có hai chi tiết phải nói trước với khách. Hệ thống không dùng được trong lúc nâng cấp nên thời điểm phải chọn vào lúc ít người dùng nhất, và trên Odoo Online thì sau khi hoàn tất không có đường quay lại phiên bản cũ.
Phần lớn cái đau của lần nâng cấp sau được quyết định ngay ở giai đoạn thiết kế lần này, và những việc làm nó bớt đau đều rẻ nếu làm sớm.
Đồng thời nên tập thói quen mỗi khi phiên bản mới ra thì đọc release notes rồi soát lại danh sách, bởi tài liệu nâng cấp khuyên so từng tùy biến với những gì sản phẩm chuẩn đã bổ sung trước khi nâng nó lên.
Một hạng mục xóa được vì sản phẩm chuẩn đã làm thay là hạng mục rẻ nhất trong cả vòng đời.
Ở giai đoạn presale, sai lầm hay gặp không phải là nói dối mà là nói thiếu. Cụ thể là nêu vòng đời ba năm như một thông tin sản phẩm rồi để khách tự suy ra rằng ba năm nữa mới phải lo.
Cách gọn hơn là đưa ba con số lên bàn cùng lúc, gồm:
Con số thứ hai mới là con số hay bị bỏ quên, vì như đã nói ở trên, nó có thể ngắn hơn hạn hỗ trợ. Còn nếu phiên bản sẽ triển khai không phải bản mới nhất, như Odoo 19 lúc này, thì lý do chọn nó phải được ghi ra.
Sau đó là một câu hỏi thay cho một lời cảnh báo, rằng doanh nghiệp muốn phần ngoài chuẩn được bảo trì theo hợp đồng hằng năm hay muốn báo giá lại mỗi lần nâng cấp. Hỏi như vậy thì hai phương án đều hợp lệ và khách chọn được, còn cảnh báo suông thì khách chỉ nghe thấy rủi ro.
Trong trường hợp khách nói chưa nghĩ tới và muốn để sau, bạn vẫn nên ghi câu trả lời đó vào biên bản, bởi hai năm sau thứ giúp cuộc trao đổi không thành tranh cãi là bằng chứng hai bên đã từng bàn tới nó.
Có ba chỗ tôi cố ý để trống.
Để đếm được phần ngoài chuẩn trong một hệ thống bàn giao dở dang, thứ đầu tiên bạn cần là nhìn thấy tên kỹ thuật của trường và của đối tượng sau mỗi màn hình, và cánh cửa mở ra chỗ đó là chế độ nhà phát triển, công cụ nhiều người vẫn tưởng chỉ dành cho lập trình viên.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận