Punkt startowy
Istniejący WordPress miał wartość redakcyjną, zaindeksowane URL-e, historyczne treści i integracje. Ryzykiem nie było to, czy Astro albo Next.js wyrenderuje strony. Ryzykiem była utrata procesu pracy redakcji, danych strukturalnych, przekierowań i zaufania przy przełączeniu.
Plan migracji traktował więc WordPress najpierw jako system treści, a dopiero potem jako warstwę renderowania.
Diagnoza
Audyt zaczynał się od typów treści, taksonomii, wzorców URL, canonicali, hreflang, danych strukturalnych, podglądu redakcyjnego, wyszukiwania i integracji.
Dopiero po tym wybór frontu miał sens: Astro dla powierzchni contentowych, Next.js tam, gdzie liczyły się przepływy zalogowane albo personalizowane.
Decyzja architektoniczna
WordPress został źródłem prawdy dla redakcji. Publiczny front przeszedł do warstwy composable z edge delivery, ścisłą mapą URL i plikiem przekierowań testowanym przed startem.
Plan celowo unikał przepisywania wszystkiego naraz. Trasy były grupowane po ryzyku: treści statyczne najpierw, powierzchnie dynamiczne później, finalizacja zakupu albo konta dopiero po osobnej walidacji.
Kontrola ryzyka
Lista migracyjna obejmowała mapy 301, canonicale, parytet sitemap, parytet danych strukturalnych, wymiary obrazów, podgląd redakcyjny, unieważnianie pamięci podręcznej i monitoring po przełączeniu.
Plan powrotu był częścią projektu. Stary front WordPress pozostawał dostępny, dopóki nowy front nie udowodnił parytetu na krytycznych szablonach.