Ile trwa migracja na headless WordPress w 2026 roku?

#Ile trwa migracja na headless WordPress w 2026 roku?

Od sześciu do szesnastu tygodni dla typowych projektów. Układ to cztery fazy: rozpoznanie, ustalanie zakresu, budowa i przełączenie, dostrajanie. Zmienne, które wydłużają lub skracają harmonogram, to wielkość katalogu, liczba integracji, zachowanie URL-i i gotowość zespołu redakcyjnego, a nie wybór frameworka.

Artykuł uzupełnia opis usługi headless WordPress i łączy się z matrycą decyzyjną Next.js vs Astro po stronie wyboru technologii oraz z Cloudflare Workers i WordPress na brzegu sieci po stronie środowiska uruchomieniowego.

#TL;DR

• Serwisy redakcyjne poniżej pięćdziesięciu stron: cztery do sześciu tygodni.
• WooCommerce do kilku tysięcy SKU ze standardowymi integracjami: dziesięć do czternastu tygodni.
• Multi-region lub wielojęzyczne z niestandardowymi integracjami: czternaście do szesnastu tygodni, czasem dłużej.
• Drogie tygodnie to ustalanie zakresu (tydzień pierwszy i drugi) oraz cutover (ostatni weekend), a nie sama budowa.
• Wycena jest indywidualna dla każdego projektu; publikujemy harmonogram, nie cenę.

#Jakie są etapy migracji na headless WordPress?

Fazy to nie są etykiety na wykresie Gantta; mapują się na różne tryby pracy, do których przy stole trzeba mieć innych ludzi.

#Faza 1, rozpoznanie (tydzień zerowy do drugiego)

Interesariusze, zespół redakcyjny, właściciel analityki i kontakt techniczny przechodzą przez trzy do pięciu sesji w ciągu jednego do dwóch tygodni. Produkty to audyt modelu treści, baseline wydajności pobrany z działającego serwisu (TTFB, TTI, LCP per szablon), inwentaryzacja wtyczek i integracji oraz szkic mapy migracji SEO.

Wynikiem rozpoznania są dane wejściowe do decyzji, a nie architektura. Zespół, który pomija rozpoznanie, żeby “zaoszczędzić czas”, spłaca ten koszt w tygodniu ósmym, kiedy wypływa niezgłoszona integracja i warstwę danych trzeba projektować od nowa.

#Faza 2, ustalanie zakresu (tydzień drugi do trzeciego)

Decyzja architektoniczna: Astro 5+ albo Next.js 15, wybór renderowania per route, wzorzec pobierania danych (REST lub GraphQL), strategia inwalidacji cache. Mapa przekierowań jest podpisana tu, nie później. Workflow redakcyjny zostaje sfinalizowany: podgląd, wersję robocze, harmonogramowane publikacje, obiegi z wieloma autorami.

Ustalanie zakresu kończy się pisemnym engagement letter i zamkniętą listą produktów. Cokolwiek pominięte na tym etapie wraca jako change order w tygodniu dziesiątym, czyli w najdroższym momencie na negocjowanie zakresu.

#Faza 3, budowa i przełączenie (tydzień trzeci do dwunastego)

Budowa idzie w sprintach dwutygodniowych z cotygodniowym demo. Każde demo jest na stagingu, nie na localhoście, żeby zespół widział, jak strona redakcyjna naprawdę wygląda w nowym stosie. Pierwszy sprint to design system i jeden szablon end-to-end; kolejne sprinty rozkładają się po typach szablonów.

Sam cutover to okno czterdziestu ośmiu do siedemdziesięciu dwóch godzin, zaplanowane świadomie. Działają dwa wzorce: przełączenie DNS (czystsze, wolniejszy rollback) oraz cutover na reverse proxy (szybszy rollback, więcej ruchomych części). Mapa przekierowań nakłada się na brzegu sieci, a nie w PHP.

Okno pomiarowe side-by-side biegnie tydzień do dwóch przed cutoverem. Wyłapuje regresje na tagach trackingu, walidacji schema i Core Web Vitals, zanim trafią na produkcję.

#Faza 4, dostrajanie i utrzymanie (tydzień dwunasty do szesnastego)

TTL-e cache na brzegu sieci dostraja się per route. Observability (Cloudflare Logpush, testy syntetyczne, alerty na TTFB i 5xx) zostaje wpięte. Przekazanie na utrzymanie obejmuje pracę nad nowymi funkcjami, kwartalne przeglądy Tech Radar i roadmapę pod ewoluujące potrzeby zespołu redakcyjnego.

