Kiedy migracja sklepu internetowego to decyzja biznesowa?

Migracja sklepu internetowego, czyli replatforming, przestaje być projektem IT, gdy obecna platforma blokuje wzrost GMV, utrudnia ekspansję zagraniczną albo generuje TCO wyższe niż koszt nowego systemu. W takiej sytuacji decyzja o zmianie technologii powinna wynikać z business case’u, a nie wyłącznie z ograniczeń technicznych. Ten przewodnik pokazuje, jak CEO i CFO mogą policzyć NPV, ocenić wpływ migracji na konwersję, time-to-market i koszty operacyjne oraz podjąć decyzję opartą na danych.

Czym jest migracja sklepu internetowego z perspektywy biznesowej?

Migracja sklepu internetowego, czyli replatforming, to przeniesienie sklepu na inną platformę e-commerce, ale z perspektywy zarządu nie jest to wyłącznie zmiana technologii. To strategiczna decyzja biznesowa, która wpływa na zdolność firmy do skalowania GMV, obsługi większego katalogu produktów, wejścia na nowe rynki, integracji z kolejnymi kanałami sprzedaży i szybszego wdrażania nowych modeli biznesowych.

W ujęciu technicznym migracja oznacza przeniesienie danych, funkcji, integracji, szablonów i procesów na nowe środowisko. W ujęciu biznesowym chodzi o coś szerszego: czy obecna platforma wspiera wzrost, czy zaczyna go blokować. Jeśli każda zmiana wymaga kosztownego wdrożenia, ekspansja zagraniczna jest trudna, checkout ogranicza konwersję, a utrzymanie systemu pochłania coraz większy budżet, replatforming staje się decyzją o przyszłej efektywności firmy.

Dlatego CEO nie powinien traktować migracji jako zadania przekazanego wyłącznie CTO lub działowi IT. Nowa platforma wpływa na sprzedaż, marketing, logistykę, obsługę klienta, finanse i tempo rozwoju całej organizacji. Według danych Digital Commerce 360 już 46% retailerów online uznawało replatforming za priorytet, co pokazuje, że zmiana platformy coraz częściej jest elementem strategii wzrostu, a nie reakcją na pojedynczy problem techniczny (Digital Commerce 360, „2023 Leading Vendors Report”, za: Noibu, „Risks of ecommerce replatforming you should know”, dostęp: 28-05-2026).

Migracja jako projekt IT a migracja jako decyzja biznesowa

Projekt IT skupia się na tym, czy sklep zostanie poprawnie przeniesiony: dane będą kompletne, integracje zadziałają, a nowy system uruchomi się bez krytycznych błędów. Decyzja biznesowa odpowiada na inne pytanie: czy nowa platforma zwiększy potencjał sprzedaży, obniży TCO, skróci time-to-market i umożliwi skalowanie firmy bez ciągłego dokładania kosztownych obejść technologicznych.

7 sygnałów biznesowych, że Twoja platforma hamuje wzrost

Platforma zaczyna hamować wzrost wtedy, gdy koszt wdrożenia nowej funkcji rośnie szybciej niż przychód, który ta funkcja może wygenerować. To moment, w którym firma przestaje inwestować w rozwój e-commerce, a zaczyna finansować utrzymanie ograniczeń obecnego systemu. Z perspektywy CEO i CFO replatforming warto rozważyć szczególnie wtedy, gdy problem jest widoczny nie tylko w IT, ale też w GMV, konwersji, marży, kosztach operacyjnych i tempie wejścia na nowe rynki.

Najczęstsze sygnały biznesowe to:

• plateau GMV – sprzedaż nie rośnie przez co najmniej 3 kwartały mimo aktywnych działań marketingowych, zwiększania budżetów reklamowych i pracy nad ofertą. Jeśli ruch rośnie, a GMV pozostaje płaskie, problem może leżeć w wydajności platformy, UX, ograniczeniach checkoutu albo jakości ścieżki zakupowej;

• rosnące TCO – całkowity koszt posiadania platformy rośnie przez poprawki, utrzymanie, ręczne obejścia i indywidualne wdrożenia, ale nie przekłada się na proporcjonalny wzrost sprzedaży. To sygnał, że firma płaci coraz więcej za stabilizowanie obecnego systemu, zamiast finansować rozwój;

