Next.js / Astro migration in Düsseldorf

I move websites from WordPress, Joomla, Drupal or an older PHP framework to Astro or Next.js. For a company in Düsseldorf that means three things: every URL that brings visitors from Google today still works after launch, your editors can keep publishing, and the German consent and accessibility rules are built into the new frontend from the first commit.

#Is moving from WordPress to Astro or Next.js worth it?

Not always. If a WordPress site is slow because twenty plugins load scripts on every page, a cleanup, caching and a lighter theme often fix it for less than a new stack. A migration is worth it when at least one of these is true:

• The CMS is out of support, for example a Joomla or Drupal major version without security updates, and the upgrade would be close to a rebuild anyway.
• The site is mostly content that rarely changes, yet every request still hits PHP and a database.
• Your team wants releases with code review, tests and preview deployments instead of edits made directly in the live admin.

The trade-offs between the two frameworks are covered on my Next.js and Astro migration page. In short: Astro outputs static HTML by default and ships JavaScript only for the interactive parts, which suits company sites, blogs, documentation and landing pages. Next.js fits better when you have logins, personalised content, many server-side requests or a shop with dynamic prices.

#How do I keep my Google rankings when I migrate?

Most of the work happens before the first line of code. I build a complete URL inventory from three sources: a crawl of the live site, the XML sitemaps, and the Search Console performance report for the last twelve months. If you have a backlink export from an SEO tool, pages with external links go into the inventory too.

From that inventory I build a redirect table with three columns: old URL, new URL, reason. Every changed address gets a server-side 301 or 308 redirect, as Google recommends in its guide to site moves with URL changes. The traps I check for one by one:

• Trailing slashes: /services and /services/ are two URLs to Google. The new project gets one rule, and every internal link follows it.
• Redirect chains: an old WordPress rule plus a new rule easily becomes two hops. I resolve each chain to one direct target.
• Parameter and pagination URLs from Joomla or Drupal, such as ?start=10 or /node/123, that are still linked somewhere.

Google advises keeping redirects for at least a year and says rankings can fluctuate during a move, which on a medium-sized site can take a few weeks or more to settle. After launch I submit the new sitemap, keep the old one for a while to monitor the redirects, and follow in the page indexing report how the new URLs replace the old ones.

#What happens to content, editors and structured data?

A CMS rarely stores content as cleanly as the front end displays it. In WordPress it sits in post types, ACF fields, shortcodes and page builder markup. In Joomla it hangs off categories and menu items, in Drupal off content types and paragraphs. So I define the content model first: which fields an entry has, which are required, and how categories and tags become paths. Then the export script runs against the live database until a page-by-page sample shows no differences.

Your editors have two options. WordPress can stay as a headless backend serving content over an API, so little changes for them. Or the content moves into Markdown files or another headless CMS; the technical side is on my headless CMS developer page.

Titles, meta descriptions, canonical tags and JSON-LD move field by field, and I compare them automatically between the old and new site before launch.

#Does my Düsseldorf site need German and English versions?

Often, yes. The city’s business development office counts 4,573 international companies based in Düsseldorf and residents from 184 nations. A site serving German customers and an international head office or partners usually ends up bilingual. In that case hreflang tags move with the content, and each language version must point back to the other: Google ignores hreflang pairs that are not reciprocal.

#Which German rules apply to a new website in Düsseldorf?

A migration is the right moment to check which cookies and scripts the site really sets. Under section 25 of the German TDDDG, storing or reading information on a visitor’s device needs consent, unless it is strictly necessary to provide a service the user explicitly asked for. In the new frontend, analytics, maps and video embeds load only after consent, and fonts are served from your own domain.

Under section 40 of the Federal Data Protection Act (BDSG), private companies are supervised by the authority of their federal state. For Düsseldorf that is the Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen (LDI NRW), which is itself based in Düsseldorf.

For online shops the Accessibility Strengthening Act (BFSG) applies as well: under section 1 it covers e-commerce services provided to consumers after 28 June 2025. Before launch I test the new frontend for keyboard navigation, contrast, form labels and alt text.

#How does the cutover work without downtime?

On large sites I switch section by section. A reverse proxy or edge rules first route, say, only the blog to the new frontend, while service pages and contact forms still come from the old system. Each section goes live only after redirects, forms and tracking pass on staging. Small sites with a few dozen pages switch on one date, because running two systems in parallel costs more there than it protects.

Before the switch I lower the DNS TTL, agree a short editorial freeze with you, and make sure the staging noindex does not travel into production.

#What can go wrong, and how do I check it?

After launch I check:

• The status code of every old URL in the inventory, by script: each must answer 200 or a single redirect to a 200 page.
• The Search Console page indexing report for new “Not found (404)” and “Page with redirect” entries.
• Forms, newsletter sign-ups and conversion events in analytics, because a missing event looks like a drop in revenue.
• Core Web Vitals from field data once there are enough visits, not only Lighthouse lab scores.

#Which Düsseldorf businesses is this relevant for?

Düsseldorf is the capital of North Rhine-Westphalia and had about 619,000 residents at the end of 2025. The city’s business development office counts around 500 startups and lists sectors including ICT, healthcare, fashion and lifestyle, retail, real estate, energy, and the creative industries.

#How do I start a migration with you?

Send me your current website address, the CMS with its version number, and your main traffic sources, ideally a Search Console export, plus a list of connected services such as CRM, newsletter or payment provider. From that I write a scope with the URL inventory, an Astro or Next.js recommendation, and what I still need from you before starting.

#Stack fit in Düsseldorf

Meetup: WordPress Düsseldorf Meetup (https://www.meetup.com/dusseldorf-wordpress-meetup/).

#FAQ

#Why are Düsseldorf corporate and agency websites transitioning to Astro?

Düsseldorf is the state capital of North Rhine-Westphalia and a major international business center for telecommunications, legal services, management consulting, fashion, and retail. Legacy CMS setups laden with third-party plugins present continuous security maintenance challenges and slow mobile response times. Migrating to Astro pre-renders content into lightweight static HTML, dramatically lowering TTFB, achieving optimal Core Web Vitals, and eliminating database vulnerabilities on public endpoints.

#How do you safeguard international search engine positions during the migration?

Before deploying code changes, I compile a complete URL manifest from live crawls, sitemaps, and Search Console history. Every legacy route is preserved or mapped to a permanent 301 redirect implemented directly at the edge layer. German and English reciprocal hreflang tags (such as de-DE and en) are verified on rendered static output to guarantee search bots index the intended regional variants.

#What German data protection laws apply to a rebuilt site in Düsseldorf?

Websites operating in Düsseldorf fall under the supervisory jurisdiction of the LDI NRW. The rebuild enforces Section 25 of the TDDDG, requiring explicit consent before executing non-essential cookies or tracking pixels. Fonts, scripts, and media files are hosted on European edge servers to avoid unconsented data transfers to third countries.

#Can our marketing department continue creating blog articles via WordPress?

Yes. We can decouple your system, turning WordPress into a headless CMS. Your marketing team works inside the familiar WordPress editorial interface, while Astro fetches published data via REST or GraphQL APIs to generate production-ready static pages automatically via deployment webhooks.

#What is the expected delivery timeframe for a website migration in Düsseldorf?

A typical corporate migration covering 20 to 50 unique page templates, multilingual translations, and custom forms spans approximately 3 to 5 working weeks from initial crawl analysis to production cutover.