To faza, którą najczęściej się pomija. Pominięcie kosztuje pół roku drobnych incydentów, których zespół nie umie zdiagnozować, bo nic nie jest oprzyrządowane.

#Co wydłuża migrację na headless WordPress

Trzy wzorce pchają sześciotygodniowy projekt do dwunastego tygodnia, a dwunastotygodniowy do dwudziestego.

Późne wykrycie integracji. Niestandardowa bramka płatności, integracja ze starszym ERP po SOAP, niszowa wtyczka bez powierzchni REST. Każda dokłada własny adapter. Każdy adapter to dwa do czterech tygodni budowy plus negocjacja umowy, jeśli stronę upstream trzyma ktoś trzeci.

Zachowanie URL-i. Serwis z trzydziestoma unikalnymi wzorcami URL to praca mechaniczna. Serwis z trzystoma wzorcami plus restrukturyzacją permalinków to projekt sam w sobie. Mapa 301 zostaje zatwierdzona w fazie zakresu, a nie improwizowana w tygodniu dziesiątym.

Przebudowa modelu treści. Kiedy istniejąca treść WordPressa jest rozbita po szablonach motywu zamiast po polach strukturalnych, front-end nie konsumuje jej deterministycznie. Przebudowa modelu treści dokłada od dwóch do sześciu tygodni i wymaga dostępności zespołu redakcyjnego, którą większość ekip niedoszacowuje.

#Jak przyspieszyć migrację na headless WordPress

Cztery warunki konsekwentnie skracają harmonogram.

Czysty model treści. Custom post types, grupy pól ACF lub Meta Box, albo niedawne przejście na edytor blokowy ze strukturalnymi wzorcami. Front-end czyta dane strukturalne i renderuje deterministycznie. Oszczędność dwóch do czterech tygodni.

Istniejący design system. Biblioteka w Figmie, zestaw tokenów albo biblioteka komponentów, której zespół już używał. Oszczędność tygodnia do dwóch pracy fundamentowej w pierwszym sprincie.

Dostępność zespołu redakcyjnego. Kiedy redakcja regularnie siada do podglądów i zatwierdza obiegi, budowa nie zatrzymuje się w oczekiwaniu na wyjaśnienia. Oszczędność tygodnia do dwóch w skali projektu.

Senior po obu stronach. Senior product owner po stronie klienta skraca cykl pytanie-odpowiedź o połowę. Agencja nie wyprodukuje tego sama; musi przyjść od kupującego.

#Co sprawdzić przed migracją na headless WordPress?

Szacunek bez inwentarza to zgadywanie. Poniższą listę da się przejść w panelu i w bazie danych w jeden dzień roboczy, zanim ktokolwiek poda termin. Każdy punkt to miejsce, w którym klasyczny motyw robił coś za darmo, a headless musi to zbudować od nowa.

Typy treści i taksonomie. Ile jest custom post types i taksonomii, które z nich mają własne archiwa pod URL-ami obecnymi w indeksie. Każdy typ z archiwum to osobny szablon i osobna trasa po stronie frontendu.

Pola ACF i meta. Grupy pól, pola powtarzalne, flexible content, pola relacyjne. Sprawdź, czy są wystawione w REST API (show_in_rest) albo w schemacie WPGraphQL. Flexible content z kilkunastoma layoutami oznacza tyle samo komponentów do zbudowania.

Shortcode’y i bloki wtyczek. Treść zapisana w bazie jako shortcode przychodzi do frontendu jako surowy tekst w nawiasach kwadratowych. Policz wystąpienia zapytaniem po post_content, zanim zdecydujesz, czy je renderować, czy przepisać.

Podgląd i wersje robocze. Klasyczny motyw ma podgląd od ręki. W headless trzeba go zbudować: uwierzytelnione zapytanie o wersję roboczą i tryb podglądu po stronie frontendu. Redakcja zauważa jego brak w pierwszym tygodniu.

Formularze. Contact Form 7 czy Gravity Forms renderują się w motywie PHP. Po odcięciu motywu formularz potrzebuje endpointu, walidacji, ochrony przed spamem i klauzul zgód RODO, które wcześniej dokładała wtyczka.

Wyszukiwarka. Wbudowane ?s= znika razem z motywem. Do wyboru jest endpoint wyszukiwania w REST, zewnętrzny indeks albo indeks statyczny generowany przy buildzie. Każda opcja ma inny koszt utrzymania.

