Przejdź do treści

Vendor lock-in w 2026 roku
Złota kłódka czy pęk kluczy

Przychody Broadcomu z VMware rosną o 29% rok do roku, choć większość dużych firm deklaruje ograniczanie VMware. SAP przesuwa granicę z licencji na dane, a open source potrafi zmienić licencję z dnia na dzień. Felieton o koszcie pozostania u dostawcy i warunkach wyjścia z jego platformy.

Broadcom podał 2 września, że przychody jego segmentu oprogramowania infrastrukturalnego, czyli przede wszystkim VMware, wyniosły w ostatnim kwartale 8,75 mld USD. Rok wcześniej było to 6,79 mld USD, więc wzrost wyniósł 29%. W lutym CloudBolt opublikował badanie, w którym 86% dużych firm z Ameryki Północnej deklarowało, że aktywnie ogranicza użycie VMware. Całkowicie zrezygnowało z niego około 4%.

Te dwie liczby sobie nie przeczą i dobrze opisują vendor lock-in, czyli uzależnienie od dostawcy, w 2026 roku. Deklaracja wyjścia nic nie kosztuje, a dopóki migracja trwa, licencję trzeba odnawiać.

Piszę z pozycji, która nie jest neutralna. SNOK jest partnerem SAP, UiPath, SUSE, Lenovo, Microsoft i Google Cloud, więc na co dzień trzymamy w rękach i kłódkę, i klucze: wdrażamy platformy, które wiążą klientów na lata, i pomagamy klientom te więzy rozluźniać. Dlatego nie wskazuję tu kierunku. Bronię jednej tezy: uzależnienie wybrane świadomie i policzone przed decyzją jest decyzją architektoniczną, a przypadkowe poznajemy dopiero przy odnowieniu umowy.

Okładkę wygenerowała AI na podstawie zdjęcia autora.

VMware pod Broadcomem - klienci deklarują wyjście, przychody rosną

Po przejęciu VMware pod koniec 2023 roku Broadcom zakończył sprzedaż licencji wieczystych i przeszedł na subskrypcje liczone od rdzeni procesora. W marcu 2025 roku dystrybutor zapowiedział partnerom minimum 72 rdzeni na zamówienie i dopłatę 20% za spóźnione odnowienie. Po fali krytyki, według heise, próg rdzeni wycofano i licencję nadal można kupić od 16 rdzeni. Sam spór o próg pokazał, jak szybko mogą zmienić się warunki zakupu. W styczniu 2026 roku Broadcom zamknął program dla większości dostawców chmury rozliczających VMware w modelu usługowym.

Spory trafiły już do sądów. Holenderski Rijkswaterstaat, który na VMware zarządza m.in. tunelami, śluzami i mostami, wywalczył w 2025 roku w sądzie w Hadze dwa lata wsparcia na migrację. Tesco pozwało Broadcom, VMware i Computacenter w Wielkiej Brytanii. Komisja Europejska wysłała Broadcomowi w lutym 2026 roku formalne żądanie informacji, a Sąd Ogólny UE w sierpniu odrzucił wniosek Broadcomu o jego wstrzymanie. Pod koniec sierpnia z publicznego pobierania zniknął VDDK, zestaw bibliotek, z którego korzysta wiele narzędzi do migracji i kopii zapasowych. Broadcom nie wydał w tej sprawie komunikatu, więc znamy ją wyłącznie z relacji użytkowników i serwisów branżowych.

Hock Tan, prezes Broadcomu, powiedział we wrześniu 2025 roku, że ponad 90% z dziesięciu tysięcy największych klientów kupiło VMware Cloud Foundation, i od razu dodał, że nie znaczy to, że wszyscy go wdrożyli. Producent rzadko sam tak wyraźnie oddziela zakup od wdrożenia.

