Migracja Next.js / Astro w Stuttgarcie

Migracja z WordPressa, Drupala, Joomli albo starszej aplikacji do Astro lub Next.js ma sens dopiero wtedy, gdy rozwiązuje mierzalny problem. W Stuttgarcie i w Badenii-Wirtembergii takim problemem bywa wolny serwis dostawcy automotive lub Maschinenbau, portal B2B ładujący panel na marketingu, albo katalog wielojęzyczny z rozjechanym hreflang. 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 Stuttgarcie, 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

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 sezonem zamówień OEM. 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 dostawcy z regionu Stuttgartu, biura w Vaihingen albo eksportera z BW 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.

#Dane w UE, RODO i rezydencja

Dla firmy w Stuttgarcie punktem odniesienia są RODO oraz praktyki niemieckiego BfDI oraz organów landowych BW. 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 Stuttgarcie 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 ze Stuttgartu

Scenariusze z regionu Stuttgartu. Kontekst: automotive i inżynieria.

#Dostawca automotive

Karty produktów, PDF i RFQ. Astro na katalog. Next.js przy statusie oferty. Hreflang de/en/pl.

#Maschinenbau z dokumentacją

Docs i oferta w monolicie. Astro na docs. Panel serwisowy osobno. Adresy docs zachowane.

#SaaS dla produkcji

Astro marketing. Next.js panel. Monitoring i backupy rozdzielone.

#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. ekosystem automotive BW 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 Stuttgarcie

Drugi etap projektuje architekturę tras i model treści. Wspólnie z redakcją w Stuttgarcie 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.

W regionie Stuttgartu kalendarz OEM i dostawców dyktuje moment cutover bardziej niż preferencje frameworka. Inwentarz URL i testy RFQ kończę przed szczytem zamówień. Dokumentacja de/en/pl obejmuje mapę przekierowań i listę zależności ERP. Near-shore z Polski daje wspólną strefę CET i szybki kanał incydentowy. Właściciel utrzymania musi być wskazany w umowie, zanim oddamy repozytorium.

Przekazanie dla zespołu w Stuttgarcie obejmuje repozytorium, mapę przekierowań, opis architektury tras, procedurę publikacji i listę obowiązków utrzymaniowych bez sekretów dokumentacji. Sekrety trafiają do menedżera wskazanego przez klienta. Near-shore z Polski do Niemczech nie zmienia tego, że konta produkcyjne należą do klienta. BfDI i organy landowe BW oraz UODO pozostają w mapie przepływów obok RODO. Huby automotive Badenii-Wirtembergii mogą pomóc znaleźć osoby do dalszego utrzymania, ale formalny właściciel usługi musi być nazwany przed odbiorem. W raporcie po wdrożeniu pokazuję różnice względem stanu bazowego dla LCP, CLS, indeksacji, 404 i konwersji formularzy. Reaguję na przyczynę, nie na pojedynczy skok wykresu. Jeśli regres dotyczy tylko jednej rodziny tras, poprawiam ją zgodnie z runbookiem bez wycofywania całego serwisu.