• blokada cross-border – platforma utrudnia obsługę wielu języków, walut, stawek VAT, metod płatności, dostaw zagranicznych i lokalnych wersji sklepu. Wtedy barierą wejścia na nowe rynki nie jest popyt, ale infrastruktura;

• zbyt długi time-to-market – jeśli wdrożenie nowej funkcji trwa dłużej niż 6 miesięcy, firma traci możliwość szybkiego testowania nowych modeli sprzedaży, kampanii i usprawnień UX. W branżach sezonowych opóźnienie może oznaczać utratę całego okna sprzedażowego;

• problemy z pikami sprzedażowymi – platforma nie radzi sobie z Black Friday, Q4, premierami produktów albo kampaniami o wysokim natężeniu ruchu. Każdy pik sprzedażowy staje się wtedy testem awaryjności, a nie okazją do zwiększenia przychodów;

• brak obsługi nowych modeli biznesowych – system nie pozwala sprawnie uruchomić B2B, subskrypcji, sprzedaży pakietowej, marketplace’u własnego, personalizacji cen albo programów lojalnościowych. To ogranicza strategiczne scenariusze wzrostu, nawet jeśli firma ma na nie popyt i budżet;

• konwersja poniżej benchmarku – klienci porzucają koszyk z powodu wolnej strony, nieintuicyjnego checkoutu, ograniczonych metod płatności lub słabego mobile UX. Jeśli CR jest niższy niż benchmark branżowy, a testy marketingowe nie poprawiają wyniku, problem może wynikać z samej platformy.

Dług technologiczny i rosnące koszty utrzymania

Dług technologiczny z perspektywy CEO i CFO oznacza sytuację, w której firma regularnie płaci za konsekwencje wcześniejszych decyzji technologicznych. Nie chodzi wyłącznie o stary kod, ale o każdy proces, który wymaga ręcznej pracy, kosztownych obejść, niestandardowych integracji albo długiego oczekiwania na wdrożenie prostej zmiany.

Najprostszy sposób oceny długu technologicznego to porównanie dev hours przeznaczanych na utrzymanie i rozwój. Jeśli ponad 50% budżetu IT lub czasu devteamu pochłaniają poprawki, awarie, aktualizacje, ręczne obejścia i stabilizacja obecnego systemu, ROI devteamu zaczyna spadać. Zespół technologiczny przestaje wtedy zwiększać wartość biznesową, a coraz częściej tylko utrzymuje platformę przy życiu.

W business case dla replatformingu warto policzyć nie tylko koszt nowej platformy, ale też koszt utrzymania obecnej: godziny zespołu, opóźnione wdrożenia, utracone kampanie, niewdrożone funkcje i niższą konwersję. W materiałach branżowych dotyczących replatformingu jako typowe powody zmiany wskazuje się m.in. ograniczenia skalowania, wysokie koszty utrzymania, problemy z UX, ekspansją i nowymi modelami sprzedaży.

TCO replatformingu, ile naprawdę kosztuje migracja (i ile kosztuje brak migracji)?

TCO replatformingu, czyli Total Cost of Ownership, obejmuje znacznie więcej niż sam koszt wdrożenia nowej platformy. W business case trzeba uwzględnić subskrypcję lub licencję, hosting, integracje, pracę agencji, dev hours, bezpieczeństwo, utrzymanie, szkolenia zespołu oraz koszty dalszego rozwoju. Dopiero pełne TCO pokazuje, czy migracja sklepu jest inwestycją w skalowanie, czy tylko kosztowną wymianą systemu.

Z perspektywy CFO równie ważne jest policzenie drugiej strony równania: ile kosztuje brak migracji. Status quo może wyglądać taniej w budżecie miesięcznym, ale generować ukryte koszty: rosnący dług technologiczny, długi time-to-market, utracone kampanie, niższą konwersję, brak cross-border, ręczną obsługę procesów i spadek efektywności devteamu. Jeśli obecna platforma wymaga coraz większego budżetu tylko po to, aby utrzymać bieżące działanie, jej realny TCO może być wyższy niż koszt przejścia na nowoczesne rozwiązanie.

