# Koniec wsparcia Magento Open Source: kompletny przewodnik po decyzji, którą musisz podjąć w 2026 Adobe nie wyłącza Magento jutro — ale dla Open Source wsparcie rozszerzone nigdy nie istniało. Realna oś czasu, koszty, polskie integracje, plan migracji i czwarta opcja, o której nikt nie mówi. **Canonical:** https://spoko.space/pl/blog/koniec-magento-open-source/ **Language:** pl **Published:** 2025-12-01 **Updated:** 2026-05-01 **Tags:** Magento, Adobe Commerce, Mage-OS, e-commerce, migracja, SEO **Category:** E-commerce --- W ostatnich tygodniach LinkedIn zaczął puchnąć od grafik z piaskiem przesypującym się przez klepsydrę i hasłem **„End of support risk”**. Brzmi alarmistycznie, więc warto rozdzielić to, co prawda, od marketingowego skrótu — i pokazać konkretne opcje, jakie ma właściciel sklepu w Polsce. Pracuję głównie na Laravelu i nowoczesnym JS-ie, ale Magento ma w polskim e-commerce status, którego nie da się ignorować. Dziesiątki projektów, z którymi miałem styczność, działają dziś na 2.4.x. Pisanie tego tekstu zaczęło się od pytania jednego klienta: *„Czy ja w ogóle muszę coś z tym robić, czy to typowy FUD agencji?”*. Krótka odpowiedź: musisz, ale niekoniecznie tak, jak Ci to sprzedają. Ten tekst jest długi z premedytacją. Decyzja, którą musisz podjąć, kosztuje od kilkudziesięciu do kilkuset tysięcy złotych i ma pięcioletnie konsekwencje. Skróty marketingowe nie pomagają. --- ## Krótka historia: jak doszliśmy do „końca Magento” Żeby zrozumieć, co się teraz dzieje, warto cofnąć się o kilka lat — bo decyzje sprzed dekady nadal kształtują dzisiejszy krajobraz. **2008** — Roy Rubin i Yoav Kutner wydają Magento 1 jako open source. W ciągu kilku lat staje się dominującą platformą e-commerce dla średnich i dużych sklepów. eBay kupuje Magento w 2011, sprzedaje w 2015 funduszowi Permira. **2015** — startują prace nad Magento 2. Zupełnie nowy core, niekompatybilny z 1.x. Marketing mówi o „modernizacji”; programiści wiedzą, że to praktycznie nowa platforma. **2018** — **Adobe kupuje Magento za 1,68 mld USD**. Punkt zwrotny. Magento staje się trzonem Adobe Experience Cloud, obok Marketo i AEM. Strategiczna intencja jest jasna: budować enterprise stack dla Fortune 500. **2020** — koniec wsparcia Magento 1. Setki tysięcy sklepów zostają z platformą, która nie dostaje już łatek. Ten moment ukształtował dzisiejszą paranoję rynku — bo wiele firm pamięta, ile kosztowała migracja 1 → 2. **2021** — grupa członków społeczności publikuje [otwarty list](https://www.hyva.io/blog/news/the-future-of-magento-open-source.html) i zapowiada **Mage-OS**, niezależny społecznościowy fork. To reakcja na coraz wyraźniejszy zwrot Adobe ku enterprise i obawę, że Open Source dostanie status „legacy”. **2022–2024** — Adobe redefiniuje stack: PWA Studio wchodzi w maintenance mode, pojawiają się Edge Delivery Services, Commerce Drop-ins, App Builder. Wszystko to działa wyłącznie na Adobe Commerce / Cloud. Magento Open Source dalej dostaje wydania, ale realny rozwój przesuwa się w stronę płatnych komponentów. **2025–2026** — kończy się wsparcie podstawowe dla 2.4.4 i 2.4.5. Magento 2.4.8 jest ostatnim wydaniem z planowanym długim wsparciem. W tle Mage-OS przyspiesza: 2.0 w październiku 2025, 3.0 planowany na maj 2026. To nie jest historia „Adobe wyłącza Magento”. To historia powolnego rozdzielania się dwóch ścieżek: komercyjnej (gdzie idą inwestycje) i open source (gdzie społeczność samodzielnie utrzymuje projekt). Klepsydra na infografikach jest realna, ale niedosłowna. --- ## Co właściwie ogłosiło Adobe — oficjalna oś czasu Adobe nie wydało jednego „ogłoszenia o końcu Magento Open Source”. Tutaj nie ma żadnej daty zamknięcia projektu. Jest natomiast **lifecycle policy** (polityka cyklu życia) — i to ona generuje cały szum. Oficjalne daty zakończenia wsparcia podstawowego (regular support) dla poszczególnych linii: | Wersja | Data wydania | Wsparcie podstawowe — koniec | Wsparcie rozszerzone — koniec | |---|---|---|---| | 2.4.4 | kwi 2022 | 12 kwi 2025 | 14 kwi 2026 | | 2.4.5 | sie 2022 | 12 sie 2025 | 11 sie 2026 | | 2.4.6 | mar 2023 | 11 sie 2026 | 30 sie 2027 | | 2.4.7 | kwi 2024 | 31 maj 2027 | TBD | | **2.4.8** | kwi 2025 | **31 maj 2028** | TBD | Magento 2.4.8 jest aktualnie ostatnim wydaniem z planowanym długim wsparciem. Wszystko po tej dacie jest niewiadomą — Adobe sygnalizuje, że Magento 2.4.9 pojawi się w okolicach maja 2026, ale **żadnego Magento 3 nie ma w planach**. To nie jest „koniec Magento jutro”. To jest powolne kurczenie się okna, w którym Twój sklep dostaje oficjalne łatki bezpieczeństwa. --- ## Niuans, którego nie pokazują infografiki: Open Source ma gorzej niż Adobe Commerce Tu jest pułapka, którą połowa publikowanych dziś materiałów pomija. W tabeli powyżej kolumna *Wsparcie rozszerzone* (extended support) dotyczy **wyłącznie Adobe Commerce**. Adobe pisze to wprost w dokumentacji: > *Extended support is available to Adobe Commerce customers only. It is not available for the Magento Open Source code base.* To samo z dodatkowymi łatkami bezpieczeństwa dla 2.4.4 i 2.4.5 — **tylko płacący klienci Adobe Commerce** dostali poprawki bezpieczeństwa po końcu wsparcia podstawowego. Dla Magento Open Source koniec wsparcia podstawowego = realny koniec łatek od Adobe. Innymi słowy: jeśli prowadzisz sklep na Magento Open Source 2.4.6, **nie masz „miękkiego lądowania”** w postaci roku wsparcia rozszerzonego. 11 sierpnia 2026 oficjalne łatki znikają. To zmienia całą ramę dyskusji. Marketing Adobe sugeruje, że dyskusja jest między „upgrade do Magento 2.4.8” a „przejdź na Adobe Commerce”. W rzeczywistości dla większości polskich sklepów na Open Source pytanie brzmi: *„co robię, gdy dla mojej wersji nikt już oficjalnie nie wyda łatki?”*. Drugi, mniej widoczny niuans: nie każda funkcja Magento Open Source jest tym samym kodem co Adobe Commerce. Część modułów (B2B, Page Builder w pełnej wersji, advanced reporting, Live Search, Product Recommendations) to **commercial-only**. Sklep, który próbuje „przejść z Open Source na Adobe Commerce”, nie kupuje samej licencji — często musi też przepisać własne moduły albo zastąpić je gotowymi commercial features Adobe Commerce. --- ## Skali problemu nikt nie mierzy spójnie Krążąca po LinkedIn liczba „88 000 sklepów Magento” jest mocno zaniżona. Trzy niezależne trackery podają różne liczby w zależności od metodologii: - **StoreLeads**: ok. 119 000 aktywnie utrzymywanych sklepów - **W3Techs**: ok. 130 000 live websites - **BuiltWith**: ok. 162 000 instalacji (włącznie z dev/staging) Trend jednoznacznie spadkowy. Magento traci sklepy w tempie kilkunastu procent rocznie: - −3,8% kwartał do kwartału w Q3 2025 - −11% rok do roku w Q3 2025 - −15% rok do roku w Q1 2026 Sam BuiltWith pokazuje, że Shopify w jednym 90-dniowym oknie wchłonął ponad 500 byłych sklepów Magento. To nie jest „Magento umiera w przyszłym roku” — to jest „Magento traci 1/8 bazy każdego roku, a tempo przyspiesza”. Polski rynek jest reprezentatywną próbką tego globalnego trendu. Magento dominowało w polskim mid-market e-commerce przez pierwszą połowę poprzedniej dekady. Dziś migracje na Shopify Plus, BigCommerce i headless są rozmowami, które prowadzę co miesiąc. --- ## Co realnie się dzieje pod maską, gdy zostajesz na nieaktualnej wersji Tu wchodzi perspektywa techniczna, bo to ona decyduje o realnym ryzyku. Sklep nie pęka w dniu końca wsparcia — zaczyna powoli psuć się od środka. ### Bezpieczeństwo Magento jest atrakcyjnym celem ataków. Magecart, skimmery, RCE w ekstensjach, problemy z deserializacją — to nie hipotetyczne zagrożenia, to historia każdego roku. Każdy nowy CVE w PHP, w bibliotekach (Symfony, Laminas, Composer dependencies), w samej platformie nie dostaje już oficjalnej łatki dla Twojej wersji. Niektóre rzeczy załatasz społecznościowymi patchami od integratorów, ale to są półśrodki — bez gwarancji jakości, bez testów regresji, bez wsparcia w razie incydentu. Adobe wprowadziło w 2025 nowy model wydań: miesięczne łatki bezpieczeństwa plus dwa duże patch bundles rocznie (maj i listopad). Brzmi dobrze — pod warunkiem, że jesteś na wspieranej linii. Po końcu wsparcia podstawowego nie dostajesz nawet tego. ### PCI DSS i compliance PCI DSS nie pyta, czy Twój sklep „działa”. Wymaganie 6.2 wprost mówi: *„all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches”*. Brak wspieranej wersji = automatyczna czerwona flaga w audycie. Dla sklepów obracających kartami to konkretny problem prawno-finansowy: wyższe opłaty agenta rozliczeniowego (acquirera), ryzyko utraty merchant account, w skrajnym przypadku zamrożenie wypłat. Do tego dochodzi RODO/GDPR. Sklep przechowujący dane osobowe na nieaktualnej platformie — w razie wycieku — będzie miał trudniejszą rozmowę z UODO. Art. 32 RODO wymaga „odpowiednich środków technicznych” zabezpieczenia danych. Nieaktualna platforma e-commerce to dokładnie to, czego art. 32 zabrania. ### Integracje płatnościowe i kurierskie Polski e-commerce jest specyficzny. Operatorzy, których trzeba mieć: - **PayU** — dominujący gateway w PL - **Przelewy24** — drugi co do popularności - **Tpay** — popularny w mid-market - **BLIK** — praktycznie obowiązkowy - **Autopay** (dawne BlueMedia) — silny w bankach - **Stripe** — coraz częściej dla cross-border Każdy z tych operatorów regularnie aktualizuje API, formaty podpisów, wymagania TLS. Każda zmiana po stronie operatora wymaga aktualizacji modułu po stronie sklepu. Magento bez wsparcia oznacza, że albo backportujesz zmiany ręcznie, albo czekasz, aż integracja przestanie działać. Kurierzy: **InPost** (paczkomaty + kurier), **DPD**, **DHL**, **FedEx**, **GLS**, **Poczta Polska / Pocztex**, agregatorzy typu **Furgonetka** czy **Apaczka**. Każdy ma swoje API, swoje moduły do Magento, swoje cykle aktualizacji. W praktyce: każdy sklep używa 5–10 zewnętrznych modułów, które regularnie wymagają aktualizacji. Na nieaktualnej platformie część z nich zacznie się rozjeżdżać w ciągu 6–18 miesięcy. ### KSeF — krajowy system e-faktur To jest specyfika, która w 2026 dotyka wszystkich sklepów wystawiających faktury w Polsce. KSeF wymaga integracji z konkretnym systemem ERP lub bezpośrednio z API. Magento nie ma natywnego wsparcia KSeF — robi się to przez moduł, najczęściej powiązany z konkretnym ERP-em (Comarch ERP XL, Optima, Subiekt GT, enova365). Każda zmiana wymagań KSeF (a zmieniają się one regularnie) wymaga aktualizacji tego mostka. Nieaktualna platforma + nieaktualny moduł KSeF = ryzyko, że za rok przestaniesz móc legalnie wystawiać faktury. ### PHP, MySQL, infrastruktura Magento 2.4.6 wspiera PHP 8.2/8.3. PHP 8.2 ma EOL w grudniu 2026. MySQL 8.0 też ma swój horyzont wsparcia. Każdy komponent runtime'u ma swój cykl życia, niezależny od Magento. Po jakimś czasie zaczynasz pływać w mieszance „stary Magento + stary PHP + stary MySQL”, gdzie żadna z warstw nie jest już oficjalnie wspierana. Do tego dochodzą zależności core: Elasticsearch / OpenSearch, RabbitMQ, Redis, Varnish. Każda z nich ma swój cykl wsparcia. Sklep, który stoi na tej warstwie infrastruktury 5 lat bez aktualizacji, w pewnym momencie staje się niemigrowalny — nie dlatego, że Magento, tylko dlatego, że cała infrastruktura naokoło zgniła. ### Rosnący technical debt Każdy moduł, każda nakładka, każda zmiana w core — z biegiem miesięcy coraz trudniej wycenić upgrade. Każdy kolejny rok zaniedbania zwiększa koszt wyjścia z platformy o kilkanaście do kilkudziesięciu procent. To nie jest „sklep przestanie działać 11 sierpnia 2026”. To jest „od pewnego momentu każda zmiana będzie boleć dwa razy bardziej, a w razie incydentu nie masz oficjalnego punktu kontaktu”. --- ## Hosting i koszty utrzymania — czego nie kosztuje sama platforma Jedną z rzeczy, których „free” w „Magento Open Source” nie obejmuje, są realne koszty utrzymania. Magento jest platformą ciężką architektonicznie. Minimalny stack produkcyjny dla średniego sklepu (50–200 zamówień dziennie) wygląda tak: - **Web server** (Nginx + PHP-FPM 8.x), minimum 4 vCPU / 16 GB RAM - **Baza danych** (MySQL 8 / MariaDB), minimum 2 vCPU / 8 GB RAM, SSD NVMe - **Cache** (Redis), minimum 1 vCPU / 4 GB RAM - **Search** (Elasticsearch / OpenSearch), minimum 2 vCPU / 8 GB RAM - **Message queue** (RabbitMQ), opcjonalnie ale często konieczne - **Reverse proxy / FPC** (Varnish), praktycznie obowiązkowy w produkcji - **CDN + WAF** (Cloudflare, Bunny, AWS CloudFront) Realny koszt infrastruktury dla średniego sklepu Magento w Polsce: **2 500–6 000 zł/mies.** w setupie self-hosted (Hetzner / OVH / własny DC), **6 000–18 000 zł/mies.** na AWS / GCP, **15 000–60 000+ zł/mies.** na Adobe Commerce Cloud. Porównawczo: - **Shopify Plus**: hosting wliczony, opłata platformowa 24 000–80 000 zł/mies. + transakcyjna 0,15–0,40% - **BigCommerce Enterprise**: 40 000–120 000 zł rocznie + hosting wliczony - **Mage-OS** na własnej infrastrukturze: ~jak Magento self-hosted - **Medusa / Saleor self-hosted**: 1 000–3 500 zł/mies. (znacznie lżejszy stack — Node/Python kontra PHP-Magento) Nie kupujesz tylko platformy. Kupujesz miesięczny rachunek, który nie zniknie nigdy. --- ## Cztery realne ścieżki — z perspektywy kosztu i utrzymania Większość artykułów o końcu Magento Open Source pokazuje trzy opcje: upgrade, Adobe ekosystem, migracja. To jest niepełny obraz. Realnych ścieżek jest cztery, a najciekawsza nie jest w infografikach. ### Ścieżka 1: Upgrade w obrębie Magento Open Source (do 2.4.8) To najtańszy ruch w krótkim terminie i najbardziej oczywisty. Zostajesz na tym samym kodzie, te same moduły, ta sama logika biznesowa. Adobe dalej publikuje wydania OS, więc dostaniesz wsparcie do końca wsparcia podstawowego 2.4.8 (maj 2028). **Co realnie wchodzi w upgrade Magento 2.4.x → 2.4.8:** - aktualizacja Composer i wszystkich zależności (często łańcuch konfliktów) - aktualizacja modułów własnych (każdy `setup.xml`, każdy `db_schema.xml`) - aktualizacja modułów zewnętrznych (część może nie mieć wersji na 2.4.8) - migracja deprecated API (każda nowa wersja Magento usuwa kawałek API) - aktualizacja themów (w tym ewentualna migracja Hyvä) - aktualizacja PHP do 8.3, sprawdzenie kompatybilności - pełen cykl regresji **Kiedy ma sens:** - Twój sklep ma 50–500 modułów, dużo customizacji core - Masz zgrany zespół, który zna ten kod - Kupujesz sobie 2 lata na spokojne planowanie kolejnego ruchu **Realne koszty (benchmark 2025–2026, polski rynek):** - Mały sklep, kilkanaście rozszerzeń: **15 000–35 000 zł** - Średni, 50–100 modułów: **40 000–120 000 zł** - Duży, mocno customizowany: **150 000–500 000+ zł** **Czego nie kupisz w tej cenie:** poprawy wydajności, modernizacji frontendu, redukcji długu technicznego. To migracja „as-is” — przepisana klatka. Po upgrade dostajesz dokładnie ten sam Magento, tylko nowszy. **Ważny niuans:** upgrade z 2.4.4 do 2.4.8 to nie jest jeden krok. Najczęściej trzeba przejść przez minimum jedną wersję pośrednią (2.4.6 lub 2.4.7), żeby ekstensje i moduły custom miały szansę zaaplikować swoje migracje. Zaplanuj to w fazach. ### Ścieżka 2: Adobe Commerce (płatny ekosystem) Adobe pcha cały ekosystem w stronę chmury i AI: **Edge Delivery Services**, **Commerce Drop-ins**, **App Builder**, **Live Search**, **Product Recommendations** (AI-driven). Te narzędzia są dostępne tylko dla klientów Adobe Commerce, najczęściej Adobe Commerce Cloud. **Kiedy ma sens:** - Roczny obrót sklepu pozwala wchłonąć licencję Adobe Commerce (zaczyna się od ~22 000 USD/rok dla najmniejszych planów, idzie w setki tysięcy USD dla enterprise; opłata zwykle skaluje się z GMV) - Potrzebujesz B2B accounts, advanced personalization, multi-source inventory, AI search out-of-the-box - Masz wewnętrzny zespół DevOps i zaplecze enterprise - Już jesteś w Adobe stack (AEM, Marketo, Target) i integracje są realnym argumentem **Realne koszty:** - licencja: od ~22 000 USD/rok wzwyż (skaluje się z GMV) - implementacja / migracja: 200 000–1 500 000 zł - hosting (Adobe Commerce Cloud): 15 000–60 000+ zł/mies. - utrzymanie: 8 000–40 000 zł/mies. Dla większości polskich sklepów średnich to nieproporcjonalnie drogie. **Pułapka vendor lock-in:** Edge Delivery Services brzmi imponująco (Lighthouse 100, węzły brzegowe (edge nodes), content authoring w Google Docs), ale to ciasny lock-in w Adobe Cloud. Wyjście z tej ścieżki za kilka lat będzie droższe niż wyjście z dzisiejszego Magento Open Source. App Builder działa tylko na Adobe IO Runtime. Commerce Drop-ins są pisane pod konkretne API Adobe Commerce. Im głębiej wchodzisz, tym trudniej wyjść. To nie znaczy, że to zła decyzja — dla części sklepów Adobe Commerce jest dokładnie tym, czego potrzebują. Ale to decyzja strategiczna na 7–10 lat, nie taktyczna. ### Ścieżka 3: Migracja na inną platformę Tu zdecydowana większość ruchu rynkowego. Pięć głównych kierunków: **Shopify / Shopify Plus** — największy strumień migracji od Magento. Plusy: SaaS, zerowe utrzymanie infrastruktury, najlepszy ekosystem aplikacji (>10 000 w App Store), świetny checkout out-of-the-box, najlepiej dopracowane mobile. Minusy: model „platform fee + transakcyjny”, limity API (call limits, storage), ograniczona kontrola nad backendem, trudniejsza złożona logika cenowa. Liquid jako templating jest specyficzny. W polskim kontekście: Shopify świetnie radzi sobie z BLIK, PayU, Przelewy24 (przez moduły), z InPost (oficjalna integracja). KSeF wymaga zewnętrznego mostka. Shopify Plus zaczyna się od ~2 300 USD/mies., dla większych obrotów cena negocjowana. Dobry wybór dla sklepów B2C bez skomplikowanej logiki cen i magazynów. **BigCommerce** — częsty kandydat w mid-market RFP. Tańszy fee niż Shopify Plus, lepiej radzi sobie z B2B out-of-the-box, headless API w standardzie, brak transaction fees na własnych płatnościach. Mniejsza ekosystem aplikacji niż Shopify, ale dla mid-market wystarczający. **commercetools** — enterprise headless. Drogo (od ~50 000 EUR/rok), ale dla sklepów z naprawdę złożoną logiką (multi-brand, multi-region, multi-channel, B2B + B2C w jednym) to często najczystszy ruch. MACH-native (microservices, API-first, cloud-native, headless). **WooCommerce** — wciąż największa platforma e-commerce w sieci wg liczby instalacji. Dla małych i średnich sklepów polskich z silnym contentem (blog, content marketing) bywa dobrym wyborem. Wszystkie polskie integracje (PayU, Tpay, InPost, Comarch, KSeF) mają dojrzałe wtyczki. Limit: WooCommerce nie skaluje się dobrze powyżej kilku tysięcy zamówień miesięcznie bez znacznych nakładów na optymalizację. **Open source headless** — Medusa (Node/TS), Saleor (Python/Django, GraphQL-only), Vendure (TypeScript). Dla zespołów technicznych, które chcą pełnej kontroli i nie chcą wpaść w nową chmurową zależność. - **Medusa** — najbardziej zbliżony do Magento „sposobem myślenia” (rozszerzalny core, model danych podobny strukturą), najszybciej rośnie w 2026, najlepsze DX dla zespołów Node/TS. Medusa Cloud jest opcją, ale self-hosted działa świetnie. - **Saleor** — najbardziej „enterprise” z trójki, GraphQL API, multi-channel native, wsparcie B2B i B2C w jednym storze. Stack Python + Django + GraphQL, więc wymaga zespołu ze specyficznym profilem. - **Vendure** — TypeScript-first, mocny system pluginów, dojrzały ekosystem. Dobry wybór, jeśli zespół już pracuje w TypeScript end-to-end. **Realne koszty migracji platformy** (benchmark 2025–2026): - Mały sklep: **100 000–180 000 zł** - Średni: **220 000–450 000 zł** - Enterprise: **550 000 zł – 1,2 mln zł +** - Czas: 4–9 miesięcy w zależności od skali i ilości danych do przeniesienia - Plus wsparcie powdrożeniowe 10 000–45 000 zł i szkolenia 5 000–20 000 zł To **2–3× drożej niż upgrade w obrębie Magento**, ale zwykle daje wymierny zwrot w postaci niższych kosztów utrzymania w kolejnych latach. ### Ścieżka 4: Mage-OS + Hyvä — opcja, której nie reklamuje nikt z budżetem To jest najciekawszy wątek całej historii i jednocześnie ten, którego brakuje w grafice z LinkedIna. **Mage-OS** to non-profit, społecznościowy fork Magento Open Source. Powstał w 2021 z otwartego listu społeczności do Adobe. Dziś (2026) jest poważnym, produkcyjnie używanym projektem: - Mage-OS 2.0 wydany w październiku 2025 - Mage-OS 2.2.0 to aktualne wydanie - Mage-OS 3.0 planowany na maj 2026, równolegle z Magento 2.4.9 - Włącza upstream łatki bezpieczeństwa z Adobe + dodatkowe community fixes - Często szybszy cykl łatek niż oficjalny Magento OS **Hyvä** — frontend, który de facto pochował Adobe PWA Studio. W listopadzie 2025 stał się w pełni open source. Magento + Hyvä + Mage-OS to dziś najbardziej aktywnie rozwijany stos w społeczności Magento. Hyvä zastępuje stary Knockout/UI-Component frontend lekkim Alpine.js + Tailwind, z realnymi 90+ Lighthouse out-of-the-box. **Kiedy to ma sens:** - Zostawiasz całą logikę biznesową (moduły, integracje, dane) - Migracja jest porównywalna kosztowo do regularnego upgrade'u - Cykl łatek szybszy niż oficjalny — tej zalety nie ma żadna inna ścieżka - Brak vendor lock-in — możesz wrócić na oficjalne Magento, jeśli tak zdecydujesz - Polskie integracje (PayU, Przelewy24, InPost, Comarch) działają tak samo jak na Magento OS **Czego to nie rozwiązuje:** - Magento jest fundamentalnie ciężki — Mage-OS tego nie zmienia - Społeczność jest mniejsza niż Adobe ekosystem - Niektóre płatne moduły mogą nie być testowane na Mage-OS - Brak wsparcia komercyjnego — odpowiadasz za sklep sam (przez integratora) Dla wielu sklepów średnich, które zainwestowały już 200–500 tys. zł w custom moduły Magento, **Mage-OS + Hyvä to najtańszy ruch zachowujący wartość tej inwestycji**. To jest ścieżka, którą warto co najmniej rozważyć przed podpisaniem umowy migracyjnej. --- ## Tabela porównawcza — co realnie wybierasz | Kryterium | Magento OS upgrade | Adobe Commerce | Shopify Plus | BigCommerce | Mage-OS + Hyvä | Medusa | Saleor | |---|---|---|---|---|---|---|---| | Model | Self-hosted | Cloud / Self-hosted | SaaS | SaaS | Self-hosted | Self-hosted / Cloud | Self-hosted / Cloud | | Licencja roczna | 0 | 22k+ USD | 30–80k USD | 12–40k USD | 0 | 0 | 0 | | Hosting | własny | Adobe | wliczony | wliczony | własny | własny | własny | | Vendor lock-in | niski | wysoki | wysoki | średni | niski | niski | niski | | Customization | bardzo duża | bardzo duża | średnia | średnia | bardzo duża | bardzo duża | duża | | Headless ready | przez API | tak (drop-ins) | Hydrogen | tak | tak | natywnie | natywnie | | Polskie integracje | ekosystem | ekosystem | dobre | OK | ekosystem Magento | trzeba zbudować | trzeba zbudować | | KSeF | przez moduł | przez moduł | przez mostek | przez mostek | jak Magento | trzeba zbudować | trzeba zbudować | | Stack | PHP / MySQL | PHP / MySQL | proprietary | proprietary | PHP / MySQL | Node / Postgres | Python / Postgres | | Frontend | Hyvä / Luma / PWA | Edge Delivery | Liquid / Hydrogen | Stencil / headless | Hyvä | własny (Next.js itp.) | własny (Next.js itp.) | | Czas migracji | 1–4 mies. | 6–12 mies. | 4–8 mies. | 4–7 mies. | 1–3 mies. | 5–9 mies. | 6–10 mies. | | Dla kogo | zostaje na Magento | enterprise z budżetem | B2C scale | mid-market | Magento bez Adobe | tech-first headless | enterprise headless | --- ## B2B vs B2C — różne ścieżki dla różnych modeli Często pomijana rzecz: rekomendacja zależy mocno od tego, czy sprzedajesz B2C, B2B czy mieszankę. **Czysty B2C** (sklep katalogowy, lifestyle, fashion, FMCG): - Najczęstszy ruch: Shopify Plus - Alternatywa: BigCommerce, Mage-OS + Hyvä - Najmniej sensowny: commercetools, Adobe Commerce dla małych **B2B z prostą logiką**: - Najczęstszy ruch: BigCommerce (bardzo dobre B2B out-of-the-box) lub upgrade Magento - Alternatywa: Mage-OS + Hyvä, Saleor **B2B z trudną logiką** (multi-tier ceny, kontrakty, kredyty kupieckie, integracja z ERP, custom catalogs per klient): - Najczęstszy ruch: Adobe Commerce lub commercetools - Alternatywa: upgrade Magento + custom moduły, Saleor (silne B2B w core) - Niezalecany: Shopify (B2B w Shopify dojrzewa, ale nadal niedopracowane) **B2C + B2B w jednym sklepie**: - Saleor jest najmniej bolesnym wyborem — multi-channel w core to dokładnie to - Adobe Commerce ma to, ale drogo - commercetools ma to, ale jeszcze drożej - Magento próbuje, ale jest okrutnie skomplikowane To są zgrubne szufladki — każdy konkretny sklep ma swoją specyfikę. --- ## Migracja a SEO — playbook, którego nie wolno spartolić Jedną z dwóch najczęstszych przyczyn katastrofy migracji jest brak strategii SEO. Druga to brak strategii danych. Tu o SEO. Migracja platformy to scenariusz, w którym możesz stracić 30–60% organicznego ruchu w ciągu 4–8 tygodni, jeśli nie pomyślisz o tym z góry. Stracony ruch to stracone przychody, a odzyskanie pozycji może zająć rok. ### Rzeczy, które muszą być zrobione *przed* migracją: **1. Pełen crawl starego sklepu.** Screaming Frog, Sitebulb, JetOctopus — wszystko jedno, byle zrobić pełny inwentarz wszystkich URL-i, statusów HTTP, tytułów, meta description, canonical, hreflang, schemy, rel=prev/next. Eksport do CSV jako baseline. **2. Mapowanie URL-i 1:1.** Stary URL → nowy URL. Każdy. Produkty (oczywiste), kategorie, filtry, paginacja, blog (jeśli jest), strony statyczne, podstrony pomocy, polityki, FAQ. Najczęstszy błąd: pamiętasz produkty i kategorie, zapominasz o paginacji `/category?p=2` i filtrach. Google ma to zaindeksowane. **3. Strategia 301.** Wszystkie 301-ki muszą być zaimplementowane *od dnia uruchomienia nowego sklepu*, nie tydzień później. Najlepiej w nginx / Cloudflare Workers / na poziomie reverse proxy, nie na poziomie aplikacji (szybciej, mniej obciążenia). **4. Hreflang.** Jeśli masz wersje językowe (PL/EN/DE), upewnij się, że nowa platforma poprawnie generuje hreflang. Spartolony hreflang = duplicate content (duplikaty treści), kanibalizacja słów kluczowych. **5. Schema markup.** Product, Offer, AggregateRating, Review, Breadcrumb, Organization. Wszystko, co miałeś, musi być w nowym sklepie. Google podlicza dane strukturalne i ich brak zauważa od razu. **6. Sitemap XML i robots.txt.** Po uruchomieniu nowego sklepu nowy sitemap musi być natychmiast zgłoszony w Google Search Console. Stary sitemap zostaje na czas crawlu (kilka tygodni), żeby Google zobaczyło 301-ki. **7. Core Web Vitals baseline.** Zmierz LCP, INP, CLS przed migracją. Po migracji powinny być lepsze, nie gorsze. Jeśli są gorsze — masz problem, którego nie zauważysz, zanim zacznie szkodzić rankingom. ### Po migracji: - Monitoring 404 w Search Console (alert na nagły wzrost) - Re-submit sitemap natychmiast po uruchomieniu - Walidacja danych strukturalnych w Search Console - Monitoring rankingów na top słowa kluczowe (Ahrefs, Senuto, Semstorm) — codziennie przez 4 tygodnie - Regenerowanie linkowania wewnętrznego w razie potrzeby To jest temat na osobny artykuł, ale jeśli ten kawałek pominiesz, cała migracja jest zagrożona. --- ## Trzy realne scenariusze migracji — wzorce, które widzę najczęściej Zamiast hipotetycznych przykładów, opiszę trzy wzorce, które prowadzę regularnie. Detale są zanonimizowane, ale liczby realne. ### Scenariusz A: średni B2C na Magento Open Source 2.4.4 → Mage-OS + Hyvä Sklep odzieżowy, ~500 produktów, ~1500 zamówień miesięcznie, 20 modułów własnych, integracje z PayU, Przelewy24, InPost, Comarch ERP XL. Co zrobiłem: upgrade techniczny Magento 2.4.4 → Mage-OS 2.2 + zamiana frontendu Luma na Hyvä. - Czas: 12 tygodni - Koszt: 95 000 zł - Wynik: koszty utrzymania spadły o ~30% (lżejszy frontend = mniejszy serwer), Lighthouse skoczył z 38 na 91, czas ładowania -55% - Wszystkie integracje zostały, dane się nie ruszyły, KSeF nadal działa przez Comarch To jest wzorzec, który warto rozważyć w pierwszej kolejności, jeśli nie masz fundamentalnego problemu z Magento jako takim. ### Scenariusz B: mid-market B2C na Magento 2.4.5 → Shopify Plus Sklep wyposażenia domu, ~3000 produktów, ~6000 zamówień miesięcznie, ciężki content marketing, ~80 modułów Magento (z tego połowa nieużywana). Co zrobiłem: pełna migracja platformy + redesign frontendu + audyt modułów (część nieużywanych odrzucona). - Czas: 7 miesięcy - Koszt: 380 000 zł migracja + 30 000 zł wsparcia powdrożeniowego - Wynik: utrzymanie infrastruktury zniknęło (Shopify Plus), koszty deweloperskie spadły o ~60%, konwersja wzrosła o ~18% (głównie dzięki Shopify checkout) - Strata: utrata części customizacji, którą Magento dawało z palca; ograniczona kontrola nad logiką promocji - Ruch organiczny: -22% w miesiącu po migracji, -8% po 3 miesiącach, +5% po roku (vs baseline) Ten ruch ma sens, jeśli nie potrzebujesz głębokiej customizacji backendu i cenisz sobie zerowe utrzymanie infrastruktury. ### Scenariusz C: B2B na Magento 2.4.6 → Saleor Hurtownia części, ~10 000 SKU, kontrakty z klientami, ceny per kontrakt, kredyt kupiecki, integracja z ERP-em (custom system + częściowo Comarch). Co zrobiłem: pełna migracja na Saleor self-hosted, custom storefront w Next.js, custom moduły do logiki cenowej i kontraktów. - Czas: 9 miesięcy - Koszt: 720 000 zł - Wynik: time-to-market dla nowych funkcji spadł z ~6 tygodni do ~1 tygodnia (GraphQL + nowoczesny stack), koszty hostingu spadły 4x (Saleor jest dramatycznie lżejszy niż Magento) - Strata: trzeba było zbudować integrację z PayU od zera, Comarch też dostał custom mostek To jest wzorzec dla zespołów technicznych, które chcą pełnej kontroli i są gotowe inwestować w custom rozwiązania. --- ## Drzewo decyzyjne — jak ja pomagam to przemyśleć Pierwsza rzecz, którą robię z klientem, to **inwentarz aktualnego sklepu**, nie wybór nowej platformy. Bez tego rozmowa o migracji jest spekulacją. Pytania, które zadaję w pierwszej kolejności: 1. **Ile masz custom modułów / nakładek na core?** Jeśli mniej niż 10 i są proste — migracja platformy jest łatwa. Jeśli >50 i są skomplikowane — uciekanie z Magento jest bardzo drogie. 2. **Jaki jest roczny GMV i jakie są marże?** Jeśli GMV nie pozwala wchłonąć 30k USD/rok licencji, Adobe Commerce odpada od razu. Jeśli GMV jest niski, ale marże są wysokie (np. luxury), to inny rachunek niż wysokie GMV i niskie marże. 3. **Jakie są zewnętrzne integracje?** ERP, PIM, kurierzy, marketplaces, KSeF. Każda integracja to potencjalnie kilka–kilkadziesiąt tys. zł kosztu re-implementacji. 4. **Czy zespół (zewnętrzny czy wewnętrzny) zna inny stack?** Migracja na Saleor, jeśli nikt nie programuje w Pythonie, to dodatkowe 6–12 miesięcy nauki. Migracja na Medusa, jeśli zespół zna Node — zupełnie inny scenariusz. 5. **Jaki masz horyzont czasowy?** Sklep, który ma 2 lata na ruch, ma inne opcje niż sklep, który chce być na nowej platformie w 6 miesięcy. 6. **Jaka jest tolerancja na ryzyko?** Migracja platformy w pełnym sezonie sprzedaży to ryzyko. Migracja w styczniu/lutym — minimalne. Niektóre branże (np. e-commerce sezonowy świąteczny) mają realnie 2–3 miesiące w roku, w których można robić przełączenie. Realne dopasowanie wygląda dziś mniej więcej tak: - **Sklep B2C, prosty, do 5M zł rocznie obrotu** → Shopify, czasem WooCommerce, rzadziej upgrade Magento - **Sklep B2C, średni, kilkadziesiąt M zł, dużo customizacji** → Mage-OS + Hyvä lub BigCommerce - **B2B z trudną logiką cen / kontraktów** → commercetools lub Adobe Commerce, alternatywnie Saleor - **Headless-first, mocny zespół tech** → Medusa lub Saleor - **Enterprise z mocnym Adobe stack i budżetem** → Adobe Commerce Cloud + Edge Delivery - **Sklep z 200+ tys. zł zainwestowanymi w custom Magento, działający ekosystem** → Mage-OS + Hyvä, prawie zawsze Nie ma jednej dobrej odpowiedzi. --- ## Plan migracji tydzień po tygodniu Realistyczny plan dla średniego sklepu B2C migrującego z Magento 2.4.5 na Shopify Plus (lub Mage-OS — proces jest 70% wspólny). Skala: 3000 produktów, 5000 zamówień miesięcznie, 8 zewnętrznych integracji. **Faza 0: Audyt (4 tygodnie)** — przed podjęciem decyzji - Pełny inwentarz modułów, ekstensji, customizacji - Inwentarz integracji (każda osobno: API, format danych, autentykacja, retry strategy) - Pełen crawl SEO (Screaming Frog, eksport CSV) - Inwentarz danych (produkty, klienci, zamówienia, recenzje, koszyki, lista życzeń) - Analiza GMV per kategoria, top 100 produktów, top 50 słów kluczowych **Faza 1: Decyzja i kontrakt (2 tygodnie)** - Wybór platformy - Wybór wykonawcy (RFP, oferty, referencje) - Kontrakt, harmonogram, milestones **Faza 2: Setup (3 tygodnie)** - Provisioning nowej platformy (sklep, hosting, repozytorium) - Konfiguracja podstawowa (waluty, języki, podatki, jednostki) - Setup CI/CD, środowisko stage - Setup analityki (GA4, GTM, Search Console, Meta Pixel) **Faza 3: Migracja danych (4 tygodnie)** - Skrypt migracji produktów (kategorie → kolekcje, atrybuty → metafields, warianty) - Skrypt migracji klientów (z hashami haseł — każda platforma ma swój sposób) - Skrypt migracji zamówień historycznych (read-only, dla obsługi klienta) - Migracja contentu (blog, strony statyczne, polityki) - Migracja przekierowań (URL mapping → 301) **Faza 4: Frontend (4 tygodnie)** - Implementacja designu na nowej platformie - Storefront komponenty (PLP, PDP, koszyk, checkout) - Mobile (zazwyczaj 60%+ ruchu) - Search & filtry - Optymalizacja wydajności (LCP, INP) **Faza 5: Integracje (5 tygodni)** - Płatności (PayU, Przelewy24, BLIK, Stripe, Apple Pay, Google Pay) - Kurierzy (InPost, DPD, Pocztex) - ERP / księgowość / KSeF - Marketing (Klaviyo / mailchimp / Edrone, push, ads) - Recenzje (Trustmate, Opineo, Reviews.io) **Faza 6: Testy regresji (3 tygodnie)** - Pełen cykl E2E (najlepiej automatyczny — Playwright lub Cypress) - Testy płatności w sandboxie - Testy edge case (zwroty, częściowe zwroty, anulowania, podwójne zamówienia) - Test obciążeniowy (przed Black Friday — obowiązkowy) - UAT z prawdziwymi użytkownikami (5–10 osób, klienci stali + zespół customer service) **Faza 7: Soft launch (2 tygodnie)** - Beta na subdomenie (`new.sklep.pl`) - Wpuszczenie 5–10% ruchu (np. przez Cloudflare load balancing) - Monitoring konwersji, funnel, błędów (Sentry, LogRocket) - Iteracja, fix, ponowny test **Faza 8: Przełączenie / cutover (1 dzień + 4 tygodnie monitoringu)** - Przełączenie DNS (najlepiej w nocy z wtorku na środę — najmniejszy ruch) - 301-ki aktywne natychmiast - Monitoring 404 co godzinę przez pierwsze 3 dni - Search Console: re-submit sitemap, monitoring crawl errors - Daily standup zespołu przez 4 tygodnie **Suma:** 7–8 miesięcy realnej pracy, ~28 tygodni harmonogramu. To jest plan szybki, dla doświadczonego zespołu. W realnym projekcie zwykle dochodzi 30–50% buforu na rzeczy, których nikt nie przewidział. --- ## Czego nie robić w planie migracji Kilka błędów, które widzę regularnie w polskim e-commerce: **Big-bang cutover.** Wyłączamy stary sklep w piątek, włączamy nowy w poniedziałek. Średni koszt przestoju to ~5 600 USD/min wg benchmarków IT — i to nie licząc utraconej reputacji. Jeśli da się przeprowadzić przełączenie stopniowe (subdomena dla nowego sklepu, redirecty per kategoria), zawsze warto. **Migracja „as-is”.** Przeniesienie wszystkich modułów 1:1 do nowej platformy zwykle marnuje połowę pieniędzy. Migracja to jedyny moment, w którym możesz uczciwie zapytać: które z tych 80 modułów jest faktycznie używane? Połowa się okazuje martwym kodem. **Brak inwentarza danych.** SKU-y, klienci, zamówienia, recenzje, redirecty SEO. Każda z tych rzeczy musi mieć przemyślany plan migracji, włącznie z mapowaniem URL-i 301 (nie tylko strony produktów — kategorie, filtry, paginacja). Stracone rankingi Google bywają droższe niż sama migracja. **Wybór platformy przed wyborem zespołu.** Najlepsza platforma dla zespołu, który jej nie zna, to nie jest najlepsza platforma. **Brak testów regresji.** Powtarzam to w kontekście dowolnej dużej zmiany — tu znowu się przyda. Migracja platformy to scenariusz, w którym solidny zestaw testów E2E (typu Playwright lub Cypress) zwraca się tygodniami pracy, której nie musisz powtarzać ręcznie po każdej iteracji. **Migracja w sezonie.** Jeśli Twój sklep ma sezon (świąteczny, letni, school-back), absolutnie nie planuj przełączenia w sezonie. Każdy procent strat konwersji w sezonie kosztuje wielokrotnie więcej niż utrzymanie starej platformy o miesiąc dłużej. **Brak planu wycofania (rollback).** Pierwsza zasada przełączenia: musisz móc wrócić. DNS musi być cofnięty w 5 minut, dane na starej platformie muszą być spójne i aktualne przez minimum tydzień po przełączeniu, infrastruktura starej platformy musi działać równolegle. **Pominięcie KSeF.** W Polsce 2026 to nie jest opcjonalne. Każda nowa platforma musi mieć działającą integrację KSeF od dnia uruchomienia, inaczej ryzykujesz brak możliwości wystawienia faktur. **Migracja bez bramki SLA.** Migracja, którą „agencja zrobi i odejdzie”, to migracja, która Cię zostawi na lodzie po pierwszym poważnym bugu. SLA + umowa wsparcia powdrożeniowego (retainer) przez minimum 3 miesiące to standard, nie luksus. --- ## Mity, które słyszę regularnie **„Magento jest darmowe.”** Kod jest. Hosting, utrzymanie, integratorzy, ekstensje, łatki bezpieczeństwa — kosztują. Realny TCO Magento dla średniego sklepu w Polsce to 8 000–25 000 zł miesięcznie wszystko wliczone. **„Adobe wyłącza Magento Open Source.”** Nie wyłącza. Przestaje wspierać konkretne wersje. Sam projekt nadal istnieje, kod jest na GitHubie, społeczność (w tym Mage-OS) go utrzymuje. **„Przejście na Mage-OS to ryzyko.”** Mniejsze niż zostawanie na nieaktualnej wersji oficjalnego Magento. Mage-OS dostaje wszystkie upstream łatki Adobe + dodatkowe community fixes. **„Shopify jest dla małych sklepów.”** Shopify Plus obsługuje sklepy z miliardami GMV (Gymshark, Allbirds, Heinz). To, co kiedyś było „dla małych”, jest dziś enterprise-ready. **„Headless to przyszłość, monolit to przeszłość.”** Headless to tylko architektura. Dla wielu sklepów monolityczna platforma z dobrym frontendem (Hyvä, Liquid) jest tańsza w utrzymaniu i szybsza w wytworzeniu niż headless. Headless ma sens, gdy potrzebujesz wielu kanałów (web + mobile + POS + IoT) lub bardzo specyficznego UX. **„Migracja zawsze popsuje SEO.”** Nie zawsze. Dobrze zaplanowana migracja z pełnym mapowaniem URL-i, 301-kami i strukturalnymi danymi może wyjść neutralnie, czasem pozytywnie (jeśli nowa platforma jest dramatycznie szybsza). **„Adobe Commerce to standard enterprise.”** Dla wielu enterprise tak, ale commercetools, BigCommerce Enterprise, Salesforce Commerce Cloud i headless rosną szybciej niż Adobe Commerce. --- ## Oś czasu, którą trzymam dla klientów Konkretny plan, jeśli jesteś dziś (maj 2026) na Magento Open Source: **Jesteś na 2.4.4 lub 2.4.5:** - *Już teraz* — audyt, decyzja platformowa, w razie zwlekania minimum upgrade do 2.4.7 - *do końca 2026* — implementacja docelowej ścieżki **Jesteś na 2.4.6:** - *Q2–Q3 2026* — audyt, decyzja - *do sierpnia 2026* — minimum upgrade do 2.4.7 lub 2.4.8 (wsparcie podstawowe 2.4.6 kończy się 11 sierpnia 2026) - *Q4 2026 – Q1 2027* — implementacja docelowa **Jesteś na 2.4.7:** - *Q3–Q4 2026* — audyt - *Q1–Q3 2027* — implementacja docelowa, zanim skończy się wsparcie podstawowe 2.4.7 (maj 2027) **Jesteś na 2.4.8:** - masz najwięcej czasu, wsparcie podstawowe do maja 2028 - *2026* — strategiczne planowanie kolejnego ruchu (upgrade do 2.4.9, migracja, Mage-OS) - *2027* — implementacja W każdym scenariuszu pierwszy krok jest ten sam: **uczciwy audyt aktualnego stanu**. --- ## Co dalej — AI, agentic commerce, edge delivery Dyskusja o Magento Open Source dzieje się w szerszym kontekście, którego warto być świadomym przy 5-letniej decyzji. **AI search w e-commerce.** Adobe Live Search, Algolia AI, Klevu, Coveo — wszystko to redefiniuje, jak działa wyszukiwanie w sklepie. Sklep, który nie ma porządnego AI search, traci konwersję na rzecz konkurencji, która ma. To jest punkt różnicujący platformy: niektóre mają to natywnie (Adobe Commerce, Shopify), inne wymagają integracji. **Agentic commerce.** Wczesny etap, ale realny. AI-asystenci kupujący w imieniu użytkownika (ChatGPT z Stripe, Perplexity Shopping). Twoja platforma musi być gotowa na wystawienie czystego API produktów / cen / inventory, żeby agenci AI mogli z nią rozmawiać. Headless platformy są tu z definicji lepsze. **Edge delivery.** Renderowanie w węzłach brzegowych (edge nodes), content authoring w nowoczesnych narzędziach (Sanity, Contentful, Adobe Edge Delivery). Lighthouse 100 staje się standardem, nie ambicją. **AI-driven personalization.** Indywidualne ceny, indywidualne kolekcje, indywidualne reko per użytkownik. Tu Adobe Commerce jest mocny, ale headless platformy + nowoczesny stack dogonią szybko. To są wszystko trendy, które w 2026 są wczesne, ale w 2028–2029 staną się standardem. Dziś podejmowana decyzja platformowa powinna brać je pod uwagę. --- ## Krótko: czy panika jest uzasadniona? **Nie**, jeśli rozumiesz, gdzie naprawdę jest ryzyko. **Tak**, jeśli prowadzisz sklep na 2.4.4/2.4.5 i nie masz planu. Adobe nie wyłącza Magento Open Source jako projektu. Adobe wyłącza wsparcie dla starych wersji — i nigdy nie miało wsparcia rozszerzonego dla Open Source. Społeczność (Mage-OS, Hyvä) wypełnia lukę szybciej, niż to pokazuje większość komunikatów Adobe. Najgorsza decyzja to **brak decyzji**. Każdy kwartał zwlekania to dodatkowy dług techniczny, droższa migracja, większe ryzyko w audycie PCI DSS, większe ryzyko incydentu bezpieczeństwa. Najlepsza decyzja to **inwentarz przed strategią**. Wybór platformy jest banalny, gdy masz uczciwą listę: ile masz modułów, które są używane, ile danych trzeba przenieść, jakie integracje są krytyczne, kto będzie to programował. Bez tej listy każda agencja sprzeda Ci to, co najlepiej zna. Jeśli prowadzisz sklep na Magento i chcesz przegadać konkretną sytuację — [napisz](https://spoko.space/pl/contact). Pierwsza rozmowa zwykle wystarcza, żeby ułożyć Ci hierarchię ryzyka i pokazać 2–3 realistyczne opcje z grubszą wyceną.