Nâng Cấp Từ Odoo 19 Lên Odoo 20: Chu Kỳ Phiên Bản, Nội Dung Thay Đổi, Quy Trình Nâng Cấp Và Các Điểm Cần Kiểm Trước Khi Nâng Cấp Sản Xuất

Mỗi phiên bản lớn của Odoo được phát hành theo chu kỳ một năm, kèm theo một tập các thay đổi về giao diện, trường dữ liệu, mô hình và hành vi ứng dụng. Với các doanh nghiệp đang vận hành Odoo 19, câu hỏi thực tế không phải là phiên bản mới có những tính năng gì, mà là quá trình chuyển từ phiên bản hiện tại sang phiên bản mới diễn ra như thế nào, những phần nào trong hệ thống chịu tác động, và các bước kiểm tra nào cần hoàn thành trước khi cơ sở dữ liệu sản xuất được nâng cấp. Odoo 20 là phiên bản lớn tiếp theo trong chu kỳ này, với các thay đổi đáng kể ở lớp ứng dụng AI và ở các ứng dụng nghiệp vụ, và được phát hành vào khoảng tháng 9 năm 2026.

Bài viết khảo sát quá trình nâng cấp từ Odoo 19 lên Odoo 20 dựa trên tài liệu chính thức của Odoo cho phiên bản 20.0: chu kỳ phát hành và hỗ trợ của các phiên bản lớn, phạm vi áp dụng của các thời hạn nâng cấp theo từng loại lưu trữ, nội dung thay đổi chính của Odoo 20, quy trình nâng cấp chuẩn qua nền tảng nâng cấp của Odoo, các rủi ro đặc thù của phần tùy biến, và tập các công việc cần hoàn thành trước ngày nâng cấp cơ sở dữ liệu sản xuất.

📑 Mục Lục

• Chu kỳ phiên bản và hỗ trợ của Odoo
• Nội dung thay đổi chính của Odoo 20
• Quy trình nâng cấp chuẩn: từ cơ sở dữ liệu thử nghiệm đến sản xuất
• Phạm vi và giới hạn của quy trình nâng cấp
• Phần tùy biến, dữ liệu và các rủi ro đặc thù
• Các công việc cần hoàn thành trước khi nâng cấp sản xuất

Chu Kỳ Phiên Bản Và Hỗ Trợ Của Odoo

🗓️ Phiên bản lớn, phiên bản phụ và vòng đời ba năm

Odoo phát hành các phiên bản lớn theo chu kỳ một năm. Odoo 19.0 được phát hành vào tháng 9 năm 2025, và Odoo 20.0 được phát hành vào tháng 9 năm 2026. Mỗi phiên bản lớn được hỗ trợ chuẩn trong ba năm, tính từ thời điểm phát hành: Odoo 19.0 được hỗ trợ chuẩn đến tháng 9 năm 2028 (theo kế hoạch), và Odoo 20.0 được hỗ trợ chuẩn đến tháng 9 năm 2029 (theo kế hoạch). Giai đoạn hỗ trợ chuẩn bao gồm vá bảo mật, hỗ trợ helpdesk và sửa lỗi, và áp dụng cho cả ba loại lưu trữ là Odoo Online, Odoo.sh và on-premise. Sau khi hết hỗ trợ chuẩn, một giai đoạn hỗ trợ mở rộng có thể được mua với phí bổ sung, nhưng chỉ áp dụng cho Odoo.sh (với một số phiên bản giới hạn) và on-premise; vá bảo mật không còn được cung cấp trong giai đoạn này, và các sửa lỗi chỉ được thực hiện khi khả thi về mặt kỹ thuật. Các phiên bản SaaS mang số phụ (ví dụ 19.1, 19.2, 19.3, 19.4) được phát hành định kỳ mỗi hai đến ba tháng, chỉ có trên Odoo Online và không thuộc phạm vi hỗ trợ mở rộng.