W praktyce TCO warto liczyć w horyzoncie 3-letnim. Pozwala to porównać CAPEX, czyli koszt wdrożenia i developmentu początkowego, z OPEX, czyli kosztami miesięcznymi: subskrypcją, hostingiem, maintenance, supportem, integracjami i dalszym rozwojem. Przykładowo Shopify Plus zaczyna się od około 2100 EUR miesięcznie przy 3-letniej umowie, a jego realny koszt zależy od aplikacji, integracji, agencji i zakresu wdrożenia. IdoSell działa w modelu abonamentowym z planami od niższych pakietów dla mniejszych sklepów po warianty biznesowe i enterprise. Magento Open Source nie ma opłaty licencyjnej, ale wymaga osobnego budżetu na hosting, bezpieczeństwo, development i utrzymanie, natomiast Adobe Commerce jest modelem płatnym, zwykle wycenianym indywidualnie lub od kilkudziesięciu tysięcy dolarów rocznie w zależności od skali.

Struktura TCO per model: SaaS, Open Source, custom/dedykowany

Porównanie TCO warto prowadzić nie tylko na poziomie kosztu wdrożenia, ale także kosztów miesięcznych, integracji, hostingu, bezpieczeństwa i tempa rozwoju platformy. Dopiero takie zestawienie pokazuje, czy dany model jest korzystny w 3-letnim horyzoncie, czy tylko wygląda taniej na starcie.

Źródło: Opracowanie własne na podstawie publicznych cenników i analiz kosztów Shopify Plus, IdoSell, Magento / Adobe Commerce oraz orientacyjnych kosztów utrzymania custom development. Widełki są szacunkowe i zależą od skali sklepu, liczby integracji, GMV, zakresu migracji danych, wymagań bezpieczeństwa, modelu współpracy z agencją i udziału zespołu in-house. 

Brak migracji też ma swoje TCO, choć rzadko jest widoczny jako jedna pozycja w budżecie. Najczęściej składają się na niego: dev hours zużywane na utrzymanie zamiast rozwój, koszty awarii, wolniejsze wdrażanie funkcji, brak integracji z nowymi kanałami sprzedaży, utracone przychody z cross-border i niższa konwersja wynikająca z ograniczeń UX lub wydajności.

ROI replatformingu nie powinno być liczone wyłącznie jako oszczędność na hostingu lub licencji. Najważniejszy zwrot często pochodzi z odblokowanych przychodów: wyższego CR, szybszego uruchamiania kampanii, łatwiejszego wejścia na marketplace’y, krótszego time-to-market i mniejszego udziału ręcznej pracy w obsłudze sklepu. Jeśli nowa platforma obniża TCO, skraca wdrażanie funkcji i pozwala zwiększyć GMV bez proporcjonalnego wzrostu kosztów operacyjnych, migracja zaczyna być decyzją inwestycyjną, a nie kosztem IT.

Build vs Buy vs SaaS, strategiczny wybór modelu platformy

Decyzja „build vs buy vs SaaS” nie powinna zaczynać się od porównania funkcji w tabeli dostawców, ale od odpowiedzi na pytanie, jak firma chce rosnąć. Innego modelu potrzebuje sklep z GMV na poziomie kilku milionów złotych, który chce szybko wejść na kolejne rynki, a innego organizacja B2B enterprise z niestandardową logiką cen, konfiguratorami, procesem ofertowania i integracją z wieloma systemami wewnętrznymi.

Dla większości e-commerce o GMV w przedziale 1–50 mln zł rocznie właściwym punktem wyjścia jest SaaS. Ten model ogranicza CAPEX, daje przewidywalny OPEX, skraca time-to-market i pozwala korzystać z funkcji rozwijanych przez dostawcę platformy. Shopify Plus oferuje m.in. expansion stores w ramach organizacji Plus, a IdoSell komunikuje możliwość zarządzania wieloma sklepami z jednego panelu, z obsługą wielu języków i walut.

Open source, np. Magento lub Adobe Commerce, ma sens wtedy, gdy firma potrzebuje głębszej customizacji, ale akceptuje większą odpowiedzialność za hosting, security, aktualizacje, development i utrzymanie. To model dla organizacji, które mają budżet na stały zespół techniczny albo partnera wdrożeniowego, a jednocześnie potrzebują większej kontroli nad architekturą niż w typowym SaaS.

