Jak wygląda architektura po migracji?
W klasycznym WordPressie wszystko jest jednym systemem: CMS, frontend, PHP, baza danych, pluginy i hosting. Każdy z tych elementów wpływa na pozostałe - dlatego aktualizacja wtyczki potrafi zepsuć wygląd strony, a problem z bazą danych zatrzymuje całą witrynę.
Po migracji te warstwy są rozdzielone. Treści żyją w CMS-ie (obecnym lub nowym, np. Sanity albo Payload), frontend to komponenty Astro w repozytorium, a całość serwowana jest z infrastruktury Cloudflare. CMS pozostaje wygodny dla marketingu, a frontend przestaje być od niego uzależniony.
W praktyce oznacza to dwa możliwe warianty: WordPress zostaje jako headless CMS i dostarcza treści przez API, albo - jeżeli jego limity realnie przeszkadzają - migrujemy treści do nowoczesnego headless CMS-a. Decyzję podejmujemy wspólnie po audycie.
Co wpływa na zakres i wycenę?
Każda migracja jest inna, dlatego nie pracujemy na cennikach z sufitu. Zakres zależy przede wszystkim od liczby typów podstron, ilości treści i wpisów w CMS-ie, liczby języków oraz integracji i formularzy, które trzeba przenieść.
Znaczenie ma też to, czy design zostaje bez zmian, czy przy okazji go odświeżamy, oraz który CMS wybierzemy docelowo.
Po audycie przygotowujemy konkretny zakres, ryzyka, rekomendowaną architekturę, harmonogram i wycenę. Dopiero wtedy podejmujesz decyzję o starcie projektu.
Co dzieje się po uruchomieniu?
Migracja nie kończy się w dniu przełączenia DNS-a. Przez pierwsze tygodnie monitorujemy indeksację, błędy 404 i Core Web Vitals, żeby mieć pewność, że Google poprawnie przepięło się na nową wersję.
Dalszy rozwój strony odbywa się już w kontrolowanym procesie: zmiany przechodzą przez repozytorium, code review i staging, a wdrożenia są automatyczne i odwracalne.