Alternatyw dla VMware jest więcej niż kiedykolwiek: Proxmox VE, Nutanix AHV, Red Hat OpenShift Virtualization, Microsoft Hyper-V i Azure Local, HPE Morpheus VM Essentials, KVM od SUSE. W świecie SAP lista szybko się skraca. SAP HANA w produkcji ma wsparcie na VMware vSphere, na KVM od SUSE i na Nutanix AHV, ale na OpenShift Virtualization już nie. Gartner szacuje, że do 2028 roku około jednej trzeciej obecnych obciążeń VMware będzie działać gdzie indziej, a pełna migracja zajmuje trzy lata albo dłużej, i ostrzega, że kto zmienia platformę wyłącznie dla oszczędności, może się rozczarować.

Nie wiem, kto bardziej finansuje tę różnicę - ci, którzy zostają, czy ci, którzy jeszcze nie zdążyli wyjść. Wiem natomiast, że etapowe ograniczanie VMware oznacza na kilka lat dwie platformy, dwa zespoły i dwa kontrakty. Jeżeli taką ścieżkę wybierzemy, wolę policzyć ją teraz niż przy kolejnym odnowieniu. Najpierw jednak warto uczciwie ustalić, czy byliśmy uzależnieni od VMware, czy od tego, że przez lata nikt nie musiał niczego zmieniać.

SAP - granica przesuwa się z licencji na dane

Harmonogram jest znany: podstawowe utrzymanie SAP ECC kończy się w 2027 roku, rozszerzone za dopłatą trwa do 2030. Rok 2033, o którym często słyszymy jako o „przedłużeniu ECC”, dotyczy wyłącznie klientów, którzy do końca 2030 roku przeniosą system do SAP ERP, private edition, czyli w praktyce do RISE with SAP. Dla on-premise granicą pozostaje rok 2030.

W lipcu 2023 roku Christian Klein mówił, że nowe innowacje SAP nie będą dostępne dla klientów ERP on-premise ani dla systemów hostowanych u hiperskalerów. W maju 2026 roku SAP częściowo zmienił zdanie: większość asystentów i agentów SAP Joule ma trafić także do ECC i S/4HANA on-premise, ale dla klientów, którzy zobowiązali się do migracji większości krajobrazu. AI na on-premise staje się w ten sposób elementem umowy migracyjnej.

Większa zmiana dotyczy danych. Nota SAP 3255746 od lat ogranicza użycie interfejsu ODP-RFC do wynoszenia danych z systemów SAP do narzędzi innych producentów. W 2026 roku ograniczenie przestało być zapisem w nocie: według Qlik, Matillion i Theobald Software SAP wprowadził techniczną blokadę z możliwością tymczasowego wyłączenia do końca 2026 roku. Hurtownia u innego dostawcy nadal jest możliwa, ale droga do niej prowadzi przez rozwiązania wskazane przez SAP.

Niemieckie stowarzyszenie użytkowników DSAG zapytało w raporcie inwestycyjnym 2026 swoich członków o nową wizję SAP Business Suite. Dla 62% badanych jest ona słabą podstawą planów inwestycyjnych albo w ogóle nią nie jest, a 70% wskazuje licencje i kontrakty SAP jako wyzwanie.

Jeden model danych od finansów po logistykę i jeden dostawca odpowiedzialny za poprawki bezpieczeństwa oraz lokalizacje prawne, takie jak KSeF i JPK, to realna wartość, za którą wiele firm świadomie płaci uzależnieniem. Uważam, że dla wielu firm standaryzacja na SAP była jedną z najtańszych decyzji ostatnich dwudziestu lat.

Najbardziej zajmuje mnie tu własność danych. Jeżeli producent decyduje, którym interfejsem dane wolno wynieść z ERP, to część decyzji o hurtowni albo platformie AI zapada poza firmą. Rok 2033 też ma swoją cenę: odroczenie decyzji kosztuje, więc dobrze, żeby ktoś ten koszt policzył, zanim termin zacznie decydować za nas.

UiPath - otwarte protokoły, zamknięte centrum

UiPath otwiera dziś platformę na zewnątrz. Maestro orkiestruje agentów zbudowanych w LangChain, u Anthropic czy w Microsoft, platforma obsługuje MCP i A2A, a jesienią 2025 roku firma ogłosiła partnerstwa z OpenAI, NVIDIA, Google, Microsoft i Snowflake. Jednocześnie od maja 2025 roku agentów UiPath rozliczamy w jednostkach Platform Units, a orkiestracja, kolejki, poświadczenia, logi audytowe i cała historia operacyjna procesów zostają w Orchestratorze.