Custom, czyli system dedykowany, powinien być wyjątkiem, a nie ambicją samą w sobie. Ma uzasadnienie przy unikalnych modelach biznesowych: złożonym B2B, konfiguratorach produktów, niestandardowej logice zamówień, marketplace’ach własnych albo procesach, których nie da się racjonalnie obsłużyć gotową platformą. W przeciwnym razie firma może wpaść w prestige trap: zbudować drogi, „własny” system, który pochłania większość budżetu, zanim zacznie realnie pracować na sprzedaż. Sellision opisuje podobne ryzyko przy wdrożeniach dedykowanych: 90% budżetu trafia w technologię, a tylko 10% zostaje na marketing, zatowarowanie czy materiały sprzedażowe.

Strategicznie warto stosować zasadę 80/20: jeśli 80% potrzeb biznesu można obsłużyć funkcjami platformy, integracjami, API, headless commerce lub composable commerce. Budowa systemu od zera zwykle nie ma uzasadnienia. Custom development warto zostawić dla tych 20% procesów, które faktycznie tworzą przewagę konkurencyjną.

Źródło: Opracowanie własne na podstawie dokumentacji i cenników Shopify Plus, IdoSell oraz Adobe Commerce/Magento. Rekomendacje w tabeli mają charakter strategiczny i zależą od GMV, złożoności modelu biznesowego, zasobów devteamu, wymagań integracyjnych oraz oczekiwanego time-to-market.

Kiedy SaaS jest właściwym wyborem?

SaaS jest właściwym wyborem wtedy, gdy priorytetem firmy jest szybki start, przewidywalny koszt utrzymania i krótszy time-to-market. Dotyczy to szczególnie sklepów, które nie mają dużego devteamu, nie chcą finansować stałego utrzymania infrastruktury i potrzebują gotowych funkcji rozwijanych przez dostawcę platformy.

Typowi migranci na SaaS to firmy, które przerosły poprzedni system, ale nie mają uzasadnienia dla pełnego custom developmentu. Potrzebują stabilnego checkoutu, integracji z płatnościami i dostawami, obsługi marketplace’ów, automatyzacji operacyjnej oraz funkcji multistore, multijęzyk i multiwaluta dostępnych in-box albo przez gotowe integracje. W takim scenariuszu IdoSell czy Shoper mogą być rozważane nie jako „tańsza technologia”, ale jako model zarządzania ryzykiem: mniej własnej infrastruktury, mniej obowiązków security, szybsze wdrożenia i większa koncentracja zespołu na sprzedaży, marketingu oraz operacjach.

ROI migracji, jak obliczyć zwrot z inwestycji?

ROI migracji sklepu internetowego liczy się przez zestawienie 3-letniej projekcji dodatkowych przychodów i oszczędności operacyjnych z kosztem wdrożenia oraz TCO nowej platformy. W praktyce decyzja jest biznesowo mocna wtedy, gdy payback period mieści się poniżej 18 miesięcy, a dodatni NPV pokazuje, że migracja tworzy większą wartość niż pozostanie przy obecnym systemie.

Pierwszym krokiem jest ustalenie baseline, czyli punktu odniesienia. CEO i CFO powinni znać aktualny GMV, współczynnik konwersji, revenue per visitor, średnią wartość zamówienia, koszt utrzymania platformy, liczbę dev hours przeznaczanych na rozwój oraz czas wdrożenia nowych funkcji. Bez tego ROI będzie oparte na założeniach, a nie na danych operacyjnych.

Drugim krokiem jest prognoza upliftu. Migracja może poprawić konwersję przez szybsze ładowanie strony, lepszy checkout, stabilniejszy mobile UX, nowe metody płatności i łatwiejsze uruchamianie kampanii. Shopify w swoim przewodniku po replatformingu podaje przykład marki Morrison, która po migracji zwiększyła konwersję o 15%, a sprzedaż fizyczną o 10%. Z kolei badanie Portent pokazuje, że serwisy e-commerce ładujące się w 1 sekundę osiągały 2,5 razy wyższy współczynnik konwersji niż strony ładujące się w 5 sekund. Te dane warto traktować jako benchmark do scenariuszy, a nie gwarancję wyniku.

