Utrzymanie sklepu Magento: daty wsparcia i budżet

Ten tekst ma dać Ci jedną prostą odpowiedź: czy Twój sklep jest jeszcze łatany. Potem pokazujemy, co z tej odpowiedzi wynika dla kosztów, co realnie kładzie sklepy na Magento i jak wygląda uczciwy budżet na opiekę. Jeżeli po przeczytaniu sam sprawdzisz wersję i sam zdecydujesz, co dalej, tekst zrobił swoje.

Daty, od których wszystko się zaczyna

Polityka cyklu życia Adobe Commerce jest prosta: trzy lata wsparcia standardowego od daty GA, a dla części wersji dodatkowo okres wsparcia rozszerzonego. Poniżej terminy, które mają dziś znaczenie.

Dziś jest wrzesień 2026, więc wnioski są krótkie. Jeżeli Twój sklep stoi na 2.4.5, minął nie tylko koniec wsparcia standardowego, ale także koniec wsparcia rozszerzonego (11.08.2026). To wersja, która nie dostaje już nowych łatek bezpieczeństwa, a każda kolejna publicznie opisana podatność zostaje z Tobą na stałe. Jeżeli stoisz na 2.4.6, wsparcie standardowe skończyło się 11.08.2026, ale masz jeszcze wsparcie rozszerzone do 31.08.2027. To jest Twoje okno na zaplanowaną, spokojną aktualizację Magento, a nie na odkładanie tematu.

Jeżeli pracujesz na 2.4.7 lub 2.4.8, jesteś w komfortowej sytuacji i decyzję o kolejnym kroku podejmujesz na chłodno, odpowiednio przed 31.05.2027 i 31.05.2028.

Osobna sprawa to Magento Open Source. Ta edycja nie ma wsparcia komercyjnego i nie ma w tej polityce własnych, osobno publikowanych terminów. W praktyce oznacza to zależność od łatek przygotowywanych przez społeczność i od tego, czy ktoś po Twojej stronie je śledzi i wdraża. Nie przenoś na Open Source dat z tabeli powyżej, bo to inny model.

Jak w pięć minut sprawdzić, na czym stoisz

Nie potrzebujesz do tego dostawcy ani audytu. Wystarczą trzy ruchy.

Pierwszy: panel administracyjny. Numer wersji jest widoczny w stopce panelu, po zalogowaniu. To wynik w piętnaście sekund i w większości przypadków wystarczy.

Drugi: plik composer.json w katalogu aplikacji, a dokładniej composer.lock. Tam widać nie tylko wersję rdzenia, ale też listę modułów firm trzecich i ich wersje. Jeżeli nie masz dostępu do serwera, poproś o zrzut tego pliku. To jedno pytanie mailem.

Trzeci: pytanie do obecnego dostawcy, zadane tak, żeby nie dało się odpowiedzieć ogólnikiem. Brzmi ono: która dokładnie wersja jest na produkcji, kiedy ostatnio wgraliście łatkę bezpieczeństwa i czy była wcześniej testowana na środowisku testowym. Jeżeli odpowiedź nie zawiera numeru wersji i daty, nie jest odpowiedzią.

Dlaczego utrzymanie Magento kosztuje więcej niż WooCommerce czy PrestaShop

To nie jest kwestia marży, tylko trzech różnic technicznych.

Infrastruktura. Obok samej aplikacji stoi kilka usług, które muszą działać i muszą być pilnowane: wyszukiwarka, warstwa cache, kolejki komunikatów i harmonogram zadań cron. W sklepie na WooCommerce awaria to najczęściej awaria jednego procesu. W Magento to kilka miejsc, w których coś może się zatrzymać niezależnie od strony, którą widzi klient.

Kompetencje. Obsługa Magento to praca dla programisty, nie dla administratora treści. Czynności, które gdzie indziej sprowadzają się do kliknięcia w panelu, tutaj oznaczają zmianę w kodzie, przeliczenie indeksów i wdrożenie. Stawka za godzinę jest ta sama, ale pula osób, które mogą tę godzinę przepracować, jest znacznie węższa.