Integracje sklepu z polskiego rynku. Wtyczki bramek Przelewy24 i PayU, mapa punktów InPost przy checkoucie, eksport zamówień do Fakturowni czy wFirmy. Takie wtyczki są pisane pod checkout renderowany przez WooCommerce, więc w headless trzeba je zweryfikować względem API dostawcy, a nie kodu PHP wtyczki. To właśnie te integracje, które w rozdziale o wydłużaniu harmonogramu wypływają za późno.

Przekierowania. Eksport z wtyczki Redirection albo reguł w .htaccess, lista URL-i z sitemapy i z Google Search Console. Z tego powstaje mapa 301, którą podpisuje faza zakresu.

Wynikiem jest tabela z trzema kolumnami: element, gdzie żyje dziś, kto zbuduje go na nowo. Wiersze bez właściciela to tygodnie, których w harmonogramie jeszcze nie ma.

#Ile trwa migracja sklepu WooCommerce na headless

Sklep WooCommerce z trzema tysiącami SKU i niestandardowym checkoutem nie zmigruje się w sześć tygodni. Każdy, kto wycenia w tym czasie, sprzedaje inny zakres i przepisuje go później. Uczciwa odpowiedź dla tego profilu to dwanaście do czternastu tygodni.

Serwis multi-region z pięcioma lokalizacjami i locale-specyficznymi przepływami commerce też nie jest projektem na sześć tygodni. Workflow tłumaczeń, walidacja hreflang, locale-specyficzne strategie cache i bramki płatności per region dokładają cztery do sześciu tygodni nawet do zdrowego baseline’u.

#Ile trwa wdrożenie małej strony headless WordPress

Mały serwis redakcyjny, świeżo zbudowana instalacja WordPressa, czysty model treści i zespół seniorów potrafią wypuścić projekt w pięć tygodni. Wycena szesnastu tygodni dla tego profilu to napompowany zakres.

Greenfield headless (bez komponentu migracji, tylko nowy front na nowym WordPressie) pomija większość fazy pierwszej i skraca fazę trzecią. Łącznie sześć do ośmiu tygodni.

#Ile kosztuje migracja na headless WordPress

Wycena jest indywidualna dla każdego projektu. Nie publikujemy cen usług na publicznym serwisie. Engagement letter wiąże godziny z czterema fazami powyżej, z ustalonym capem na fazę pierwszą (jest ograniczona liczbą wywiadów, a nie czymś, co skaluje się w nieskończoność) oraz time-and-materials lub fixed-scope na fazę trzecią (zależnie od tego, jak stabilny jest zakres po fazie zakresu).

Rozliczamy w EUR lub USD, jurysdykcja UE, kontrakt B2B. Patrz opis usługi headless WordPress po model współpracy oraz O WPPoland po informacje o zespole i domyślnej jurysdykcji UE.

#Powiązane tematy

Powiązane artykuły, pogrupowane według tematu.

• Cloudflare Workers i WordPress na brzegu sieci o warstwie runtime’u nowego stosu.

#Jak samemu oszacować czas migracji headless

Zmienne, od których zależy długość projektu, da się sprawdzić samodzielnie, zanim ktokolwiek przygotuje wycenę. To one przesuwają projekt między sześcioma a szesnastoma tygodniami, framework robi różnicę najwyżej tygodnia.

• Katalog. Policz strony redakcyjne i SKU. Serwis poniżej pięćdziesięciu stron bez sklepu to inny profil niż WooCommerce z kilkoma tysiącami produktów.
• Integracje. Spisz wszystko, co wymienia dane z WordPressem: ERP, bramkę płatności, wtyczki bez powierzchni REST. Każda pozycja odkryta dopiero w trakcie budowy oznacza osobny adapter.
• Wzorce URL. Wyeksportuj listę adresów i pogrupuj je według struktury. Trzydzieści wzorców to praca mechaniczna, trzysta z restrukturyzacją permalinków to osobny projekt.
• Model treści. Sprawdź, czy treść siedzi w custom post types i polach ACF lub Meta Box, czy jest rozbita po szablonach motywu.
• Redakcja. Ustal z nazwiska, kto po waszej stronie będzie regularnie zatwierdzał podglądy i odpowiadał na pytania zespołu.

Z tą listą pierwsze sesje rozpoznania idą na weryfikację danych, które już macie, i szybciej widać, do którego profilu z sekcji TL;DR pasuje wasz serwis.