Чому оновлюватися зараз: статус підтримки
Кожна мажорна версія Odoo має три роки стандартної підтримки — єдиний період з оновленнями безпеки. Далі йде розширена підтримка: платна і лише на Odoo.sh та on-premise. Статус за політикою підтримки Odoo на листопад 2026:
| Версія | Реліз | Стандартна підтримка до | Статус зараз |
|---|---|---|---|
| 16.0 | жовтень 2022 | вересень 2025 | Лише розширена підтримка (платна, Odoo.sh / on-premise) |
| 17.0 | листопад 2023 | вересень 2026 | Лише розширена підтримка (платна, Odoo.sh / on-premise) |
| 18.0 | жовтень 2024 | вересень 2027 (план) | Стандартна підтримка |
| 19.0 | вересень 2025 | вересень 2028 (план) | Стандартна підтримка |
| 20.0 | вересень 2026 | вересень 2029 (план) | Стандартна підтримка |
Для клієнтів Enterprise є ще дві причини. На Odoo Online мажорне оновлення обов'язкове раз на два роки (документація з оновлення). А угода про підписку Enterprise визначає підтримувані версії як три останні мажорні; з клієнтів на старішій версії Odoo може стягувати додаткову плату — 25% річної вартості підписки. Community на власному сервері може лишатися на будь-якій версії скільки завгодно, але без виправлень безпеки.
Odoo 19 чи одразу Odoo 20?
Odoo дозволяє оновлюватися до будь-якої мажорної версії зі стандартною підтримкою. На момент написання (листопад 2026) дві обставини роблять 19 практичною ціллю для баз із кастомними модулями:
- Форма на upgrade.odoo.com пропонує 19.0 як найновішу цільову версію, а гілка OCA OpenUpgrade 20.0 ще не містить скриптів міграції.
- Odoo 20 змінює більше технічного фундаменту: права доступу й правила записів об'єднано в одну модель, вебклієнт переходить на OWL 3 без jQuery, групи рахунків замінено батьківськими рахунками. Кожен кастомний модуль потребує більше роботи з портування.
Розумний план — перейти на 19 зараз, а 20 зробити окремим, пізнішим кроком. Odoo 18 теж можлива ціль, але в неї найменше підтримки попереду (до вересня 2027).
Enterprise: сервіс оновлення Odoo
- Входить в Enterprise разом із підтримкою для виправлення розбіжностей в оновленій базі.
- Версії можна пропускати: 16.0 → 19.0 — один запит на оновлення (приклад самої Odoo — 16.0 → 18.0).
- Будь-який хостинг: Odoo Online (менеджер баз), Odoo.sh (вкладка Upgrade і staging-гілка) та on-premise командою
python <(curl -s https://upgrade.odoo.com/upgrade) test -d <db> -t 19.0, потімproductionзамістьtest. - Спершу тест: тестова база нейтралізована (заплановані дії вимкнено, вихідна пошта йде на фіктивний сервер, платіжні провайдери в тестовому режимі), приходить без filestore і з звітом про оновлення. Таких баз можна запросити скільки потрібно.
- Кастомний код — ваша відповідальність: базу з кастомними модулями «неможливо оновити, доки немає версії ваших модулів для цільової версії Odoo». Власні та сторонні модулі без контракту на супровід, чистка даних і навчання не покриваються.
Community: OCA OpenUpgrade
Скрипти оновлення Odoo закриті. Для Community відкритий шлях — OpenUpgrade від Odoo Community Association (OCA):
- По одній версії: пропускати версії не можна. З 16 на 19 — це три запуски: гілки 17.0, 18.0 і 19.0.
- 19.0 активна: базові застосунки — бухгалтерія, продажі, закупівлі, склад, виробництво, CRM, проєкти, співробітники, сайт, eCommerce і POS — позначено готовими в її списку покриття, але сотні модулів ще без статусу (серед них український
l10n_ua). Перевірте кожен модуль, яким користуєтеся. - 20.0 не готова: гілка існує, але скриптів міграції ще немає (листопад 2026).
- Запускаєте самі на копії бази й закриваєте прогалини власними скриптами міграції.
Для невеликої бази або бази з «брудною» історією нова база Odoo 19 з перенесенням довідників і відкритих залишків може коштувати менше, ніж три послідовні запуски OpenUpgrade. Вирішуйте після пробного запуску, а не до нього. Перенесення даних у чисту базу — це наша послуга міграції на Odoo.
Що ламається в кастомних модулях
Гайд Odoo з портування перелічує типові помилки встановлення: невалідні залежності, зміни синтаксису (assets, OWL, attrs), перейменовані чи видалені поля, моделі й в'юхи, XPath, ціль якого перемістилась, перейменовані методи. Основні зміни, перевірені в коді Odoo та changelog ORM:
| Крок | Що змінюється для кастомного коду |
|---|---|
| 16 → 17 | attrs і states прибрано з в'юх (замість них вирази invisible / readonly / required); name_get() застарів на користь display_name; нова сигнатура _read_group(); Python 3.10+. |
| 17 → 18 | в'юхи <tree> стають <list> (view_mode «list,form»); name_get() видалено; group_operator перейменовано на aggregator; check_access_rights() / check_access_rule() замінено на check_access() / has_access(); account.account отримує company_ids замість company_id. |
| 18 → 19 | <group expand> більше не валідний у пошукових в'юхах; _sql_constraints замінено на models.Constraint; read_group(), odoo.osv, record._cr / _uid / _context і маршрути type="json" застаріли; договори співробітників об'єднано з Employees. |
| 19 → 20 | права доступу й правила записів об'єднано в ir.access (ir.access.csv); групи рахунків замінено батьківськими рахунками; odoo.osv, аліас group_operator і старі методи перевірки доступу видалено; OWL 3 і без jQuery; Python 3.12+ і PostgreSQL 16. |
Застарілі API зазвичай ще версію-дві працюють з попередженнями, а потім зникають. Виправляйте їх під час портування, інакше наступне оновлення почнеться з боргу.
Покроковий план оновлення
За гайдом Odoo з оновлення кастомізованої бази:
- Заморозьте й перегляньте кастомізації. Зупиніть нову розробку, порівняйте кожну кастомну функцію з тим, що вже вміє стандартна Odoo 19, і приберіть зайвий код.
- Зробіть тестове оновлення (сервіс оновлення або OpenUpgrade на копії), щоб переконатися, що стандартна частина конвертується чисто.
- Портуйте кастомні модулі на порожній базі Odoo 19: встановлюйте по одному, виправляйте трейсбеки й попередження, перевіряйте в'юхи, звіти, шаблони листів, серверні та автоматичні дії.
- Запустіть їх на оновленій базі: напишіть pre- і post-скрипти міграції (бібліотека Odoo
upgrade-utilперейменовує поля, моделі й XML ID) і знову увімкніть в'юхи, які оновлення вимкнуло, — їх перелічено у звіті про оновлення. - Тестуйте й репетируйте: запитуйте свіжі тестові бази в процесі й зробіть повну репетицію перед запуском.
- Оновіть продакшн у тихий час. Під час оновлення база недоступна, а зміни після створення дампу не переносяться. Об'єднайте отриманий filestore з робочим.
Чекліст тестування
Документація Odoo з оновлення радить перевірити щонайменше:
- В'юхи, особливо ті, що вимкнені в тестовій базі.
- Звіти й друковані документи, сторінки сайту та шаблони листів.
- Створення й редагування записів, переклади, збережені фільтри та експорти.
- Інтеграції (EDI, API), автоматичні та серверні дії.
- Щонайменше один наскрізний процес: закупівля → надходження → продаж → відвантаження → рахунок → кредит-нота → бухгалтерські звіти → замовлення eCommerce.
Від чого залежить обсяг робіт
Універсальної ціни оновлення немає. Головні чинники:
- Кількість і розмір кастомних модулів та те, яку їхню частину тепер замінює стандартна Odoo 19.
- Чи є для Odoo 19 кожен сторонній модуль, яким ви користуєтеся (OCA, Odoo Apps).
- Скільки версій ви перетинаєте: один запит на Enterprise, один запуск OpenUpgrade на кожну версію в Community.
- Інтеграції з іншими системами, обсяг і якість даних.
Пробне оновлення плюс інвентаризація модулів дають надійну оцінку. Оновлення версій входять у нашу підтримку Odoo, а портування кастомних модулів — це розробка під замовлення. Якщо ви ще обираєте редакцію, читайте Community чи Enterprise; про нове в Odoo 20 — AI-функції Odoo 20.