⏰ Thời hạn nâng cấp bắt buộc theo loại lưu trữ

Mức độ bắt buộc của một lần nâng cấp phụ thuộc vào loại lưu trữ mà cơ sở dữ liệu đang chạy. Trên Odoo Online, cơ sở dữ liệu ở phiên bản lớn phải được nâng cấp bắt buộc theo chu kỳ hai năm, và cơ sở dữ liệu ở phiên bản phụ phải được nâng cấp một vài tuần sau khi phiên bản phụ tiếp theo được phát hành; Odoo Online thực hiện quá trình này bằng cơ chế phát hành lăn (rolling release), trong đó đội nâng cấp của Odoo chạy một lần nâng cấp thử im lặng trước, và nếu nâng cấp thử thành công, cơ sở dữ liệu được mời nâng cấp trực tiếp từ chính cơ sở dữ liệu đó, với thời hạn được thông báo trước. Trên Odoo.sh, sau ba năm hỗ trợ chuẩn, cơ sở dữ liệu có thêm hai năm để hoàn tất nâng cấp, và thông báo về yêu cầu nâng cấp được hiển thị trong dự án. Với on-premise, không có thời hạn nâng cấp bắt buộc về mặt dịch vụ, nhưng khoảng cách giữa hai phiên bản càng nhỏ thì quá trình nâng cấp càng ít phức tạp, nên việc nâng cấp khi cần thay vì khi buộc là cách giữ cho chi phí và rủi ro của mỗi lần nâng cấp ở mức thấp hơn.

🔁 Nâng cấp giữa các phiên bản: từ đâu đến đâu

Một cơ sở dữ liệu có thể được nâng cấp từ bất kỳ phiên bản nào sang bất kỳ phiên bản lớn nào còn trong hỗ trợ chuẩn, hoặc vừa hết hỗ trợ chuẩn chưa quá sáu tháng. Với một cơ sở dữ liệu đang chạy Odoo 19.0 tại thời điểm Odoo 20.0 phát hành, cả hai phiên bản đều trong hỗ trợ chuẩn nên lộ trình nâng cấp trực tiếp từ 19.0 lên 20.0 khả thi ngay. Việc nâng cấp giữa hai phiên bản lớn liên tiếp là trường hợp có khoảng cách nhỏ nhất, và cũng là trường hợp mà tập thay đổi cần được xem xét là tập thay đổi của đúng một phiên bản, thay vì tập hợp dồn của nhiều phiên bản. Nếu một cơ sở dữ liệu đã bỏ lỡ hai chu kỳ phát hành, quá trình nâng cấp sẽ phải đi qua tập thay đổi của nhiều phiên bản cùng lúc, và khối lượng kiểm thử trước khi nâng cấp sản xuất tăng theo đó. Đây là lý do các thời hạn nâng cấp theo loại lưu trữ ở mục trước tồn tại: chúng giữ cho khoảng cách phiên bản của mỗi cơ sở dữ liệu nằm trong một mức có thể kiểm soát.

Nội Dung Thay Đổi Chính Của Odoo 20

🤖 Ứng dụng AI riêng và cấu trúc agent, skills, tools, sources

Thay đổi lớn nhất của Odoo 20 nằm ở lớp ứng dụng AI. Trong Odoo 20, AI được tổ chức thành một ứng dụng riêng, nơi các tính năng AI được tập trung quản lý thay vì phân tán ở từng ứng dụng nghiệp vụ như ở các phiên bản trước. Thành phần cốt lõi của ứng dụng này là các agent: mỗi agent là một trợ lý ảo có một mục đích được xác định, một prompt mô tả vai trò và cách hành xử, một tập skills và một tập sources. Skills là các chỉ thị và vai trò định hướng việc agent cần hoàn thành, và tools là các hàm mà agent gọi để thực sự thao tác trên dữ liệu; các tools này chính là các server actions trong hệ thống. Sources là các nguồn thông tin mà agent tham chiếu khi trả lời và khi lập kế hoạch hành động. Nhiều tính năng AI vẫn có thể sử dụng mà không cần cài ứng dụng AI, nhưng việc tạo và tùy chỉnh agent yêu cầu ứng dụng AI phải được cài đặt. Ứng dụng AI trong Odoo 20 còn bao gồm các công cụ phụ trợ được tài liệu hóa riêng: chuyển giọng nói thành văn bản và tóm tắt cuộc họp, cải thiện văn bản, tạo mẫu email, tạo hình ảnh, live chat có hỗ trợ AI và phân loại tài liệu.