Trzeci krok to policzenie kosztów: CAPEX wdrożenia, migracji danych, integracji, projektu UX, testów, szkoleń i prac agencji oraz 3-letniego TCO nowej platformy. Czwarty krok to oszacowanie zysków: dodatkowego GMV z poprawy CR, przychodów z nowych kanałów, oszczędności OPEX, krótszego time-to-market i mniejszej liczby dev hours zużywanych na utrzymanie starego systemu.

Najprostszy model można zapisać w kilku krokach:

1. baseline – aktualny GMV, CR, AOV, revenue per visitor, koszt utrzymania i dev hours;

2. uplift – prognozowany wzrost CR, szybszy checkout, nowe kanały, krótszy time-to-market;

3. koszty – CAPEX wdrożenia plus TCO nowej platformy w horyzoncie 3 lat;

4. korzyści – dodatkowy GMV, oszczędności OPEX, mniejszy dług technologiczny i wyższa efektywność zespołu;

5. wynik – ROI, NPV i payback period.

W uproszczeniu:

ROI = (korzyści z migracji – koszt migracji) / koszt migracji × 100%.

Payback period = koszt migracji / miesięczna korzyść netto z migracji.

NPV = suma zdyskontowanych przepływów pieniężnych z migracji – koszt inwestycji początkowej.

Jeśli payback period wynosi 6–18 miesięcy, migracja zwykle ma silne uzasadnienie biznesowe, zwłaszcza gdy odblokowuje nowe rynki, kanały sprzedaży lub modele biznesowe. Jeśli zwrot przekracza 24–36 miesięcy, business case wymaga ostrożności: albo założenia dotyczące CR uplift są zbyt optymistyczne, albo koszt wdrożenia i TCO nowej platformy są zbyt wysokie względem skali GMV.

Największy błąd polega na liczeniu ROI wyłącznie jako różnicy między kosztem starej i nowej platformy. Replatforming rzadko zwraca się tylko przez niższy hosting lub tańszy abonament. Najważniejsza wartość najczęściej pochodzi z poprawy konwersji, wzrostu revenue per visitor, szybszego wdrażania funkcji, mniejszej liczby błędów operacyjnych i możliwości skalowania GMV bez proporcjonalnego wzrostu kosztów.

Źródła: Shopify, „Ecommerce Replatforming and Migration Guide for 2026”, dostęp: 29-05-2026; M. Wiegand, „Site Speed is (Still) Impacting Your Conversion Rate”, Portent, dostęp: 29-05-2026 

Kiedy migrować, żeby nie stracić?

Moment migracji sklepu internetowego ma duży wpływ na ryzyko finansowe całego projektu. Najbezpieczniej zaplanować ją 4–6 miesięcy przed ekspansją zagraniczną, wejściem w nowy kanał sprzedaży albo dużą zmianą w sposobie działania sklepu. Taki zapas czasu pozwala spokojnie wybrać platformę, przenieść dane, przetestować sklep, przeszkolić zespół i poprawić błędy przed okresem większej sprzedaży.

Najlepsze momenty na migrację to:

• okres przed ekspansją zagraniczną – sprzedaż cross-border wymaga obsługi kilku języków, walut, lokalnych metod płatności, różnych form dostawy i często osobnych wersji sklepu. Platforma powinna być gotowa przed startem ekspansji, a nie dopiero wtedy, gdy firma zaczyna kampanię na nowym rynku;

• okres po rundzie inwestycyjnej lub zatwierdzeniu większego budżetu rozwojowego – firma ma wtedy środki nie tylko na samo wdrożenie, ale też na integracje, szkolenia, analitykę, optymalizację i wsparcie zespołu po uruchomieniu nowego sklepu;

• okres niższego ruchu i sprzedaży – migrację najlepiej przeprowadzić poza sezonem, gdy ewentualne błędy nie wpływają na najważniejszy okres przychodowy. Dla wielu sklepów oznacza to przygotowanie zmian kilka miesięcy przed Q4, a nie tuż przed nim;

• moment przed wejściem w nowy kanał sprzedaży – jeśli firma planuje marketplace, B2B, subskrypcje albo sprzedaż omnichannel, platforma powinna wcześniej obsługiwać potrzebne integracje, cenniki, procesy zamówień i raportowanie.