Czas wdrażania zmian. W Magento nie zmienia się rzeczy na produkcji. Jest środowisko testowe, jest procedura wdrożenia i są testy regresji, bo zmiana w jednym module potrafi wywrócić koszyk. Ta sama pozornie drobna poprawka zajmuje więcej godzin niż na PrestaShop, i to jest najczęstsze źródło zaskoczenia przy pierwszym rozliczeniu. Rozpisaliśmy to szerzej we wpisie o tym, ile kosztuje utrzymanie sklepu internetowego.

Co realnie kładzie sklepy na Magento

Poniżej pięć rzeczy, które w naszej praktyce powodują najwięcej zgłoszeń. Podajemy objaw, przyczynę i rząd wielkości czasu przywrócenia. To obserwacja z pracy, nie deklaracja czasu naprawy, bo czasu usunięcia awarii nie da się uczciwie obiecać z góry.

Zatrzymane kolejki i crony. Objaw jest mylący, bo sklep wygląda na sprawny: strona się otwiera, zamówienia się składają, ale nie wychodzą do ERP, nie lecą maile transakcyjne, nie aktualizują się stany. Przyczyną bywa zabity proces konsumenta kolejki albo wyłączony harmonogram po restarcie serwera. Rząd wielkości przywrócenia: od kilkudziesięciu minut do kilku godzin, przy czym najdłużej trwa nie restart, tylko rozliczenie zaległych zdarzeń.

Pełny dysk i logi. Objaw: sklep zaczyna zwracać błędy zapisu, panel przestaje reagować. Przyczyna jest zwykle banalna, czyli logi debugowania włączone kiedyś przy wdrożeniu i nigdy nie wyłączone. Rząd wielkości: od kilkunastu minut do godziny, o ile ktoś patrzy na wolne miejsce zanim skończy się całkiem.

Przeindeksowanie i cache po wdrożeniu. Objaw: po wgraniu zmian sklep pokazuje stare ceny, puste kategorie albo rozjechany wygląd. Przyczyna to nieprzeliczone indeksy lub nieprzebudowana zawartość statyczna. Rząd wielkości: od kilkudziesięciu minut do kilku godzin, zależnie od wielkości katalogu.

Moduły firm trzecich niezgodne z wersją. Objaw pojawia się najczęściej zaraz po aktualizacji: błąd 500 na konkretnym kroku koszyka albo w panelu. Przyczyna to moduł, który nie deklaruje zgodności z nową wersją rdzenia. Rząd wielkości: od kilku godzin do kilku dni, bo często trzeba czekać na wydanie od producenta modułu albo napisać obejście.

Integracje płatności. Objaw: płatność się rozpoczyna i nie wraca statusem, zamówienie zostaje w stanie oczekującym. Przyczyna to zmiana po stronie operatora, wygasły certyfikat albo klucz. Rząd wielkości: od kilkudziesięciu minut do kilku godzin, z tym że część czasu jest poza nami, po stronie operatora. O tym, ile taki przestój kosztuje w pieniądzu, piszemy we wpisie o koszcie przestoju sklepu internetowego.

Co powinno wchodzić w miesięczną opiekę nad sklepem Adobe Commerce

Minimum, którego warto wymagać od każdego dostawcy, także od nas.

Łatki bezpieczeństwa w ustalonym reżimie. U nas aktualizacje krytyczne wchodzą w 72 godziny, pozostałe w 14 dni, zawsze najpierw na środowisku testowym. Bez tego ostatniego warunku szybkie łatanie jest ryzykiem, a nie usługą.

Monitoring tego, co naprawdę może się zatrzymać. Sprawdzanie strony głównej co 60 sekund jest potrzebne, ale w Magento niewystarczające. Pilnować trzeba kolejek, cronów i tego, czy zdarzenia wychodzą na zewnątrz, bo to tam zaczyna się większość cichych awarii.

Kopie zapasowe z testem odtworzenia. Kopia, której nikt nie odtworzył, jest założeniem, nie zabezpieczeniem. W pakiecie podstawowym robimy kopie co 7 dni i test odtworzenia raz na kwartał.

Przegląd logów. Regularne czytanie logów aplikacji jest nudne i jest jedynym sposobem, żeby zobaczyć problem zanim zobaczy go klient.

Budżet: trzy profile sklepu