🔌 Máy chủ MCP: kết nối hệ sinh thái AI bên ngoài vào cơ sở dữ liệu

Một thành phần mới trong Odoo 20 là máy chủ MCP (Model Context Protocol) tích hợp sẵn trong ứng dụng AI. MCP là một chuẩn mã nguồn mở cho phép các mô hình ngôn ngữ lớn bên ngoài tương tác an toàn với các ứng dụng ngoài và truy cập dữ liệu của chúng. Với máy chủ MCP của Odoo, một cơ sở dữ liệu Odoo đóng vai trò máy chủ MCP ở xa, và một client AI bên ngoài — các ứng dụng AI mà người dùng đang sử dụng — có thể kết nối trực tiếp vào cơ sở dữ liệu để đọc và chỉnh sửa dữ liệu theo các workflow AI riêng của người dùng đó. Xác thực được thực hiện bằng OAuth (phương thức được khuyến nghị, chỉ dành cho người dùng nội bộ) hoặc bằng API key (dành cho người dùng portal). Khi kết nối thành công, client tự động yêu cầu danh sách các tools mà cơ sở dữ liệu đang mở ra. Theo tài liệu 20.0, một cơ sở dữ liệu Odoo mặc định mở năm tools: Get Fields, Get Models, MCP Retrieve initial context, Search và Read group; các tools còn lại, đặc biệt là các tools có khả năng ghi, bị ẩn khỏi client và chỉ được gọi khi được bật thủ công qua tùy chọn Available in MCP trong server action tương ứng, với tùy chọn đánh dấu Readonly Tool để thông báo cho client rằng tools đó không thay đổi dữ liệu.

📐 Thay đổi ở các ứng dụng nghiệp vụ và lớp kỹ thuật

Bên cạnh lớp AI, Odoo 20 mang theo các thay đổi ở các ứng dụng nghiệp vụ và ở lớp kỹ thuật mà tài liệu 20.0 mô tả lại toàn bộ cho phiên bản mới. Các thay đổi này trải dài từ giao diện và trường hiển thị, đến các trường dữ liệu và mô hình mà các module tùy biến có thể đang tham chiếu. Báo cáo nâng cấp được Odoo đính kèm vào email xác nhận nâng cấp thành công và có sẵn trong ứng dụng Discuss cho người dùng thuộc nhóm Administration/Settings; báo cáo này liệt kê các thay đổi do phiên bản mới đưa vào, và là tài liệu đối chiếu chính để xác định những phần của hệ thống hiện hành sẽ bị tác động. Với một cơ sở dữ liệu không có module tùy biến, các thay đổi này chủ yếu nằm ở lớp giao diện và hành vi chuẩn, và việc kiểm thử tập trung vào các luồng nghiệp vụ đang vận hành. Với một cơ sở dữ liệu có module tùy biến, cùng một tập thay đổi lại trở thành tập các điểm cần đối chiếu với mã nguồn của các module, và đây là phần công việc được phân tích ở mục rủi ro.

Quy Trình Nâng Cấp Chuẩn: Từ Cơ Sở Dữ Liệu Thử Nghiệm Đến Sản Xuất

🧪 Yêu cầu cơ sở dữ liệu thử nghiệm đã nâng cấp

