Twoja wersja jest starsza, niż ci się wydaje
Odoo wydaje nową wersję główną co roku i wspiera tylko trzy najnowsze. Ta arytmetyka nie wybacza: jeśli uruchomiłeś produkcję na Odoo 15 w 2022 roku, od dłuższego czasu pracujesz na oprogramowaniu bez wsparcia. Odoo 16 wypadło z okna wsparcia wraz z premierą dziewiętnastki. Odoo 17 jest następne w kolejce.
Brak wsparcia nie znaczy, że coś jest zepsute. System jutro rano nadal przetworzy zamówienia. Znaczy natomiast:
- Brak poprawek bezpieczeństwa. Luki znalezione w rdzeniu pozostają otwarte na twojej instancji.
- Brak poprawek błędów. Cokolwiek się zepsuje, staje się problemem twojego zespołu deweloperskiego — albo naszego.
- Dopłata za starą wersję. Klientom Enterprise na wersjach spoza wsparcia może zostać naliczona dodatkowa opłata do abonamentu — najczęściej podawana jako 25%.
- Kurczący się ekosystem modułów. OCA i zewnętrzni deweloperzy przestają backportować. Nowi dostawcy płatności, przepisy o e-fakturowaniu i aktualizacje lokalizacji trafiają wyłącznie do bieżących wersji.
- Rozjazd z przepisami. To zwykle ten punkt wymusza decyzję w europejskich firmach. Obowiązki e-fakturowania, formaty deklaracji VAT i krajowe wymogi podatkowe dostarczane są w aktualizacjach lokalizacji — a te celują we wspierane wersje.
Im większa luka, tym droższy skok. Migracja z 18 na 19 to projekt. Migracja z 14 na 19 to przebudowa z zachowaniem danych.
Migrować do 19 teraz czy czekać na Odoo 20?
Uczciwe pytanie, skoro Odoo 20 spodziewane jest jesienią 2026. Odpowiedź zależy od punktu wyjścia:
Jesteś na 14, 15 lub 16 — przejdź na 19 teraz. Już jesteś poza wsparciem, a każdy miesiąc dokłada ryzyka. Odoo 19 działa produkcyjnie od września 2025, wersja jest stabilna, ekosystem modułów nadrobił zaległości, a wsparcie sięga obecnie mniej więcej września 2028. To dwa spokojne lata, zanim znów trzeba będzie o tym myśleć.
Jesteś na 17 — zaplanuj migrację na ten rok. Jesteś na krawędzi okna wsparcia. Przejście na 19 daje najdłuższy zapas przy tym samym nakładzie pracy.
Jesteś na 18 — nie ma pośpiechu. Oceń nowości dziewiętnastki pod kątem swojej mapy drogowej i rozważ przeskok od razu na 20 w przyszłym roku.
Odruch „poczekajmy na najnowszą" zwykle się mści. Wersja wydana miesiąc temu ma najsłabsze pokrycie modułami zewnętrznymi i najwięcej ostrych krawędzi. Migracja do wersji o jedną za czołówką jest niemal zawsze tańszym i spokojniejszym wyborem.
Dwie bardzo różne ścieżki: Enterprise i Community
To miejsce, w którym najczęściej źle szacuje się budżety migracji, więc powiedzmy wprost.
Klienci Odoo Enterprise mają dostęp do oficjalnej usługi aktualizacji Odoo. Przesyłasz bazę danych, platforma zwraca ją przekonwertowaną do wersji docelowej, a skoczyć można z dowolnej wersji prosto na 19, bez przechodzenia przez pośrednie. Usługa jest wliczona w ważny abonament i działa dobrze — dla standardowego kodu.
Odoo Community nie ma odpowiednika. Nie istnieje ani oficjalny kreator aktualizacji, ani ścieżka „jednym kliknięciem". Realne opcje to:
- OpenUpgrade — projekt OCA dostarczający skrypty migracyjne. Obsługuje zmiany schematu i transformację danych, ale uruchamia się go wersja po wersji, a kod niestandardowy i tak wymaga ręcznej pracy.
- Zewnętrzne narzędzia migracyjne — kilku dostawców łączy dziś kroki wersji automatycznie.
- Czysta instalacja z eksportem/importem danych — czasem pragmatyczna odpowiedź przy małych bazach z niewielką liczbą transakcji, ale tracisz dane historyczne, jeśli eksport nie zostanie starannie zaplanowany.
Którąkolwiek ścieżkę wybierzesz, jedno pozostaje niezmienne: Odoo migruje własny kod, nie twój. Moduły niestandardowe zawsze pozostają twoją odpowiedzialnością.
Co faktycznie się psuje
Między wersją 16 a 19 skumulowane zmiany liczy się w setkach zmian modeli, dziesiątkach zmian nazw modeli, scaleniach modułów, zmianach nazw pól i zmianach ograniczeń. W praktyce uderza to w cztery obszary:
Moduły niestandardowe. Wycofane API, usunięte metody, przebudowane widoki XML, zmienione reguły uprawnień. Każdy własny model, dziedziczony widok i raport wymaga przeglądu. To niemal zawsze największa pozycja w budżecie migracji — i jest to zwykła praca deweloperska, której żaden skrypt nie załatwi.
Moduły zewnętrzne i OCA. Zanim zrobisz cokolwiek innego, zinwentaryzuj każdy zainstalowany moduł i sprawdź, czy istnieje gałąź dla 19. Czasem moduł został wchłonięty do rdzenia Odoo — to dobra wiadomość. Czasem jest porzucony i potrzebujesz zamiennika albo przepisania od nowa.
Integracje. Sklepy internetowe, bramki płatnicze, skanery magazynowe, zewnętrzne API, narzędzia BI. Wszystko, co rozmawia z Odoo przez XML-RPC lub REST, trzeba przetestować względem nowego schematu — zmienione nazwy pól psują integracje po cichu.
Raporty i dokumenty drukowane. Szablony QWeb zmieniają się między wersjami. Faktury, dokumenty WZ i etykiety należy sprawdzić wizualnie strona po stronie, a nie zakładać, że działają.
Migracja, która nie boli
Proces, który stosujemy przy każdym projekcie aktualizacji:
1. Audyt. Pełna inwentaryzacja zainstalowanych modułów, dostosowań, integracji i wielkości bazy. Stąd bierze się realna wycena — i tu zwykle znajdujemy moduły, których nikt nie otwierał od trzech lat. Odinstalowanie balastu to najtańsza praca migracyjna, jaką kiedykolwiek wykonasz.
2. Migracja testowa. Odtwarzasz kopię produkcji na serwerze testowym i tam uruchamiasz aktualizację. Produkcja pozostaje nietknięta. Ten przebieg mówi, ile trwa konwersja — a to na tej liczbie budujesz okno przestoju.
3. Dostosowanie kodu. Moduły niestandardowe są portowane na 19, w systemie kontroli wersji, równolegle do prac nad bazą. Moduły zewnętrzne są wymieniane lub aktualizowane.
4. Testy z prawdziwymi ludźmi. Nie tylko „czy się uruchamia" — pełne cykle biznesowe. Od oferty do zapłaty. Od zakupu do płatności. Od zlecenia produkcyjnego do ruchu magazynowego. Zamknięcie miesiąca. Posadź księgową i kierownika magazynu przed systemem testowym — znajdą rzeczy, których deweloper nigdy nie zobaczy.
5. Przełączenie i wsparcie. Świeża kopia zapasowa, finalna migracja, uruchomienie w zaplanowanym oknie — zwykle w weekend. Potem bliskie wsparcie przez pierwsze dni, gdy użytkownicy spotykają zmieniony interfejs i wychodzą drobiazgi.
Terminy i co napędza koszty
Mała baza z niewielką liczbą dostosowań: zwykle 4–8 tygodni od początku do końca. Średnia firma z rozbudowanymi dostosowaniami, kilkoma integracjami i latami danych transakcyjnych: 3–6 miesięcy.
Sama konwersja bazy jest często najszybszą częścią — baza poniżej 1 GB potrafi się przekonwertować w kilka minut. O koszcie decyduje objętość dostosowań, liczba integracji, przez ile wersji przeskakujesz i ile testów wymagają twoje procesy biznesowe. Nie wielkość danych.
Błędy, które widzimy raz za razem
- Migracja bez audytu. Nie da się zabudżetować czegoś, czego się nie zinwentaryzowało.
- Pominięcie migracji testowej. Odkrycie, że konwersja trwa sześć godzin w trakcie okna wdrożenia, to bardzo zła sobota.
- Traktowanie tego jak projektu IT. Migracja to przegląd procesów biznesowych. Użytkownicy muszą zobaczyć nową wersję przed uruchomieniem, a nie w poniedziałek rano.
- Przenoszenie martwych dostosowań. Połowa własnego kodu w starej instancji Odoo rozwiązuje problemy, które standardowe Odoo obsługuje już natywnie. Migracja to właściwy moment, żeby go usunąć.
- Brak planu wycofania. Przetestowana procedura odtworzenia, a nie samo „mamy kopie zapasowe".
Od czego zacząć
Jeśli jesteś na 14, 15, 16 lub 17, pierwszym sensownym krokiem nie jest wybór narzędzia — tylko ustalenie, co faktycznie masz. Audyt modułów, dostosowań i integracji zamienia „chyba kiedyś trzeba będzie zaktualizować" w konkretny projekt z realnym harmonogramem i realną kwotą.
Prowadzimy migracje Odoo od początku do końca: audyt, portowanie modułów niestandardowych, migracje testowe, przełączenie i wsparcie po uruchomieniu — zarówno dla Community, jak i Enterprise, on-premise i na Odoo.sh.
Umów bezpłatną konsultację , a powiemy szczerze, jak wygląda twoja aktualizacja — również wtedy, gdy odpowiedź brzmi „poczekaj rok".