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ł kotwiczy się w filarze usług headless WordPress i łączy z matrycą decyzyjną Next.js vs Astro po stronie frameworka oraz z Cloudflare Workers i WordPress na brzegu sieci po stronie warstwy runtime’u.
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ę.
Cztery fazy w realnym czasie
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, wersje 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 harmonogram
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.
Co skraca harmonogram
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.
Kiedy odpowiedź “sześć tygodni” jest zła
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.
Kiedy odpowiedź “szesnaście tygodni” jest zła
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.
Jak wygląda wycena
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 filar usług headless WordPress po model współpracy oraz O WPPoland po informacje o zespole i domyślnej jurysdykcji UE.
Cluster reading
Artykuły wspierające w klastrze, po tematach.
- Cloudflare Workers i WordPress na brzegu sieci o warstwie runtime’u nowego stosu.