Quy trình nâng cấp chuẩn của Odoo bắt đầu bằng việc yêu cầu một cơ sở dữ liệu thử nghiệm đã được nâng cấp, thay vì nâng cấp trực tiếp trên cơ sở dữ liệu đang vận hành. Nền tảng chính cho việc này là upgrade.odoo.com. Với Odoo Online, yêu cầu được đặt từ database manager: chọn cơ sở dữ liệu, vào phần quản lý, chọn Upgrade, xác định phiên bản đích, nhập email nhận liên kết và chọn mục đích là Test. Với Odoo.sh, dự án được tích hợp sẵn với nền tảng nâng cấp: bản sao lưu tự động hàng ngày gần nhất của môi trường production được gửi lên nền tảng, và sau khi nền tảng nâng cấp xong bản sao lưu đó, nó được đặt vào một branch ở chế độ đặc biệt, trong đó mỗi lần push commit sẽ khôi phục bản sao lưu đã nâng cấp và cập nhật lại toàn bộ module tùy biến, cho phép kiểm thử module trên một bản sao nguyên bản của cơ sở dữ liệu đã nâng cấp. Với on-premise, quá trình có thể khởi động bằng lệnh dòng lệnh gọi nền tảng nâng cấp với tên cơ sở dữ liệu và phiên bản đích, hoặc cũng qua upgrade.odoo.com. Trong mọi trường hợp, cơ sở dữ liệu thử nghiệm được gửi lên mà không kèm filestore, và khi nhận về, phần filestore được tách riêng trong một thư mục cần được gộp với filestore của cơ sở dữ liệu production để các tệp đính kèm đầy đủ.

🔍 Kiểm thử cơ sở dữ liệu đã nâng cấp

Cơ sở dữ liệu thử nghiệm được vô hiệu hóa một số chức năng để không làm ảnh hưởng đến cơ sở dữ liệu production: các scheduled action bị vô hiệu, các mail server gửi đi bị lưu trữ và thay bằng một mail server giả, các nhà cung cấp thanh toán và đơn vị vận chuyển được đặt lại về môi trường thử nghiệm, và đồng bộ ngân hàng bị vô hiệu. Do đó, phạm vi kiểm thử tập trung vào các luồng nghiệp vụ thay vì các kênh tích hợp trực tiếp. Tài liệu 20.0 nêu một danh mục kiểm thử cơ bản: các view thông dụng có còn hiển thị đúng, các báo cáo hóa đơn và đơn bán hàng có còn sinh đúng, các trang website có hoạt động, các ghi mới và sửa đổi có thực hiện được, các mẫu email và bản dịch đã lưu có còn nguyên, các bộ lọc tìm kiếm có còn, và dữ liệu có xuất được. Một ví dụ kiểm thử đầu-cuối được tài liệu hóa là lấy một sản phẩm ngẫu nhiên, đối chiếu dữ liệu giữa môi trường thử và production, sau đó lần lượt mua, nhập kho, bán, xuất kho, lập hóa đơn, cấp credit note và đối chiếu các báo cáo kế toán của sản phẩm đó. Ngoài các luồng trong Odoo, các tích hợp với phần mềm bên ngoài (EDI, API), các luồng chéo giữa các ứng dụng, các automated action và các server action trong menu hành động của form view cũng nằm trong phạm vi cần kiểm thử. Các vấn đề phát hiện trong giai đoạn này được báo cáo cho Odoo qua trang hỗ trợ với mục chọn tương ứng cho giai đoạn đang thử nâng cấp.

🚀 Nâng cấp cơ sở dữ liệu production và các bước quanh ngày go-live

