Next.js / Astro Migration in Munich

We move existing sites off WordPress or an older CMS onto a headless setup with a Next.js or Astro frontend. The content backend can stay (WordPress as a headless source over REST or GraphQL) or move to something else, depending on who edits content day to day. We don't rebuild projects that would be cheaper to fix where they are.

Incremental by default. The new frontend takes over one section at a time while the rest keeps running on the old system, with a reverse proxy or edge rules splitting the traffic until we've finished. A big-bang cutover only makes sense on small sites, where running two stacks in parallel costs more than a single clean switch.

We map every old URL before we start and match it one to one on the new site, with 301s wherever an address changes. Titles, meta, structured data and canonicals move across, and after launch we watch Search Console to catch indexing drops early. Any URL change is a decision we write down on purpose, not a side effect.

It's a trade-off, not a religion. I reach for Astro on content-heavy sites (blogs, marketing, docs) because it ships zero JS by default; Next.js when there's real interactivity, an authenticated area, or server rendering for dynamic data. I put the recommendation in writing so you can revisit the reasoning a year later.

We guard Core Web Vitals with a performance budget in CI, so a regression in LCP or CLS fails the build before it reaches production. The code ships with docs, conventions and a deploy pipeline your team can take over without us. Handover covers the repository, environment variables and a short guide for shipping changes.