Otwarty protokół nie przenosi zasobów. Procesu zapisanego w XAML z aktywnościami UiPath nie przekonwertujecie do innej platformy - trzeba go przepisać. To samo dotyczy Power Automate, który wiąże automatyzację z Entra ID i Dataverse, oraz Blue Prism z własnym formatem pakietów.

Alternatywa „open source” też wymaga przeczytania licencji. n8n działa na Sustainable Use License, która dopuszcza użycie wyłącznie do wewnętrznych celów biznesowych i nie jest licencją open source w rozumieniu OSI. Licencje OSI mają m.in. Robot Framework, Temporal i LangGraph, ale warstwa operacyjna LangGraph jest już produktem komercyjnym.

W automatyzacji ścieżkę wybieramy w praktyce przy pierwszym wdrożeniu. Gdy przepisanie procesów kosztuje więcej niż kilka lat licencji, zmiana platformy przestaje być realną opcją, niezależnie od liczby obsługiwanych protokołów. MCP otwiera integrację, ale orkiestracja i licencja zużyciowa zostają u producenta.

Szerzej o tym, gdzie kończy się robot, a zaczyna agent, pisałem w tekście Agent czy przemianowany robot.

Open source też potrafi zamknąć drzwi

W 2023 roku HashiCorp zmienił licencję Terraform z MPL 2.0 na Business Source License, a społeczność odpowiedziała forkiem OpenTofu. W 2025 roku HashiCorp przeszedł do IBM za 6,4 mld USD. Redis w 2024 roku porzucił licencję BSD, co dało początek Valkey pod Linux Foundation, a w 2025 roku wrócił do licencji open source, dodając AGPLv3. Elastic przeszedł tę samą drogę w obie strony. W sierpniu 2025 roku Broadcom przeniósł większość obrazów Bitnami do archiwum bez aktualizacji, zostawiając pełny katalog w płatnej ofercie. W kwietniu 2026 roku repozytorium MinIO zostało zarchiwizowane z dopiskiem, że nie jest już utrzymywane.

Open source zmienia rodzaj uzależnienia. Mniej zależycie od licencji, bardziej od tego, czy w organizacji jest ktoś, kto utrzyma fork, gdy firma stojąca za projektem zmieni zasady.

Ryzyko rzadziej leży więc w samej licencji, częściej w modelu biznesowym jednej firmy stojącej za projektem i w tym, czy ktoś u Was utrzyma kod bez niej. Powrót Redis i Elastic do licencji OSI pokazuje przede wszystkim, że zasady potrafią zmieniać się w obie strony.

Chmura - wyjście bez opłat, ale nie bez kosztów

Formalnie wyjście z chmury nigdy nie było tańsze. Od 12 stycznia 2027 roku Data Act zakazuje dostawcom usług przetwarzania danych pobierania opłat za zmianę dostawcy. AWS, Google Cloud i Microsoft Azure od 2024 roku nie pobierają opłat za transfer danych przy wyprowadzce, choć każdy na własnych warunkach - AWS daje od września 2025 roku 90 dni na migrację.

Mimo to Gartner prognozuje, że wydatki na chmurę publiczną wzrosną w 2026 roku o 21,3%. 37signals deklaruje, że wyjście z chmury zaoszczędzi mu ponad 10 mln USD w pięć lat, ale to deklaracja firmy bez niezależnego audytu i dotyczy firmy o wyjątkowo przewidywalnym obciążeniu. Przy wyjściu z chmury więcej niż transfer danych kosztuje zwykle zastąpienie usług zarządzanych, których nie ma poza chmurą danego dostawcy, przebudowa architektury zbudowanej pod te usługi i nowe kompetencje zespołu.

Drugi wątek to suwerenność cyfrowa. W czerwcu 2025 roku przedstawiciel Microsoft France zeznał pod przysięgą przed francuskim Senatem, że nie może zagwarantować, że dane francuskich obywateli nie trafią do władz USA. AWS uruchomił w styczniu 2026 roku European Sovereign Cloud z pierwszym regionem w Brandenburgii. Szlezwik-Holsztyn przeniósł w 2025 roku pocztę całej administracji na Open-Xchange i Thunderbird, a Międzynarodowy Trybunał Karny przechodzi na openDesk.