Najgorsze momenty na migrację to:

• Black Friday, Cyber Monday i Q4 – to okresy, w których każda godzina niedostępności sklepu, problem z koszykiem albo błąd płatności może oznaczać bezpośrednią utratę przychodu;

• kilka tygodni przed dużą kampanią marketingową – jeśli nowa platforma nie została dobrze przetestowana, kampania może wygenerować ruch, którego sklep nie obsłuży poprawnie;

• szczyt sezonu w danej branży – dla sklepów ogrodniczych może to być wiosna, dla branży fashion okres wyprzedaży, a dla zabawek i prezentów końcówka roku. Migracja w takim czasie zwiększa presję na zespół i ogranicza przestrzeń na spokojne poprawki;

• moment bez gotowego planu awaryjnego – jeśli nie ma kopii zapasowej, listy testów, mapy przekierowań 301 i osób odpowiedzialnych za reakcję na błędy, migracja staje się ryzykiem operacyjnym, a nie kontrolowanym projektem.

W praktyce Q4 powinno służyć skalowaniu sprzedaży na stabilnej platformie, a nie naprawianiu błędów wdrożeniowych. Dobrze zaplanowana migracja daje firmie czas na testy, optymalizację i spokojne wejście w kolejny etap wzrostu.

Gotowość organizacji do migracji – czy Twoja firma jest na to gotowa?

Migracja sklepu internetowego może się nie powieść nawet wtedy, gdy firma wybierze dobrą platformę e-commerce i doświadczonego partnera wdrożeniowego. Przyczyną problemów często nie jest sama technologia, ale brak przygotowania po stronie organizacji: niejasna odpowiedzialność, nieopisane procesy, słaba jakość danych i zbyt mało zasobów wewnętrznych.

Dlatego przed rozpoczęciem projektu CEO powinien sprawdzić, czy firma jest gotowa nie tylko budżetowo, ale też operacyjnie. Migracja wymaga osoby decyzyjnej po stronie biznesu, uporządkowanych wymagań, jasnych priorytetów i zespołu, który będzie dostępny na etapie analizy, testów, odbiorów oraz pracy po uruchomieniu nowej platformy.

Brak takiego przygotowania szybko prowadzi do scope creep, czyli niekontrolowanego rozszerzania zakresu projektu. W praktyce oznacza to dopisywanie nowych wymagań w trakcie wdrożenia, przesuwanie terminów, wzrost kosztów i konflikty między biznesem, IT, agencją oraz zarządem.

Gotowość organizacji do migracji warto oceniać w trzech obszarach: ludzie, procesy i technologia. Dopiero połączenie tych elementów pozwala potraktować replatforming jako kontrolowany projekt biznesowy, a nie chaotyczne przenoszenie sklepu na nowy system.

Trzy wymiary gotowości: ludzie, procesy, technologia

Pierwszy wymiar to ludzie. Migracja powinna mieć jednego właściciela projektu po stronie biznesu. Może to być product owner, interim manager albo osoba wyznaczona przez zarząd, która ma prawo podejmować decyzje, ustalać priorytety i rozstrzygać konflikty między działami. Bez takiej roli projekt łatwo staje się odpowiedzialnością „wszystkich”, czyli w praktyce nikogo.

Drugi wymiar to procesy. Przed startem warto przygotować BRD, czyli Business Requirements Document. Dokument powinien opisywać cele migracji, wymagania biznesowe, kluczowe procesy sprzedażowe i funkcje, które muszą działać od pierwszego dnia. Szczególnie ważne jest wskazanie tych elementów, które odpowiadają za największą część przychodu, np. koszyk, płatności, wyszukiwarkę, promocje, integracje z ERP, marketplace’ami i logistyką.

Trzeci wymiar to technologia. Tech readiness oznacza, że firma zna stan swoich danych, integracji i systemów krytycznych. Przed migracją trzeba sprawdzić data quality, zinwentaryzować integracje, przygotować plan backupu i określić scenariusz rollbacku, czyli powrotu do poprzedniego rozwiązania w razie poważnych problemów.

Przed uruchomieniem projektu CEO powinien zadać kilka pytań:

• Czy projekt ma jednego project ownera po stronie biznesu?

• Czy zarząd wie, jaki problem biznesowy ma rozwiązać migracja?

