Next.js / Astro migration in Cologne

Cologne is the largest city in North Rhine-Westphalia and the fourth most populous in Germany, with 1,025,523 residents at the end of 2025. Its economic development agency, KölnBusiness, groups the local economy into six sectors: research and science, health and life sciences, information and communication technology, culture and creative industries, logistics and wholesale, and insurance. Many of these companies run websites that grew for a decade on WordPress, Joomla or Drupal. When that stack becomes slow, fragile to update or risky to patch, a move to Astro or Next.js can fix it. This page explains how I run that move and what I check so your search traffic survives it.

#When should a Cologne company move to Astro or Next.js?

When the CMS itself is the problem, not one plugin or the hosting plan. Typical signs: every page view hits PHP and the database for text that changes once a month, the admin is slower than the public site, plugin updates break the theme, and nobody owns the security patch schedule. If removing a page builder and adding a page cache would fix it, I tell you that, and you keep the CMS.

Astro fits content sites: service pages, blogs, documentation, product catalogues, multilingual corporate sites. It ships static HTML by default and adds JavaScript only to components that need it. Next.js fits sites with logins, customer portals, personalised content or server rendering on every request. An insurance broker with a policy calculator and a client area is a Next.js case; a media production company with a showreel and a blog is an Astro case. Both can read content from a headless CMS, from Markdown in a Git repository, or from your existing WordPress through its REST API while the move is in progress.

#What does the migration involve, step by step?

1. URL inventory. I crawl the current site and export every indexable URL, then add the URLs that get traffic or links according to your Search Console and analytics. Redirects left over from earlier redesigns go on the list too, because they often still carry backlinks.
2. URL map. Each old URL gets exactly one target: the same path, a new path with a 301, or a deliberate 410 when the content is gone for good. You get the map as a spreadsheet, and the new host serves it as a redirect file. No chains, and no sending everything to the homepage.
3. Content model. Post types, custom fields, taxonomies and menus become typed collections. This is where hidden problems appear: page builder shortcodes, images embedded in HTML, translations linked through a plugin table instead of a shared ID, German umlauts mangled in old slugs.
4. Structured data. Organisation, breadcrumb, article, product or FAQ markup is generated from the same fields as the visible text, so the two cannot drift apart.
5. Languages and hreflang. If you publish in German and English, each page carries hreflang links to all its translations and to itself. I use de and en for a general audience, or de-DE when you target Germany only. The tags come from the content model and I test that every pair is reciprocal.
6. Staging and parity checks. Before launch I compare each old page with its new version: title, meta description, canonical, H1, structured data and internal links. Every difference is either fixed or written down as intended.
7. Staged cutover. On larger sites the new frontend takes over one section at a time while edge rules send the rest to the old system. Small sites switch in one step.
8. Search Console after launch. I submit the new sitemap, watch the page indexing report and inspect a sample of redirected URLs. If the domain or subdomain changes, I file a Change of Address request, which Google says is needed only in that case.

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

• Lost URLs. A page that existed and now returns 404 loses its links and rankings. After launch I re-crawl the full old URL list against the new site and fix every 404 and every redirect chain.
• Rankings that dip and stay down. Google says that for a medium-sized site it can take a few weeks or more before the new URLs replace the old ones in results. A dip in that window is expected; a dip on pages whose redirect or canonical is wrong is not. I check those pages first.
• Redirects removed too early. Google’s guidance is to keep them for as long as possible, generally at least one year. I leave them in place unless you decide otherwise.
• Language versions cut loose. If the English page redirects but the German one does not, hreflang breaks and Google may show the wrong language. I check reciprocity on the built HTML, not in the CMS settings.
• Forms and tracking that silently stop. Contact forms, newsletter sign-ups, cookie banners and analytics usually live in plugins. I list each one before the move and test it on staging with real submissions.
• Editors who cannot publish. A fast site nobody can update is a failed project. The editing workflow is agreed at the start, and editors get a walkthrough before cutover.

#Which data protection rules matter for a site in Cologne?

Form submissions, analytics data and newsletter lists are personal data under the GDPR. For companies in North Rhine-Westphalia the supervisory authority is the LDI NRW (Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen), whose remit covers the private sector as well as public administration. A migration is a good moment to list which scripts load on each page, which set cookies and where form data goes, because the new stack carries only what you deliberately add back. A legacy WordPress install often has three tracking scripts nobody remembers adding; the rebuild is where they disappear.

Hosting is a choice, not a default. Astro output can be served from a static host or a CDN; Next.js with server rendering needs a runtime. If your data handling requires hosting inside the EU, I pick a provider and region that meet it and record the choice in the handover document.

#What do I get at the end of the project?

You get the repository, the URL map, the redirect file, environment variables, the deploy pipeline and a short document describing how content is edited and published. Search Console and analytics stay in your own accounts. If you want, I watch indexing and Core Web Vitals for the weeks after launch and fix what comes up.

The general process is described on my Next.js and Astro migration page, and the Astro side in more depth on the Astro developer page.

#How do I start?

Send me the current site URL, the CMS and version it runs on, the languages it publishes in, and where your traffic comes from: organic search, ads, newsletters or referrals. Search Console access helps but is not needed for the first look. I reply with a written scope: what moves, what changes, which URLs need redirects and which risks I see on your site.

#Regulatory frame for projects in Cologne

On a migration engagement we record hosting location, who administers WordPress, and what sits out of scope. Scalable architecture for growing products, strong security baselines, and multilingual user journeys optimized for regional and international audiences.

#FAQ

#Why are Cologne media and commercial enterprises migrating to Astro or Next.js?

Cologne is a premier German media capital, publishing hub (WDR, RTL), and corporate center for trade fairs, insurance, and chemical industries. Traditional CMS monoliths laden with legacy plugins create high server latencies, security risks, and frustrating editing bottlenecks. Migrating to Astro replaces database bottlenecks with pre-rendered, static HTML and isolated components, ensuring instantaneous page delivery, top Core Web Vitals, and total protection against web vulnerabilities.

#How do you preserve German and English search rankings during the transition?

Before writing any code, I crawl and catalog every live URL, metadata tag, canonical link, and image asset across both languages. Each legacy path is mapped 1:1 to its target route or redirected via permanent HTTP 301 headers configured at the edge. Reciprocal hreflang tags (such as de-DE and en) are generated and programmatically tested directly on the built HTML to prevent translation drops.

#How does the editorial team in Cologne handle content updates post-launch?

Yes. Your marketing and communication team can retain their familiar authoring environment by converting WordPress, Strapi, or Sanity into a headless CMS. Authors write and preview content in the established backend, while Astro ingests published data via REST or GraphQL APIs to build static, zero-JS pages automatically upon saving.

#What German and European regulations are incorporated into the migration?

Every migration strictly complies with the EU GDPR under Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen (LDI NRW) supervision, Section 25 of the TDDDG, Section 5 of the Digitale-Dienste-Gesetz (DDG), and European Accessibility Act mandates (BFSG / EN 301 549). Web fonts, analytics tokens, and stylesheets are self-hosted directly on European server nodes to prevent third-party IP address leakage to US cloud networks.

#What is the expected delivery timeframe for a Cologne website migration?

A typical corporate replatforming covering 15 to 45 unique page templates, multilingual translations (German, English), and custom forms spans approximately 3 to 5 working weeks from initial crawl analysis to production cutover.