Next.js / Astro migration in Zurich

Zurich companies usually come to me with a WordPress, Joomla or Drupal site that has grown slow, hard to update safely, or expensive to keep patched, and they want a lighter Astro or Next.js frontend without losing the search traffic the old site earned. I plan and carry out that move myself: the URL map, the content model, structured data, language versions, the staged cutover and the checks in Search Console afterwards.

#Is a migration worth it, or would a clean-up of the current CMS be enough?

A migration earns its cost when the current system holds back speed, security or publishing, and when the fix cannot be a cache plugin and a cleaned-up plugin list. Typical signs: pages that take more than a second before the first byte, an admin panel slower than the public site, updates that nobody dares to install, and editors who avoid publishing because a change once broke the layout.

If the real problem is one heavy theme or three badly written plugins, I say so in the scope and quote that smaller job instead. A rebuild is the wrong answer to a hosting or caching problem.

#Astro or Next.js for a Zurich company site?

Astro fits sites that are mostly content: company pages, service descriptions, a blog, documentation, job ads. It renders HTML at build time and sends no JavaScript unless a component needs it, which keeps pages fast on any connection.

Next.js fits when the site does real work in the browser or on the server: a customer login, a configurator, search across live data, pages that change per request. Both can read content from a headless CMS. More on that split on my page about headless CMS development.

#What happens to my URLs and Google rankings?

Rankings are attached to URLs, so the URL map is the core of the project.

1. I crawl the live site and export every indexable URL, plus URLs that still receive links or traffic in Search Console and analytics.
2. Each old URL gets a target: the same path where possible, a 301 to the closest new page where the structure changes, and a deliberate 410 only for content you decide to drop.
3. Titles, meta descriptions, headings, canonical tags and structured data are carried over field by field, not rewritten by default.
4. I compare the staging build against the crawl of the old site before launch: status codes, titles, canonicals, internal links and JSON-LD.

Redirect chains get flattened so an old URL reaches its final page in one hop. PDFs and old image URLs belong in the map too, since they often carry backlinks.

#How do German and English versions work after the move?

German is the official language in Zurich, and the most widely spoken local variety is Zurich German. At federal level the Swiss Constitution names German, French and Italian as official languages, with Romansh for communication with Romansh speakers, and the federal law database itself notes that English is not an official language of the Confederation. Many Zurich companies still run an English site for international clients, so the realistic setup is often German plus English.

In the new build each language gets its own URLs, a self-referencing canonical and reciprocal hreflang tags, for example de-CH and en. I check that every language version points back to the others, because one-sided hreflang is one of the most common errors I find after migrations.

#What does Swiss data protection law change in the build?

The revised Federal Act on Data Protection (FADP) has applied since 1 September 2023. Several of its articles touch a website directly:

• Privacy by design and by default (Art. 7): the controller has to plan data processing so that the principles are respected from the planning stage. In practice I decide with you which forms, analytics and embeds the new site needs, and leave out the rest.
• Duty to inform (Art. 19): visitors must be told who processes their data, why, and to whom it goes. If data leaves Switzerland, for example to a hosting region, form service or analytics tool abroad, the notice must name the country and the safeguard used.
• Disclosure abroad (Art. 16): data may go to countries the Federal Council recognises as adequate, or elsewhere with guarantees such as contract clauses.
• Records of processing (Art. 12) and breach notification to the FDPIC (Art. 24) stay your organisation’s duties; the new site should make them easier, not add unknown processors.

The supervisory authority is the Federal Data Protection and Information Commissioner (FDPIC), which supervises how federal bodies and private companies process personal data. I am not a lawyer and do not write your privacy policy, but I deliver a list of every third-party service, its purpose and its data location, so your legal adviser has facts to work from.

#Where should the new site be hosted?

A static Astro site can run on a CDN, on a Swiss server or on both. A Next.js site with server rendering needs a runtime, either a managed platform or your own server. The choice affects speed, cost and the data flows you must declare under the FADP. I write the options into the scope with the region each provider uses, and I set up deployment so the repository, environment variables and build pipeline belong to your company account, not mine.

#What does the cutover look like?

The new site is built on a staging address that search engines cannot index. On launch day the DNS switch happens at a quiet hour, the redirect rules go live at the same moment, and I immediately test a sample of old URLs, the sitemap and robots.txt.

For larger sites I prefer a section-by-section cutover: the blog first, then service pages, then the rest. A single big switch suits only small sites.

#What do I check in the weeks after launch?

• Search Console: indexing status, crawl errors, the 404 report and whether Google picks the declared canonicals.
• Redirect hits in server logs, to catch old URLs nobody listed.
• Core Web Vitals on real visits once enough data exists.
• Rankings and clicks for the queries that brought business before the move, compared per page against the old baseline.

A full picture of the method, independent of the city, is on my Next.js and Astro migration page.

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

The usual failures are predictable: forgotten URLs with backlinks, staging accidentally left indexable, hreflang pointing to redirects, forms that silently stop sending, tracking that breaks consent, and structured data that disappears because the old theme generated it. Each one has a check in my launch list, and each check runs against the built site, not against the plan.

#How do I get a written scope?

Send me the current URL, the CMS and its version, the languages you publish in, and where your traffic comes from (search, ads, newsletters, partners). I reply with a written scope: what moves, what changes, what I recommend leaving out, the hosting options with their data regions, and the checks I will run before and after launch.

#Operating calendar in Zurich

Peaks in the Banking & Pharmaceutical fabric in Zurich set freeze windows. The date lives in the project runbook.

Zurich is an important business and technology centre. We deliver WordPress solutions focused on performance, resilience and measurable business outcomes. Swiss banking compliance (FinMA), pharmaceutical industry security standards, and multilingual content (German/French/Italian/English).

Brief compliance: revFADP (nFADP), GDPR (EU-facing). Common stack: WordPress, WooCommerce, Astro, Next.js.