Profil pierwszy: sklep na 2.4.7 lub 2.4.8, kilka integracji, katalog do kilku tysięcy indeksów, zmiany zlecane rzadko. Realny pakiet to Advanced za 1 900 zł miesięcznie z pulą 20 godzin. To wystarcza na łatki, drobne zmiany i obsługę zgłoszeń.

Profil drugi: sklep na 2.4.6, przed aktualizacją, z kilkunastoma modułami firm trzecich i integracją z ERP. Tu pula 20 godzin skończy się w miesiącu, w którym wejdzie aktualizacja. Realny pakiet to Premium za 3 800 zł miesięcznie z pulą 40 godzin.

Profil trzeci: sklep na 2.4.5, czyli poza wsparciem, z własnymi modułami. Zanim w ogóle rozmawiamy o abonamencie, potrzebny jest plan wyjścia z tej wersji, bo miesięczna opieka nie rozwiąże problemu braku łatek.

Uczciwe zastrzeżenie: sklep na Magento rzadko mieści się w pakiecie Basic za 950 zł z pulą 10 godzin. Dziesięć godzin miesięcznie w tej platformie potrafi zniknąć na jednym wdrożeniu z testami regresji. Jeżeli ktoś proponuje Ci Magento za 950 zł, zapytaj, co się stanie po wyczerpaniu puli. Godzina w pakiecie kosztuje u nas 95 zł, godzina ponad pulę 150 zł, i to jest cała różnica.

Nadzór nad dostępnością liczymy osobno, bo to inna usługa niż pula godzin na Twoje zlecenia. Poziom Podstawowy zaczyna się od 890 zł. Przy Magento zwykle wchodzi poziom Rozszerzony za 2 400 zł i powód jest konkretny: monitorować trzeba nie jeden adres, tylko kolejki, crony i procesy w tle, a diagnostyka przy zdarzeniu krytycznym wymaga człowieka znającego tę platformę. Dyżur w trybie ciągłym mamy wyłącznie na najwyższym poziomie SLA. Różnicę między wsparciem technicznym a nadzorem nad dostępnością rozkładamy na części we wpisie o tym, czy potrzebujesz wsparcia technicznego czy SLA.

Aktualizacja czy migracja na inną platformę

To pytanie warto postawić uczciwie, zwłaszcza gdy stoisz na wersji bez wsparcia. Nie będziemy Cię przekonywać do migracji, bo migracja z Magento jest droga, długa i w połowie przypadków kończy się odtworzeniem tych samych problemów gdzie indziej. Zamiast tego trzy kryteria.

Pierwsze: policz koszt utrzymania w skali roku, czyli abonament razy dwanaście plus godziny ponad pulę plus hosting. Dopiero ta liczba, a nie faktura za jeden miesiąc, daje się porównać z czymkolwiek.

Drugie: sprawdź, ile funkcji Twojego sklepu jest naprawdę specyficznych. Jeżeli masz złożone cenniki B2B, wiele magazynów i twardą integrację z ERP, Magento robi robotę, za którą płacisz. Jeżeli sklep jest w istocie prostym katalogiem z płatnością, płacisz za możliwości, których nie używasz.

Trzecie: zapytaj, czy Twój zespół umie z tej platformy korzystać. Magento wymaga po stronie klienta kogoś, kto rozumie różnicę między indeksem a cache i nie boi się panelu. Jeżeli takiej osoby nie ma i nie będzie, każda zmiana będzie kupowana na godziny, a to jest realny składnik rachunku.

Jeżeli dwa z trzech kryteriów wypadają na korzyść Magento, zostań i zaplanuj aktualizację. Jeżeli żadne, rozmowa o migracji jest zasadna, ale to temat na osobny projekt, nie na aneks do umowy utrzymaniowej.

Zacznij od przeglądu wersji i stanu technicznego. Sprawdzamy, na jakiej wersji stoi sklep, kiedy ostatnio dostał łatki, czy kolejki i crony działają, i przekazujemy listę rzeczy do zrobienia z oszacowaniem godzin. Napisz przez /pl/sla-help-desk, a odpowiemy, czy w Twoim przypadku wystarczy pula godzin, czy potrzebny jest też nadzór nad dostępnością.