Migracja Next.js / Astro w Zurychu

Migracja z WordPressa, Drupala, Joomli albo starszej aplikacji do Astro lub Next.js ma sens dopiero wtedy, gdy rozwiązuje mierzalny problem. W Zurychu i w Deutschschweiz takim problemem bywa wolny serwis fintech lub ubezpieczeniowy pod wymaganiami bezpieczeństwa, portal klienta ładujący kod uwierzytelnienia na marketingu, albo witryna wielojęzyczna z rozjechanym hreflang i transferami danych UE-CH. Sam wiek strony nie wystarcza. WPPoland zaczyna od audytu, a nie od wyboru frameworka. W Zurychu często widzę ten sam wzorzec: publiczne FAQ ładuje skrypty panelu, a mapa procesorów danych żyje tylko w mailach compliance, nie w repozytorium.

Przenoszę treść, adresy URL, metadane, dane strukturalne i proces publikacji jako jeden system. Frontend może się zmienić, lecz redakcja nie musi porzucać WordPressa. Przełączenie odbywa się z przygotowanym powrotem, a odbiór opiera się na danych z okresu przed i po wdrożeniu. Ten sposób pracy pasuje do zespołów Zurychu, które potrzebują polskiego i unijnego kontekstu prawnego, near-shore z Polski do Szwajcarii oraz utrzymania, które nie zależy od jednej agencji. W projektach fintech często łączę warsztaty z compliance po polsku z dokumentacją rezydencji danych po niemiecku lub angielsku, żeby marketing i dział prawny mieli ten sam diagram procesorów przed cutover.

#Migracja czy relaunch w obecnym systemie

Relaunch w WordPressie jest lepszy, gdy backend jest aktualny, zespół zna proces publikacji, a kłopot ogranicza się do ciężkiego motywu, chaotycznych bloków lub niespójnej nawigacji. Nowy, lekki motyw i porządek w rozszerzeniach mogą dać oczekiwany wynik przy mniejszej zmianie operacyjnej. Podobnie postępuję, gdy firma planuje przebudowę oferty eksportowej lub katalogu produktów przed audytem bezpieczeństwa lub rundą dla klientów instytucjonalnych. Najpierw stabilizuje treści i ścieżki użytkownika, a dopiero później ocenia, czy nowy frontend nadal jest potrzebny.

#Astro i Next.js dobierane do konkretnych tras

Astro pasuje do stron usług, centrum wiedzy, dokumentacji produktowej, profili zespołu i większości publikacji. Generuje HTML podczas budowania i pozwala dołączać JavaScript tylko do elementów, które go potrzebują. Dla serwisu fintechu z Kreis 5, biura doradczego przy Bahnhofstrasse albo zespołu w Zurich West oznacza to szybkie strony treściowe bez stałego serwera aplikacyjnego w ścieżce każdego wejścia. Interaktywny kalkulator albo formularz zapytania ofertowego może działać jako odrębna wyspa, bez zmiany całej strony w aplikację React.

#Zachowanie adresów URL i sygnałów SEO

Równolegle porównuję tytuły, opisy, canonicale, dyrektywy robots, hreflang, dane Open Graph, dane strukturalne Schema.org i linki wewnętrzne. Migracja nie może zgubić oznaczeń organizacji, artykułów, FAQ ani breadcrumbs tylko dlatego, że poprzednio tworzyła je wtyczka. Dla witryn kierowanych na Szwajcarii, Polskę i inne rynki UE sprawdzam każdą parę hreflang oraz odwołanie zwrotne. Mapa witryny zawiera wyłącznie kanoniczne, indeksowalne adresy i odpowiada temu, co rzeczywiście zbudował frontend.

#Okno pomiarowe i przećwiczony powrót

Przed przełączeniem ustalam kryteria powrotu. Mogą nimi być niedostępność ścieżki kontaktowej, błąd logowania, utrata danych z formularza, nieoczekiwane blokowanie indeksacji albo awaria integracji krytycznej, na przykład integracji krytycznej z systemem bankowym lub CRM. Kryteria muszą być obserwowalne i powiązane z osobą decyzyjną. Samo stwierdzenie, że nowa strona działa gorzej, nie wystarcza podczas incydentu.

#Dane w UE, RODO i rezydencja

Dla firmy w Zurychu punktem odniesienia są RODO oraz praktyki szwajcarskiego FDPIC oraz RODO przy transferach UE. Gdy WPPoland prowadzi projekt z Polski, dokumentacja uwzględnia też wskazówki UODO. Dokumentuję kategorie danych, podstawę przetwarzania wskazaną przez klienta, retencję, procesorów, lokalizacje oraz mechanizmy transferu poza EOG, jeśli w ogóle występują. Nie zakładam, że platforma z regionem we Frankfurcie lub lokalnym regionie klienta utrzyma każdy log i każdą usługę pomocniczą w Unii. Sprawdzam osobno hosting frontendu, system CMS, bazę, monitoring, kopie zapasowe, pocztę transakcyjną i analitykę.

