---
title: "Vòng đời version Odoo và bài toán upgrade"
url: "https://bahub.vn/khoa-hoc/erp-cho-ba/vong-doi-version-odoo-va-bai-toan-upgrade"
author: "Võ Văn Trí"
published: "2026-09-10"
updated: "2026-11-02"
source: "bahub.vn"
license: "Được dùng lại, trích dẫn và đưa cho AI đọc, với điều kiện ghi rõ nguồn bahub.vn kèm link bài gốc."
---

# Vòng đời version Odoo và bài toán upgrade

> 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.

- Nguồn: https://bahub.vn/khoa-hoc/erp-cho-ba/vong-doi-version-odoo-va-bai-toan-upgrade
- Tác giả: Võ Văn Trí
- Khoá học: ERP cho Business Analyst (mục lục: https://bahub.vn/khoa-hoc/erp-cho-ba.md)
- Chương: Nền tảng Odoo

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ớ.

## Ba câu hỏi thay cho một câu trả lời

* **Câu thứ nhất là version doanh nghiệp đang chạy còn được hỗ trợ tới bao giờ**, và nền tảng họ dùng có ép một lịch nâng cấp riêng không.
* **Câu thứ hai là hệ thống có bao nhiêu phần nằm ngoài sản phẩm chuẩn**, và phần đó làm bằng cách nào.
* **Câu thứ ba là ai chịu trách nhiệm nâng cấp phần ngoài chuẩn khi version mới ra.**

> 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.

## Hạn hỗ trợ của version đang chạy

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](https://bahub.vn/khoa-hoc/erp-cho-ba/no-ky-thuat-cua-customization), ở đâ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.

![Đồng hồ hỗ trợ chạy từ ngày Odoo phát hành, không từ ngày khách go-live](https://bahub.vn/uploads/2026/11/1793630930225-vfk3ny-vong-doi-version-odoo-va-bai-toan-upgrade-1.webp "Đồng hồ hỗ trợ chạy từ ngày Odoo phát hành, không từ ngày khách go-live")

## Lịch nâng cấp bắt buộc theo từng nền tả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](https://bahub.vn/khoa-hoc/erp-cho-ba/odoo-online-odoo-sh-on-premise), 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:

1. doanh nghiệp nhận thông báo trong chính database vài tuần trước hạn
2. đội nâng cấp của Odoo chạy thử một lần trong im lặng trên bản sao
3. nếu lần chạy thử thành công trong dưới hai mươi phút thì doanh nghiệp tự bấm nâng cấp được
4. và nếu tới hạn mà không ai làm gì thì việc nâng lên phiên bản kế tiếp được kích hoạt tự động.

**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**.

## Phần ngoài chuẩn và cách đếm nó

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ả:

* module mua từ bên thứ ba
* các thay đổi làm bằng Studio
* automation
* mẫu email
* bản dịch đã sửa tay
* và đặc biệt là các tích hợp với hệ thống bên ngoài.

![Phần ngoài chuẩn không chỉ là module: còn Studio, automation, mẫu email, tích hợp](https://bahub.vn/uploads/2026/11/1793630931197-37jhph-vong-doi-version-odoo-va-bai-toan-upgrade-2.webp "Phần ngoài chuẩn không chỉ là module: còn Studio, automation, mẫu email, tích hợp")

## Ranh giới của cam kết nâng cấp

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:

* toàn bộ ứng dụng chuẩn
* toàn bộ tùy biến tạo bằng Studio với điều kiện Studio còn được cài và thuê bao tương ứng còn hiệu lực
* và các phần phát triển có hợp đồng bảo trì tùy biến đi kèm.

Tài liệu cũng liệt kê thẳng ba nhóm không được bao.

* **Thứ nhất là dọn dẹp dữ liệu và cấu hình đã có từ trước.**
* **Thứ hai là các module bổ sung không nằm trong hợp đồng bảo trì**, dù do doanh nghiệp tự viết hay do bên thứ ba viết, và tài liệu ghi rõ rằng bên thứ ba ở đây bao gồm cả các partner của Odoo.
* **Thứ ba là đào tạo người dùng** trên tính năng và luồng làm việc của phiên bản mới.

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.

## Môi trường thử và ngày chạy thật

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:

* dạng xem còn hiển thị đúng không
* mẫu in còn ra đúng không
* mẫu email và bản dịch đã lưu có trục trặc không
* bộ lọc đã lưu còn không.

Đặ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ũ**.

![Diễn tập trọn luồng nghiệp vụ một lần vào ngày trước ngày nâng cấp thật](https://bahub.vn/uploads/2026/11/1793630931911-o35etc-vong-doi-version-odoo-va-bai-toan-upgrade-3.webp "Diễn tập trọn luồng nghiệp vụ một lần vào ngày trước ngày nâng cấp thật")

## Việc làm từ giai đoạn thiết kế

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.

* Lập danh sách phần ngoài chuẩn khi chốt giải pháp, ghi rõ hạng mục nào làm bằng Studio, hạng mục nào bằng code
* Ghi tên đơn vị bảo trì cho từng hạng mục vào chính danh sách đó
* Giữ kịch bản kiểm thử của giai đoạn nghiệm thu để dùng lại khi kiểm thử nâng cấp
* Đưa điều khoản trách nhiệm nâng cấp phần ngoài chuẩn vào hợp đồng, không để trong biên bản họp

Đồ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.

## Cách đặt chuyện này lên bàn ở presale

Ở 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:

* hạn hỗ trợ của phiên bản sẽ triển khai
* nhịp nâng cấp bắt buộc của nền tảng khách chọn
* và số hạng mục ngoài chuẩn trong phạm vi đang bàn.

**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ó.

## Những gì bài này không trả lời

Có ba chỗ tôi cố ý để trống.

* **Thứ nhất là mọi con số phí**, gồm phí hỗ trợ mở rộng và phí hợp đồng bảo trì tùy biến, thứ bạn phải lấy từ báo giá chính thức chứ không lấy từ một bài viết.
* **Thứ hai là công sức của một lần nâng cấp tính theo ngày công**, thứ phụ thuộc vào số hạng mục ngoài chuẩn và khoảng cách version tới mức một con số chung sẽ gây hiểu nhầm.
* **Thứ ba**, những gì ở trên là quy trình Odoo công bố chứ không phải nhật ký của một lần nâng cấp cụ thể.

Để đế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](https://bahub.vn/khoa-hoc/erp-cho-ba/developer-mode-cong-cu-cua-ba), công cụ nhiều người vẫn tưởng chỉ dành cho lập trình viên.

---

Nguồn: https://bahub.vn/khoa-hoc/erp-cho-ba/vong-doi-version-odoo-va-bai-toan-upgrade — Được dùng lại, trích dẫn và đưa cho AI đọc, với điều kiện ghi rõ nguồn bahub.vn kèm link bài gốc.