Next.js / Astro migration in Stuttgart

Stuttgart is the capital of Baden-Württemberg. The city’s own economic development pages list mobility, aerospace, engineering, finance, information technology, media and the creative industries as its top sectors. That mix produces websites that are German first, often English second, heavy on technical content and built up over years in WordPress, TYPO3, Drupal or Joomla. When that site gets slow, fragile or hard to extend, a move to Astro or Next.js can make sense. This page explains how I run that migration, what I check, and where it tends to go wrong.

#Should a Stuttgart company migrate or just fix the current CMS?

Migration is not the default answer. If the problem is ten page-builder plugins and no caching, a cleanup on the current platform is cheaper and faster. I recommend a move to Astro or Next.js when at least one of these holds:

• The frontend cannot pass Core Web Vitals on mobile even after caching, because the theme itself ships too much JavaScript and CSS.
• The CMS admin is exposed to the internet and patched irregularly, and the site does not need a public login at all.
• The same product or technical content has to feed the website, a dealer or partner portal and maybe an app, so an API-first content source pays off.
• Nobody in-house wants to touch the legacy theme any more, and every small change goes through one external person.

If none of these apply, I say so in the written scope.

#Astro or Next.js for a company site in Stuttgart?

I decide per route group, not per company. Marketing pages, product descriptions, technical articles, career pages and press releases are content: Astro renders them to static HTML with no JavaScript unless a component explicitly needs it. A configurator, a logged-in partner area or a page that shows live stock or prices needs server rendering and session handling, which is where Next.js fits.

Some sites end up with Astro for the public pages and a separate Next.js application for the interactive part. The CMS can stay: WordPress through its REST API or WPGraphQL is a valid headless backend, so editors keep the interface they know. More on that approach in my Next.js and Astro migration guide and on the Astro development page.

#How do I keep Google rankings during the move?

Rankings survive a migration when every URL that has traffic or links still answers, either at the same address or through a single 301. The work, in order:

1. URL inventory. I combine a full crawl, the Search Console performance export and, if available, server access logs. Logs catch old PDF links and campaign URLs that no crawler finds.
2. Redirect map. Every old URL gets a target in a spreadsheet you can review. No chains, no blanket redirects to the homepage, and 404 only for pages that are deliberately gone.
3. Content model. Post types, custom fields, taxonomies and media are mapped to the new content schema. Shortcodes and page-builder markup are converted, not copied as raw HTML.
4. Metadata and structured data. Titles, meta descriptions, canonicals, Open Graph tags and JSON-LD (Organization, Product, Article, BreadcrumbList, FAQPage where it is real) are rebuilt and validated against the built pages, not the templates.
5. Hreflang. For German and English versions, each page needs reciprocal hreflang links and a self-referencing canonical. I check reciprocity across the whole site with a script, because one missing return link breaks the pair.
6. Staging check. The new site runs on a protected staging domain. I replay the redirect map against it and compare status codes, titles and canonicals URL by URL before anything goes live.

#What does the cutover look like?

I prefer a short content freeze and a DNS or proxy switch over a big-bang relaunch weekend. The old site stays available on a separate origin for rollback. On launch day I submit the new sitemap in Search Console, run the redirect map against production, and check that robots.txt does not still block crawling, which is the most common self-inflicted outage after a migration.

In the following weeks I watch the Search Console indexing and performance reports for the migrated URLs: crawl errors, pages dropped from the index, queries that lost position. A drop in the first days is normal while Google recrawls. A drop that grows after two weeks usually points to a missing redirect, a wrong canonical or content that did not migrate, and the URL-level comparison from staging tells me which.

#What German rules does the new site have to respect?

A new frontend does not change the legal requirements, but it is the right moment to implement them cleanly instead of through plugins:

• Consent. Section 25 of the TDDDG allows storing or reading information on a visitor’s device only with consent, unless it is strictly necessary for the service the user asked for. On a static Astro site it is easy to verify that no analytics or marketing script loads before consent.
• Imprint. Section 5 of the DDG requires business websites to keep provider information easy to find, directly reachable and permanently available. The imprint page and its link move with the migration like any other URL.
• Accessibility. The Barrierefreiheitsstärkungsgesetz (BFSG) applies to e-commerce services provided to consumers after 28 June 2025. If your site sells to consumers, the migration is a good point to fix headings, contrast, form labels and keyboard navigation in the new components rather than patching them later.
• Data protection. The Landesbeauftragte für Datenschutz und Informationsfreiheit Baden-Württemberg advises companies in the state that process personal data. Moving to static hosting, self-hosted fonts and fewer third-party scripts reduces what has to be listed in the privacy notice.

I am not a lawyer and I do not give legal advice. I implement what your privacy and legal advisers specify and make it checkable in the code.

#Hosting and data residency

Astro output is static files, so it can run on almost any host, including providers with data centres in Germany or the EU. Next.js with server rendering needs a Node runtime or a platform that supports it. If your data protection officer requires EU-only processing, I factor that into the hosting choice before writing code, not after.

#What you get at handover

The repository, the redirect map, the content model documentation, a deploy pipeline you control and a short runbook for publishing and rolling back. No credentials sit in documents, and another developer can take over without asking me.

#Where to meet people who work with WordPress in Stuttgart

The WordPress Meetup Stuttgart is a casual, German-language meetup for users, designers, developers and bloggers working with WordPress, with talks, lightning talks and networking. If you want a reference check on anyone you are about to hire, including me, a room of people who have already done this locally is a good place to ask.

#Next step

Send me the current URL, the CMS and version, the main traffic sources (organic, ads, direct, partner links) and which parts of the site need logins or live data. I reply with a written scope: what to migrate, what to keep, Astro or Next.js per section, and the risks I see. No call needed.