Dla mnie sprawdzianem jest to, czy środowisko da się odtworzyć poza chmurą z kodu, czy można tylko odzyskać dane. Rachunek 37signals dotyczy obciążeń przewidywalnych, więc zanim zaczniemy mówić o repatriacji, sprawdziłbym, ile takich naprawdę mamy. Nie jestem też przekonany, że suwerenna chmura amerykańskiego dostawcy z europejską spółką rozwiązuje problem z francuskiego Senatu. Raczej przenosi go o jeden szczebel własności wyżej.

Przy modelach AI mechanizm jest ten sam. Według Menlo Ventures, inwestora Anthropic, tylko 11% firm zmieniło w ciągu roku dostawcę modelu, choć zmiana jest technicznie prosta. MCP trafił w grudniu 2025 roku do fundacji pod Linux Foundation, ale prompty, ewaluacje i dane zostają tam, gdzie je zbudowaliście. Własne próby z modelami uruchamianymi lokalnie opisałem przy porównaniu Mac Studio i DGX Spark.

DORA i KSC - plan wyjścia staje się obowiązkiem

DORA od stycznia 2025 roku wymaga od instytucji finansowych testowanej strategii wyjścia dla usług ICT wspierających funkcje krytyczne lub ważne. 18 listopada 2025 roku europejskie urzędy nadzoru wskazały 19 krytycznych zewnętrznych dostawców ICT, w tym AWS, Google Cloud, Microsoft i SAP. Jednym z kryteriów była zastępowalność usług. Mamy więc wymóg testowanego planu wyjścia od dostawców, których regulator sam uznał za trudnych do zastąpienia.

W Polsce nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa obowiązuje od 3 kwietnia 2026 roku, a termin na wniosek o wpis do wykazu podmiotów kluczowych i ważnych minął 3 października. Zarządzanie ryzykiem łańcucha dostaw jest od tego dnia obowiązkiem ustawowym. O tym, jak ten obowiązek wygląda w systemach SAP, pisaliśmy przy KSC, NIS2 i SecurityBridge.

Plan wyjścia, który istnieje wyłącznie jako dokument dla audytora, nie wytrzyma pierwszej realnej zmiany warunków. Do rejestru ryzyk dostawców dopisałbym też pozycję, której w wielu rejestrach brakuje: producent zmienia zasady licencjonowania w trakcie umowy.

Jaką ścieżkę wybierzemy

Nie uważam, że vendor lock-in jest z natury zły. Każda decyzja architektoniczna jest jakimś uzależnieniem - od producenta, od społeczności, od własnego zespołu albo od jednego inżyniera, który rozumie konfigurację. Problem zaczyna się wtedy, gdy uzależnienie jest przypadkowe, a jego koszt poznajemy dopiero przy odnowieniu umowy.

Zanim zapadnie u nas decyzja o kolejnej platformie, chcę wiedzieć pięć rzeczy. Ile kosztuje wyjście, policzone dziś, a nie w dniu, w którym będzie potrzebne. Kto i w jakim formacie wyniesie dane bez zgody producenta. Co trzeba będzie przepisać, a co da się przenieść. Co się stanie, gdy producent zmieni licencję w połowie umowy, i czy umowa coś na ten temat mówi. I czy mamy ludzi, którzy utrzymają alternatywę, jeśli ją wybierzemy.

A Wy - które uzależnienie w swojej architekturze wybraliście świadomie, a które odkryliście dopiero przy fakturze?

Jeśli taka decyzja czeka Was w najbliższych miesiącach, chętnie przejdę ją z Wami. W SNOK robimy to w ramach doradztwa i integracji IT.

Źródła

Tematy:Innevendor lock-inVMwareBroadcomSAPUiPathopen sourcesuwerenność cyfrowaDORAchmura
Spodobał się artykuł? Proszę podać go dalej:

Skontaktuj się z nami