• Czy powstał BRD z zakresem, priorytetami i kryteriami sukcesu?

• Czy zespół zna funkcje i procesy, które generują największą część przychodu?

• Czy dane produktowe, klienckie i zamówieniowe są uporządkowane?

• Czy wszystkie integracje zostały zinwentaryzowane?

• Czy istnieje plan backupu i rollbacku?

• Czy firma ma budżet na testy, szkolenia i optymalizację po starcie?

• Czy wiadomo, kto podejmuje decyzje przy konflikcie zakresu, kosztu lub terminu?

Jeśli na więcej niż 5 pytań odpowiedź brzmi „nie”, projekt warto wstrzymać i najpierw uporządkować fundamenty. Migracja sklepu wymaga nie tylko dobrej platformy, ale też organizacji gotowej do zmiany.

Jak uzasadnić migrację przed zarządem i inwestorami?

Uzasadnienie migracji przed zarządem nie powinno zaczynać się od architektury technicznej, listy funkcji ani porównania platform. Prezentacja na board meeting musi pokazać, jaki problem biznesowy rozwiązuje replatforming i jak wpłynie na wyniki firmy: payback period, NPV, wzrost GMV, redukcję TCO oraz możliwość dalszego skalowania sprzedaży.

Najważniejsze jest pokazanie kosztu status quo. Jeśli obecna platforma ogranicza rozwój, opóźnia wdrożenia, podnosi koszty utrzymania albo blokuje ekspansję, brak migracji również jest decyzją inwestycyjną – tylko często ukrytą w bieżących kosztach. CFO, CEO i inwestorzy muszą zobaczyć, ile firma traci przez niewdrożone funkcje, niższą konwersję, długi time-to-market, ręczną obsługę procesów i niewykorzystany potencjał nowych kanałów sprzedaży.

Dobry migration business case powinien mieć prostą strukturę:

• problem statement – opis biznesowego problemu, np. plateau GMV, rosnące TCO, niska konwersja, brak cross-border readiness albo zbyt długi czas wdrażania nowych funkcji;

• opcje strategiczne – porównanie 2–3 scenariuszy, np. pozostanie na obecnej platformie, migracja na SaaS, przejście na Open Source albo budowa rozwiązania custom, z TCO dla każdej opcji;

• rekomendacja – wskazanie najlepszego wariantu wraz z uzasadnieniem finansowym, ROI, NPV, payback period i wpływem na GMV growth;

• plan wdrożenia – harmonogram, główne etapy projektu, potrzebne zasoby, budżet, odpowiedzialności i założenia operacyjne;

• plan mitygacji ryzyka – opis najważniejszych ryzyk migracji, takich jak spadki SEO, utrata danych, przestoje, błędy integracji i opóźnienia, wraz ze sposobem ich ograniczenia;

• KPI sukcesu – mierniki, które pokażą, czy migracja przyniosła oczekiwany efekt biznesowy.

→ W prezentacji dla CFO akcent powinien padać na liczby: TCO obecnej i nowej platformy, CAPEX, OPEX, payback period, NPV, koszt dev hours, oszczędności operacyjne i wpływ na marżę. CFO nie potrzebuje szczegółowego opisu technologii, tylko odpowiedzi na pytanie, czy inwestycja zwróci się w akceptowalnym czasie i czy ryzyko finansowe jest kontrolowane.

→ W rozmowie z CEO ważniejsza będzie strategia. Migrację warto pokazać jako decyzję o zdolności firmy do wzrostu: wejściu na nowe rynki, szybszym uruchamianiu kampanii, poprawie doświadczenia klienta, większej elastyczności i odporności operacyjnej. CEO powinien zobaczyć, że platforma nie jest wyłącznie kosztem IT, ale infrastrukturą, która wpływa na tempo rozwoju całej firmy.

–> Dla inwestorów najważniejsze są skalowalność i wpływ na wartość spółki. Warto pokazać, jak migracja może wspierać GMV growth, poprawę konwersji, wyższą efektywność operacyjną, lepsze multiples i mniejsze ryzyko technologiczne w kolejnych rundach finansowania lub przy potencjalnym exit. Taka narracja przesuwa rozmowę z poziomu „zmieniamy system” na poziom „usuwamy barierę wzrostu”.

