Przejdź do treści
Migracje 3 min czytania

Migracja sklepu custom na Shopware 6 - modernizacja stack'u

Sklepy custom z 2010-2015 roku to specyficzna kategoria. Każdy jest unikalny - własny framework PHP, własne moduły, własne integracje. Działają, ale: PHP 5.6, MySQL 5.5, brak supportu vendora, deweloper który je zbudował dawno odszedł. To bomby zegarowe. Migracja na dojrzałą platformę (Shopware 6, Magento 2, ew. Sylius) to często kwestia czasu.

Jakub Owsianka Autor
Zaktualizowano:
Okladka artykulu: Migracja sklepu custom na Shopware 6 - modernizacja stack'u (kategoria: Migracje)
Okladka artykulu: Migracja sklepu custom na Shopware 6 - modernizacja stack'u (kategoria: Migracje)
Spis treści (6)

W skrócie

  • 1. Custom sklepy starego pokolenia: PHP 5.6/7.0, własny framework, brak vendora
  • 2. Ryzyko: brak patchy security, brak deweloperów, niemożność dodawania nowych funkcji
  • 3. Target Shopware 6: Symfony stack, łatwy dla zespołu PHP, dobre B2B w Enterprise B2B Suite
  • 4. Czas: 6-10 miesięcy
  • 5. Koszt: 600-1500 tys. zł

Dlaczego custom „działający" to ryzyko

1. Brak security patchy. PHP 5.6 koniec wsparcia 2018. PHP 7.0 koniec 2018. Każda znana luka aktywnie używana.

2. Brak deweloperów. Junior PHP dev w 2026 zna Laravel / Symfony. Twój sklep custom z 2013 - nikt nie chce z tym pracować.

3. Niemożność integracji. Nowe API ERP / KSeF / płatności - projektowane pod modern stack. Custom PHP 5.6 trudne do podpięcia.

4. Compliance. PCI DSS, RODO, KSeF - wymagają supportowanego stacku. Custom PHP 5.6 nie przejdzie.

5. Wzrost biznesu. Sklep ma działać dla 50k+ SKU. Custom code z 2013 nie skaluje się.

Dlaczego Shopware (nie Magento)

Plus Shopware:

  • Symfony stack - natural dla developerów PHP z modern doświadczeniem
  • Łatwiejsza krzywa uczenia (3-6 mies. dev do produktywności)
  • Czysta architektura (vs. Magento legacy)
  • Headless out-of-the-box (jeśli celujesz)

Minus Shopware:

  • Mniejszy polski ekosystem (mniej integracji ERP gotowych)
  • Mniej deweloperów na rynku PL
  • Brak Data Migration Tool (custom → SW)

Magento alternative:

  • Większy ekosystem PL (lepszy dla Comarch XL, Subiekt)
  • Adobe Commerce ma więcej B2B features
  • Ale: starsza architektura, więcej legacy

Wybór: dla projektów greenfield z zespołem Symfony - Shopware. Dla integracji z polskim ERP, dojrzałe B2B - Magento.

Shopware 6 dla B2B.

Custom → Shopware - co konkretnie zmienia

1. Database schema. Twoja products table → Shopware product entity. Mapowanie 1:1 rzadkie. Re-modeling.

2. Custom features. Twój „configurator produktów" w PHP → Shopware needs custom plugin. Re-implementation.

3. Frontend. Twój Twig templates → Shopware Storefront templates (Twig też, ale inny structure). Re-design.

4. Backend / admin. Twój panel admin → Shopware Administration (Vue 3 SPA). Możesz dorabiać extensions.

5. Integracje. Twoje custom integracje (ERP) → re-implement jako Shopware plugins.

Plan migracji

Faza 1: Discovery (3-5 tygodni).

  • Audyt custom kodu (linia po linii czasem)
  • Inwentaryzacja funkcji
  • Decyzje: które migrate, które porzucić, które re-design

Faza 2: Setup Shopware (3-5 tygodni).

  • Instalacja Shopware 6
  • Decyzja: Community vs. Enterprise (jeśli B2B)
  • Theme bazowy (custom branding)

Faza 3: Re-implementacja custom funkcji (12-20 tygodni).

  • Każda istotna funkcja custom → plugin Shopware
  • Testy unit + integration

Faza 4: Data migration (4-8 tygodni).

  • Custom ETL script (no DMT dla tej ścieżki)
  • Klienci, produkty, zamówienia historyczne

Faza 5: Integracje (6-12 tygodni).

  • ERP, płatności, kurierzy
  • Każde jako Shopware plugin

Faza 6: UAT + cutover (4-6 tygodni).

Razem: 7-11 miesięcy.

Koszt

Dla średniej skali:

  • Discovery + projekt: 50-100 tys. zł
  • Setup + theme: 60-120 tys. zł
  • Custom re-implementation: 250-600 tys. zł (najwięcej)
  • Data migration: 60-150 tys. zł
  • Integracje: 150-350 tys. zł
  • SEO + UAT + cutover: 40-100 tys. zł

Razem: 600-1400 tys. zł, 7-11 miesięcy.

Najczęstsze problemy

1. Niedoszacowanie custom logiki. „Mamy 5 custom funkcji" → 25. Każda zaprojektowana w PHP 5.6 inaczej niż w nowoczesnym Symfony.

2. Brak dokumentacji custom kodu. Stary sklep bez README, bez komentarzy, bez testów. Reverse engineering kodu = tygodnie analizy.

3. Stara baza danych z chaosem. Migracje robione ręcznie przez lata. Schema dziwna. Mapping → custom.

4. Klient oczekuje 1:1 migracji. „Wszystko ma działać tak samo". Trudne - Shopware ma inne defaults. Część funkcji wymaga re-design.

5. Brak zespołu Symfony / Shopware. Zespół custom kodu nie zna Shopware. Rekrutacja lub agency partnership.

FAQ

Czy mogę zmodernizować custom in-place (upgrade PHP)? Można częściowo. PHP 5.6 → 8.2 to projekt sam w sobie (refactor incompatibility). Czasem łatwiej migrate na modern platform.

Czy lepsze Shopware czy Sylius dla custom → modern PHP? Oba na Symfony. Shopware dla typowych sklepów. Sylius dla bardzo nietypowych use-case'ów (multi-tenant SaaS).

Co ze starymi zamówieniami z poprzedniej dekady? Najczęściej: ostatnie 3-5 lat do nowego sklepu, starsze do PDF archive.

Czy mogę utrzymać domyślny URL z custom? Tak - Shopware pozwala konfigurować URL structures. Plus 301 redirects dla zmian.

Czy migracja zwraca się ROI? Tak, ale w dłuższym terminie (2-3 lata). Krótkoterminowo: 600 tys. zł wydatek. Średnio: brak ryzyka security, nowe funkcje, wzrost sprzedaży.

Co dalej

O autorze

Jakub Owsianka

Architekt rozwiązania w WiseB2B - silniku platform B2B. Zaczynał po stronie biznesu (własne sklepy), potem deweloper, dziś projektuje wdrożenia dla sklepów z katalogami w dziesiątkach tysięcy SKU. W ostatnich latach wdrożył AI-development w zespole i funkcjonalności oparte o AI bezpośrednio w silniku sklepu.

Masz pytanie do tego artykułu?

Dodatkowy kontekst, problem z własnym wdrożeniem, druga opinia - napisz wprost. Odpowiadam osobiście w 1-2 dni robocze.