Khi kiểm thử hoàn tất và kết quả đủ để xác nhận rằng cơ sở dữ liệu đã nâng cấp có thể vận hành thay cơ sở dữ liệu hiện tại, bước tiếp theo là lên kế hoạch nâng cấp production. Cơ sở dữ liệu production không truy cập được trong suốt quá trình nâng cấp, nên thời điểm nâng cấp được chọn vào khoảng thời gian sử dụng thấp nhất. Vì các script nâng cấp và cơ sở dữ liệu đều thay đổi liên tục, tài liệu khuyến nghị yêu cầu một cơ sở dữ liệu thử nghiệm mới gần ngày nâng cấp để xác nhận quá trình vẫn thành công, và khuyến nghị mạnh mẽ việc diễn tập toàn bộ quá trình nâng cấp ngay trước ngày nâng cấp production. Sau khi nâng cấp production hoàn tất, các vấn đề phát sinh được báo cáo qua trang hỗ trợ với mục chọn tương ứng cho giai đoạn sau nâng cấp. Với Odoo Online, nếu không có hành động nào được thực hiện trước thời hạn thông báo, quá trình nâng cấp tự động sang phiên bản tiếp theo sẽ được kích hoạt theo cơ chế phát hành lăn đã nêu ở mục chu kỳ phiên bản.

Phạm Vi Và Giới Hạn Của Quy Trình Nâng Cấp

🚫 Những việc mà một lần nâng cấp không bao gồm

Quy trình nâng cấp phiên bản chuyển một cơ sở dữ liệu từ một phiên bản lớn sang một phiên bản lớn khác, và chỉ vậy. Theo tài liệu 20.0, một lần nâng cấp không bao gồm bốn việc: hạ cấp về một phiên bản cũ hơn, chuyển đổi giữa các bản — ví dụ từ Community sang Enterprise, đổi loại lưu trữ — ví dụ từ on-premise sang Odoo Online, và chuyển từ một hệ ERP khác sang Odoo. Bốn việc này, nếu cần, là bốn dự án riêng với quy trình và phạm vi riêng, và không được gộp vào phạm vi của một lần nâng cấp phiên bản. Việc phân tách này có ý nghĩa thực tế khi lên kế hoạch: nếu một doanh nghiệp vừa muốn nâng cấp phiên bản vừa muốn thay đổi loại lưu trữ, hai việc đó cần được tách thành hai mốc thời gian và hai tập kiểm thử riêng, vì trộn hai thay đổi vào cùng một cửa sổ làm cho việc xác định nguồn gốc của một sự cố trở nên khó hơn đáng kể.

📋 Báo cáo nâng cấp: tập thay đổi cần đối chiếu

Mỗi lần nâng cấp thành công đi kèm một báo cáo nâng cấp, được đính kèm vào email xác nhận và có sẵn trong ứng dụng Discuss cho người dùng thuộc nhóm Administration/Settings. Báo cáo liệt kê các thay đổi do phiên bản mới đưa vào, gồm các thay đổi về view, trường, mô hình và hành vi mà quá trình nâng cấp đã áp dụng lên cơ sở dữ liệu. Với một cơ sở dữ liệu chuẩn, báo cáo là tham chiếu để hiểu tại sao một màn hình hoặc một báo cáo hiển thị khác sau nâng cấp. Với một cơ sở dữ liệu có module tùy biến, báo cáo là đầu vào chính của bước đối chiếu mã: các trường và mô hình được liệt kê trong báo cáo là tập các điểm mà mã tùy biến có thể đang tham chiếu, và mỗi điểm như vậy cần được xác nhận là vẫn tồn tại với cùng định nghĩa, hoặc được cập nhật trong module. Việc đối chiếu này được thực hiện trước khi nâng cấp production, trên cơ sở dữ liệu thử nghiệm, và kết quả của nó quyết định thời điểm go-live.

🏗️ Nâng cấp module tùy biến song song với nâng cấp cơ sở dữ liệu

