Migracja Next.js / Astro w Hamburgu

Migracja z WordPressa, Drupala, Joomli albo starszej aplikacji do Astro lub Next.js ma sens dopiero wtedy, gdy rozwiązuje mierzalny problem. W Hamburgu i w północnych Niemczech takim problemem bywa wolny serwis operatora logistycznego z HafenCity pod naporem sezonu portowego, portal B2B przy Elbie, który ładuje cały kod panelu na stronach marketingowych, albo wielojęzyczna witryna handlowa, w której hreflang i integracje ERP rozjechały się po kilku relaunchach. Sam wiek strony nie wystarcza. WPPoland zaczyna od audytu, a nie od wyboru frameworka.

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 Hamburgu, które potrzebują polskiego i unijnego kontekstu prawnego, near-shore z Polski do Niemczech oraz utrzymania, które nie zależy od jednej agencji.

#Migracja czy relaunch w obecnym systemie

Migrację uzasadnia system, którego ograniczenia wracają po każdej lokalnej naprawie. Przykładem jest motyw WordPress powiązany z niewspieranym builderem, przez co aktualizacja PHP blokuje kluczowe szablony. Innym sygnałem jest Drupal albo autorski CMS, w którym wdrożenie drobnej zmiany wymaga dostępu do wiedzy jednej osoby w zespole rozproszonym między Hamburgu a innymi hubami UE. W projektach lead generation problem może ujawniać się jako niestabilny LCP na 4G w metrze, skrypty ładowane na każdej podstronie i formularze połączone z HubSpotem lub Salesforce bez testów kontraktowych. Kolejny plugin optymalizacyjny nie usuwa wtedy przyczyny.

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 szczytem sezonu portowego lub targami logistycznymi. 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 firmy logistycznej z HafenCity, biura inżynieryjnego w Altonie albo eksportera z północnych Niemiec 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 Niemczech, 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 z ERP lub bramką płatności. 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 Hamburgu punktem odniesienia są RODO oraz praktyki niemieckiego BfDI oraz organów landowych. 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 Niemczech i innych rynków UE. Wspólna strefa czasowa CET ułatwia warsztaty z zespołem w Hamburgu 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 Hamburga

Poniższe wzorce są scenariuszami projektowymi z ekosystemu Hamburga i północnych Niemiec, a nie opisami konkretnych klientów WPPoland. Punkt odniesienia: port, HafenCity i firmy eksportowe.

#Operator logistyki wokół portu i HafenCity

Firma z regionu portowego ma katalog usług, karty PDF, strony rynków i zapytania spięte z ERP. Stary frontend ładuje ciężkie skrypty na każdej karcie. Astro obsługuje katalog i treści rynkowe. Next.js pojawia się tylko przy statusie przesyłki lub obszarze klienta. Mapa URL rozdziela trwałe strony usług od sezonowych landingów. Testy obejmują hreflang dla rynków UE i formularze RFQ. Dane zapytań nie trafiają do strony zbudowanej do HTML.

#SaaS przemysłowy z rozdzieloną warstwą marketingu

Produkt B2B łączy dokumentację, blog i panel w monolicie. Publiczne artykuły ładują kod uwierzytelnienia. Astro przejmuje ofertę i dokumentację z WordPressa. Next.js zostaje przy panelu. Odbiór liczy publikacje, metadane i zachowanie adresów docs linkowanych z e-maili serwisowych.

#Eksporter z północnych Niemiec z ofertą wielojęzyczną

Wersje de/en/pl powstały jako kopie stron. Migracja zaczyna się od wspólnego modelu treści. Astro buduje katalog. Formularze i zgody pozostają poza buildem. Powrót może dotyczyć jednej rodziny tras, bez wycofywania całego serwisu.

#Kiedy nie migrować

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. HafenCity, logistyka portowa i firmy eksportowe z północnych Niemiec 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 Hamburgu

Drugi etap projektuje architekturę tras i model treści. Wspólnie z redakcją w Hamburgu 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 Niemczech i innych krajów UE. Spotkania odbywają się w godzinach wspólnych CET, a pytania wymagające decyzji biznesowej trafiają do jednego rejestru.