Na końcu business case powinien prowadzić do jednej jasnej decyzji: zatwierdzić migrację, odłożyć ją do wskazanego momentu albo najpierw uporządkować fundamenty organizacyjne. Zarząd nie powinien otrzymać ogólnej rekomendacji „warto zmienić platformę”, ale konkretny wariant inwestycyjny z budżetem, terminem, ryzykami i miernikami sukcesu.

KPI sukcesu migracji, co mierzyć po wdrożeniu (biznesowe, nie techniczne)

Sukces migracji sklepu internetowego nie powinien być oceniany wyłącznie po tym, czy nowa platforma działa stabilnie i czy wszystkie funkcje zostały uruchomione zgodnie z harmonogramem. To ważne warunki techniczne, ale dla zarządu liczy się przede wszystkim wpływ migracji na wyniki biznesowe: konwersję, AOV, GMV, retencję klientów, koszty operacyjne i tempo wdrażania nowych inicjatyw.

Po migracji warto przygotować dashboard zarządu, który pokazuje najważniejsze KPI w porównaniu z okresem sprzed wdrożenia. Najlepiej analizować dane w ujęciu tygodniowym i miesięcznym, ale pełniejszą ocenę robić dopiero po pierwszych 90 dniach. Pierwszy miesiąc często jest okresem stabilizacji, poprawek i dostosowania zespołu do nowych procesów, dlatego pojedynczy spadek nie zawsze oznacza porażkę migracji.

Najważniejsze KPI biznesowe po migracji to:

• CR, czyli współczynnik konwersji – pokazuje, czy nowa platforma lepiej zamienia ruch w zamówienia. W business case można przyjąć scenariusze poprawy konwersji na poziomie 15–35%, ale po wdrożeniu trzeba porównywać wynik z realnym baseline sklepu i benchmarkiem branży;

• AOV, czyli średnia wartość zamówienia – pozwala sprawdzić, czy nowy koszyk, rekomendacje produktowe, promocje, pakiety lub darmowa dostawa od określonej kwoty zwiększają wartość pojedynczej transakcji;

• GMV – powinien być analizowany kwartalnie, aby oddzielić efekt migracji od sezonowości, kampanii marketingowych i zmian w ofercie. Wzrost GMV jest jednym z najważniejszych sygnałów, że platforma wspiera skalowanie sprzedaży;

• customer retention rate – pokazuje, czy klienci wracają po migracji i czy nowe doświadczenie zakupowe nie pogarsza lojalności. Spadek retencji może oznaczać problem z kontami klientów, komunikacją, obsługą posprzedażową albo zmianami w UX;

• time-to-market dla nowych funkcji – mierzy czas od pomysłu do wdrożenia nowej inicjatywy. Jeśli przed migracją uruchomienie funkcji trwało kilka miesięcy, a po migracji kilka tygodni, platforma realnie zwiększa elastyczność firmy;

• koszt obsługi klienta per zamówienie – pozwala ocenić, czy nowy system zmniejsza liczbę pytań, błędów, ręcznych interwencji, problemów z płatnościami, dostawą lub statusem zamówienia;

• wyniki cross-border – obejmują liczbę uruchomionych rynków, udział sprzedaży zagranicznej w GMV, konwersję na lokalnych wersjach sklepu, skuteczność płatności i koszt obsługi zamówień międzynarodowych;

• NPS klientów po migracji – pomaga sprawdzić, czy zmiana platformy poprawiła realne doświadczenie użytkowników, a nie tylko wewnętrzne procesy firmy.

Metryki techniczne, takie jak: uptime, szybkość ładowania strony czy liczba błędów, nadal mają znaczenie, ale powinny być traktowane jako wskaźniki wspierające. Same w sobie nie są celem migracji. Ich rola polega na tym, że pomagają wyjaśnić wyniki biznesowe: spadek CR, wzrost porzuceń koszyka, niższy NPS albo większy koszt obsługi klienta.

Najlepszy dashboard zarządu powinien pokazywać trzy warstwy danych: wynik biznesowy, przyczynę operacyjną i trend w czasie. Dzięki temu CEO i CFO widzą nie tylko, czy migracja „działa”, ale także które elementy nowej platformy wymagają dalszej optymalizacji.