Với cơ sở dữ liệu có module tùy biến, quy trình nâng cấp có một ràng buộc quan trọng: cơ sở dữ liệu không thể được nâng cấp cho đến khi các phiên bản của module tùy biến tương thích với phiên bản đích đã có sẵn. Tài liệu 20.0 khuyến nghị chạy hai nhánh song song: nhánh thứ nhất yêu cầu cơ sở dữ liệu thử nghiệm đã nâng cấp để kiểm thử ở lớp dữ liệu và giao diện, nhánh thứ hai nâng cấp mã nguồn của các module tùy biến lên phiên bản đích theo tài liệu hướng dẫn dành cho developer. Hai nhánh gặp nhau ở bước kiểm thử: trên Odoo.sh, chế độ khôi phục lại bản sao lưu đã nâng cấp và cập nhật module khi mỗi commit được push chính là điểm gặp nhau đó, và log của quá trình nâng cấp nằm trong file upgrade.log của bản staging. Với on-premise, hai nhánh cũng song song nhưng điểm gặp nhau là việc cài các module đã nâng cấp lên cơ sở dữ liệu thử nghiệm trước khi chạy kiểm thử. Rủi ro của nhánh này được phân tích ở mục tiếp theo.

Phần Tùy Biến, Dữ Liệu Và Các Rủi Ro Đặc Thù

⚠️ Phần tùy biến: điểm không thể đảo ngược

Rủi ro lớn nhất của một lần nâng cấp phiên bản nằm ở phần tùy biến, và đặc điểm quyết định của rủi ro này là tính không thể đảo ngược. Tài liệu 20.0 nêu rõ: trong quá trình kiểm thử, có thể gặp các khác biệt đáng kể so với các view, tính năng, trường và mô hình chuẩn; các thay đổi đó không thể bị đảo ngược từng trường hợp một. Nếu một thay đổi của phiên bản mới làm hỏng một phần tùy biến, trách nhiệm làm cho module tương thích thuộc về đơn vị duy trì module đó, không thuộc về quá trình nâng cấp. Hệ quả là chất lượng của một lần nâng cấp phụ thuộc gần như toàn bộ vào chất lượng của bước nâng cấp và kiểm thử module tùy biến ở giai đoạn trước, chứ không phải vào bản thân thao tác nâng cấp cơ sở dữ liệu. Với một doanh nghiệp có nhiều module tùy biến, bước này là phần chiếm nhiều thời gian nhất trong toàn bộ quy trình, và là phần cần được lên kế hoạch sớm nhất vì nó có thể kéo dài qua nhiều vòng lặp phát hiện sự cố và sửa mã.

🗄️ Dữ liệu và filestore trong quá trình nâng cấp

Quá trình nâng cấp chuẩn xử lý dữ liệu của cơ sở dữ liệu bằng các script nâng cấp chính thức của Odoo. Ở chiều gửi, cơ sở dữ liệu được gửi lên nền tảng nâng cấp; ở chiều nhận, kết quả gồm một tệp dump.sql chứa cơ sở dữ liệu đã nâng cấp và một thư mục filestore chứa các tệp được trích ra từ các bản ghi trong cơ sở dữ liệu cùng các tệp chuẩn mới của phiên bản đích (các ảnh, icon, logo nhà cung cấp thanh toán mới). Với on-premise, do cơ sở dữ liệu được gửi lên mà không kèm filestore, bước gộp filestore đã nhận về với filestore production là bắt buộc trước khi cơ sở dữ liệu thử nghiệm có thể được kiểm thử trong điều kiện giống production. Với Odoo Online và Odoo.sh, việc này được nền tảng xử lý. Một điểm kiểm tra nằm trong danh mục kiểm thử cơ bản là việc xuất dữ liệu: dữ liệu có còn xuất được sau nâng cấp hay không, vì các tích hợp và các quy trình báo cáo ngoài hệ thống thường phụ thuộc vào việc xuất dữ liệu.

🔒 Quyền truy cập và xác thực trong môi trường thử nghiệm

