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 workflow redakcji, danych strukturalnych, przekierowań i zaufania przy cutoverze.
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, schema, preview, 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ł big-bang rewrite. Trasy były grupowane po ryzyku: treści statyczne najpierw, powierzchnie dynamiczne później, checkout albo konta dopiero po osobnej walidacji.
Kontrola ryzyka
Checklist migracyjny obejmował mapy 301, canonicale, parytet sitemap, parytet danych strukturalnych, wymiary obrazów, preview redakcyjne, invalidację cache i monitoring po cutoverze.
Rollback był częścią planu. Stary front WordPress pozostawał dostępny, dopóki nowy front nie udowodnił parytetu na krytycznych szablonach.