WPPoland pracuje w modelu near-shore wewnątrz UE: Polska jako baza dostarczania usług dla klientów z Szwajcarii i innych rynków UE. Wspólna strefa czasowa CET ułatwia warsztaty z zespołem w Zurychu oraz reakcję podczas wdrożenia. Jednocześnie dostęp zewnętrznego wykonawcy do środowisk klienta musi znaleźć się w dokumentacji dostępu i umów powierzenia. Stosuję najmniejsze potrzebne uprawnienia, konta imienne, uwierzytelnianie wieloskładnikowe i rejestr operacji administracyjnych.

#Trzy wzorce projektów z Zurychu

Scenariusze z Zurychu, nie opisy klientów. Kontekst: finanse, ubezpieczenia i transfery CH-UE.

#Fintech lub ubezpieczyciel

Blog i centrum pomocy ładują kod sesji. Astro na treści publiczne. Next.js na panel. Nagłówki bezpieczeństwa i rezydencja danych w dokumentacji odbioru.

#Firma B2B z ofertą DE/EN/FR/IT/PL

Kopie stron językowych zamiast modelu. Migracja porządkuje hreflang. Astro buduje katalog. Formularze poza buildem.

#SaaS z klientami w CH i UE

Mapa procesorów rozdziela hosting CH i UE. Monitoring panelu nie miesza się z CDN marketingu.

#Kiedy nie migrować

Nowy frontend nie naprawi nieaktualnych komunikatów compliance, sprzecznych wersji językowych ani braku właściciela treści po stronie compliance. Jeżeli zespół nie wie, które komunikaty zachować w archiwum i kto zatwierdza datę końca obowiązywania, najpierw potrzebny jest audyt treści. Migracja wykonana przed tym etapem przeniesie sprzeczności do szybszego systemu i utrudni późniejsze porządki w FAQ produktowych.

Nie zaczynam przełączenia tuż przed audytem bezpieczeństwa, dużą kampanią instytucjonalną albo terminem raportowania bez okna pomiarowego. Można wcześniej przygotować inwentarz, testy i nowy frontend, ale publikacja potrzebuje czasu na obserwację i reakcję zespołu. Data narzucona bez miejsca na cofnięcie zwiększa ryzyko utraty zgłoszeń i błędnej indeksacji.

Migracja jest również złym wyborem, jeśli po odbiorze nikt nie będzie utrzymywać zależności, procesu budowania i monitoringu. Astro ogranicza kod wykonywany po stronie klienta, lecz nadal wymaga aktualizacji. Next.js ma własny cykl wersji i wymagania infrastrukturalne. Przed rozpoczęciem wskazuję właściciela usługi po stronie klienta albo uzgadniam utrzymanie zewnętrzne. Grupy WordPress Zürich oraz scena fintech w Zurychu pomagają znaleźć osoby, które przejmą kod, ale nie zastępują formalnego właściciela w umowie.

#Jak WPPoland prowadzi migrację z zespołem w Zurychu

Drugi etap projektuje architekturę tras i model treści. Wspólnie z redakcją w Zurychu sprawdzam, co musi pozostać w WordPressie, które pola wymagają uporządkowania i jakie operacje muszą działać bez dostępu do API. Decyzje zapisuję po polsku i angielsku, gdy w projekcie uczestniczą partnerzy z Szwajcarii i innych krajów UE. Spotkania odbywają się w godzinach wspólnych CET, a pytania wymagające decyzji biznesowej trafiają do jednego rejestru.

Ostatni etap to przekazanie. Klient otrzymuje repozytorium, dokumentację architektury, mapę przekierowań, konfigurację środowisk opisaną bez sekretów, procedurę publikacji, odtwarzanie kopii i listę obowiązków utrzymaniowych. Sekrety trafiają do uzgodnionego menedżera, a konta pozostają własnością klienta. Osobno zapisuję hosting frontendu, lokalizację bazy WordPress, region kopii zapasowych, narzędzia analityki oraz transfery CH-UE. W raportach tygodnia po starcie porównuję ścieżki mobilne, formularze leadowe i landingi produktowe względem właściwego okresu odniesienia, z uwzględnieniem terminów raportowania compliance. Zespół w Zurychu może dalej rozwijać system samodzielnie, z wybranym partnerem albo z WPPoland, bez technicznej blokady na jednego wykonawcę.