Một số ràng buộc của môi trường thử nghiệm ảnh hưởng trực tiếp đến phạm vi kiểm thử. Cơ sở dữ liệu thử nghiệm chỉ có thể được tải xuống bởi người đã gửi yêu cầu, vì lý do bảo mật. Trong môi trường thử nghiệm, đồng bộ ngân hàng bị vô hiệu, và nếu cần kiểm thử đồng bộ, thông tin đăng nhập môi trường sandbox phải được lấy từ nhà cung cấp dịch vụ đồng bộ ngân hàng. Các nhà cung cấp thanh toán và đơn vị vận chuyển được đặt lại về môi trường thử nghiệm, nên các giao dịch thanh toán và vận chuyển thật không thể được kiểm thử trong môi trường này. Các ràng buộc này không phải là hạn chế của phiên bản mới mà là thiết kế cố hữu của môi trường thử nghiệm, và cách xử lý khi lên kế hoạch kiểm thử là tách các luồng có thể kiểm thử trong môi trường thử nghiệm khỏi các luồng cần được xác nhận bằng cách khác, và ghi nhận rõ phần nào của hệ thống chưa được kiểm thử trước ngày go-live.

Các Công Việc Cần Hoàn Thành Trước Khi Nâng Cấp Sản Xuất

📋 Khảo sát hiện trạng: loại lưu trữ, module tùy biến và tích hợp

Bước đầu tiên trong chuẩn bị nâng cấp là xác định ba thuộc tính của hệ thống hiện hành. Thuộc tính thứ nhất là loại lưu trữ, vì nó xác định nghĩa của các thời hạn nâng cấp và kênh thực hiện nâng cấp: Odoo Online với cơ chế phát hành lăn và thời hạn hai năm, Odoo.sh với tích hợp sẵn nền tảng nâng cấp và branch staging, hoặc on-premise với lệnh dòng lệnh và thời hạn do doanh nghiệp tự quyết. Thuộc tính thứ hai là danh sách module tùy biến: các module nào do doanh nghiệp hoặc đối tác phát triển, ai là đơn vị duy trì, và mã nguồn hiện ở phiên bản nào; đây là thuộc tính quyết định thời lượng của nhánh nâng cấp module. Thuộc tính thứ ba là danh sách các tích hợp bên ngoài: các kết nối EDI, API, đồng bộ ngân hàng, nhà cung cấp thanh toán và vận chuyển, vì các tích hợp này nằm trong phạm vi kiểm thử đầu-cuối và một số không kiểm thử được trong môi trường thử nghiệm. Kết quả của bước khảo sát là một danh sách phạm vi cho từng nhánh của quy trình, và là cơ sở để xác định thứ tự các bước tiếp theo.

🧭 Thứ tự các bước và mốc thời gian của dự án nâng cấp

Trên cơ sở kết quả khảo sát, thứ tự các bước của một dự án nâng cấp từ Odoo 19 lên Odoo 20 được tổ chức như sau. Bước một là yêu cầu cơ sở dữ liệu thử nghiệm đã nâng cấp và, song song, bắt đầu nâng cấp mã nguồn các module tùy biến nếu có. Bước hai là gộp filestore (với on-premise) và kiểm thử cơ sở dữ liệu thử nghiệm theo danh mục kiểm thử đã nêu, gồm các luồng nghiệp vụ chuẩn, các luồng có module tùy biến, các tích hợp có thể kiểm thử và việc xuất dữ liệu. Bước ba là báo cáo các vấn đề phát hiện cho Odoo và theo dõi đến khi được xử lý, đồng thời tiếp tục vòng lặp sửa mã và kiểm thử lại cho các module tùy biến. Bước bốn là yêu cầu một cơ sở dữ liệu thử nghiệm mới gần ngày go-live để xác nhận quá trình vẫn thành công với các script mới nhất, và diễn tập toàn bộ quá trình nâng cấp. Bước năm là nâng cấp production vào thời điểm sử dụng thấp nhất, và bước sáu là báo cáo các vấn đề phát sinh sau nâng cấp. Với một hệ thống không có module tùy biến, bước một rút gọn về việc yêu cầu cơ sở dữ liệu thử nghiệm và toàn bộ dự án có thể được hoàn thành trong một khoảng thời gian ngắn hơn đáng kể; với một hệ thống có nhiều module tùy biến, bước một và bước ba là các bước quyết định tổng thời lượng.

💰 Chi phí nâng cấp và các khoản công việc phát sinh

Về chi phí, các bản nâng cấp giữa các phiên bản nằm trong mức phí thuê bao của các gói dịch vụ Odoo và không thu thêm phí, theo phần công bố về những gì các gói bao gồm. Đây là khoản nằm trong chi phí giấy phép định kỳ, không phải một khoản mục phát sinh riêng trong ngân sách. Chi phí thực tế của một dự án nâng cấp nằm ở các công việc quanh quá trình nâng cấp: khối lượng nâng cấp mã nguồn các module tùy biến, khối lượng kiểm thử đầu-cuối, và khối lượng chuẩn bị dữ liệu và thời gian dừng của cơ sở dữ liệu production trong ngày go-live. Với một hệ thống vận hành hoàn toàn bằng cấu hình chuẩn, các khoản công việc này nhỏ và dự đoán được; với một hệ thống có phần tùy biến đáng kể, chúng trở thành phần chi phí chính của dự án nâng cấp và cần được ước tính từ danh sách module tùy biến và danh sách tích hợp của bước khảo sát. Việc tách chi phí nâng cấp — tức chi phí công việc quanh quá trình nâng cấp — khỏi chi phí giấy phép trong báo giá là cách để ngân sách của dự án nâng cấp phản ánh đúng thứ mà nó đang định giá.

Nâng cấp từ Odoo 19 lên Odoo 20 là một quá trình có quy trình chuẩn, có các ràng buộc rõ và có các điểm kiểm tra xác định: chu kỳ phiên bản một năm với hỗ trợ chuẩn ba năm xác định thời hạn theo loại lưu trữ, tập thay đổi của Odoo 20 được đối chiếu qua báo cáo nâng cấp và tài liệu 20.0, quy trình nâng cấp chuẩn đi qua cơ sở dữ liệu thử nghiệm trước khi chạm đến production, và phần tùy biến là điểm rủi ro chính với đặc điểm không thể đảo ngược. Ba quyết định ảnh hưởng lớn nhất đến kết quả của một lần nâng cấp là thời điểm yêu cầu cơ sở dữ liệu thử nghiệm, chất lượng của nhánh nâng cấp module tùy biến, và phạm vi kiểm thử trước ngày go-live. Với Odoo 20 vừa phát hành vào khoảng tháng 9 năm 2026 và Odoo 19 còn trong hỗ trợ chuẩn đến tháng 9 năm 2028, cửa sổ nâng cấp giữa hai phiên bản này mở ra trong một khoảng thời gian đủ dài để một dự án nâng cấp được chuẩn bị theo đúng quy trình thay vì theo áp lực thời hạn.

Đối với các doanh nghiệp đang vận hành Odoo 19 tại Việt Nam, bước tiếp theo là khảo sát hiện trạng theo ba thuộc tính đã nêu — loại lưu trữ, danh sách module tùy biến, danh sách tích hợp — và từ đó xác định thứ tự các bước của dự án nâng cấp. SkyERP cung cấp dịch vụ tư vấn và triển khai Odoo tại Việt Nam, bao gồm nâng cấp phiên bản, nâng cấp module tùy biến, kiểm thử đầu-cuối và hỗ trợ trong giai đoạn sau nâng cấp. Để nhận tư vấn về lộ trình nâng cấp từ Odoo 19 lên Odoo 20 phù hợp với hiện trạng hệ thống, liên hệ qua https://skyerp.net/contactus.