Next.js / Astro migration in Bern

Bern is the federal city of Switzerland and the seat of its government, with about 146,000 residents, most of them German speakers. The canton around it is officially German- and French-speaking, with French in the Bernese Jura and both languages in Biel/Bienne. A company here that sells across the canton, or to the rest of the country, often runs a site in German and French at least. Every language doubles the URLs, redirects and places where SEO can break in a migration from WordPress, Joomla or Drupal to Astro or Next.js.

#Should I migrate off WordPress, or fix what I have?

Migration is worth it when the same problem returns after every repair: a theme tied to a page builder that breaks on each PHP upgrade, a Drupal 7 or Joomla 3 install nobody wants to update, a site where every new page needs the one developer who knows the deploy. If the backend is current and the pain is a heavy theme, a WordPress cleanup is cheaper, and my audit says so.

When a new frontend is justified, I pick the tool per route family, not per site. Astro suits service pages, publications, documentation and most marketing pages: it renders HTML at build time and ships JavaScript only where a component needs it. Next.js suits areas with login, user-specific data or search that depends on session state. The general approach is on my Next.js and Astro migration page.

#How do I keep my Google rankings during the move?

Rankings are lost through missing URLs, not through the new framework. I build the URL inventory from three sources and keep track of where each address came from:

1. a crawl of the current site, which finds what is linked internally,
2. Google Search Console, which lists the addresses Google already knows and the ones that bring clicks,
3. server logs, which show hits from old newsletters, PDFs, bookmarks and external links.

Every URL gets a decision in a written map: keep the path, 301 to the closest successor, or return 410 for content that is gone on purpose. I never send whole groups of old pages to the homepage. Before go-live a script walks the full map against the staging host and flags chains, loops and targets that return anything other than 200.

I also compare titles, descriptions, canonicals, robots directives and structured data between old and new pages. On WordPress, schema often comes from a plugin such as Yoast or Rank Math; when the plugin goes, the markup goes with it unless the new templates emit it. I rebuild Organization, BreadcrumbList, Article or FAQPage markup from content fields and validate it before launch.

#What changes for a German and French site in Bern?

Each language version needs its own URL, a self-referencing canonical and hreflang tags that point both ways. A German page that links to its French twin, while the French page has no link back, is ignored by Google. I generate hreflang from one shared identifier per content item, so the pairs stay consistent after editors add or remove a translation.

The content model matters more here than on a one-language site. If German and French pages are separate posts with no link between them, the migration is the moment to connect them. Slug rules per language and what happens when a translation is missing are decided before the bulk import.

#Can editors keep WordPress as the CMS?

Yes, if that is what they know. WordPress can stay as a headless backend: editors keep drafts, schedules, roles and media, and Astro or Next.js reads content through the REST API or WPGraphQL. I describe the content model first, as explicit fields per type instead of layout hidden in builder shortcodes, because content that only renders inside the old theme does not survive the move. More on that setup is on my headless CMS developer page.

The live site keeps publishing during the build; the new frontend builds in parallel from the same data.

#What does the Swiss data protection act mean for the new site?

A static frontend does not remove data obligations. Contact forms, analytics, newsletter tools and hosting logs still process personal data. For a company in Bern the reference is the revised Federal Act on Data Protection (FADP, SR 235.1), in force for companies since 1 September 2023. Points that a migration touches directly:

• the duty to inform when collecting data (Art. 19): the privacy notice must name the controller, the purpose and the recipients, so every form and tool on the new site has to be listed,
• disclosure abroad (Art. 16): data may go to a country the Federal Council has found adequate, otherwise safeguards such as contractual clauses are needed, which is relevant when hosting, analytics or form handling run outside Switzerland,
• data protection by design and by default (Art. 7): defaults should limit processing to what is needed, so new tracking does not quietly appear with the new frontend,
• breach notification (Art. 24): breaches likely to cause a high risk go to the regulator as soon as possible.

The regulator is the Federal Data Protection and Information Commissioner (FDPIC), itself based in Bern. A register of processing activities is mandatory, with exemptions for small companies whose processing carries limited risk. I am not a lawyer and do not give legal assessments. What I deliver is a list of every data flow on the new site, with its tool, location and processor, so your legal adviser can check it.

#How does the cutover work, and can it be undone?

Small sites can switch in one step. Larger ones move section by section, behind a routing rule, so a problem in one section does not take down the rest. Before the switch I agree measurable rollback criteria: a broken contact form, lost submissions, a page set accidentally marked noindex, a failing integration. The old system stays ready, and the reversal is rehearsed on staging.

After launch I check Search Console daily for the first weeks: the Pages report for new 404s and “Duplicate, Google chose different canonical”, the sitemap status per language, and performance by page type. I compare clicks and Core Web Vitals against a fair period before the switch, not against a single day.

#Do I need to host the new site in Switzerland?

The FADP does not require that as such. Disclosure abroad is allowed to countries the Federal Council lists as adequate, or with safeguards. I document where each component runs so you can decide.

#Will the French version be migrated too?

Yes. Every language version goes through the same URL map, metadata comparison and hreflang check.

#Who maintains the site afterwards?

You own the repository, environment variables, deploy pipeline and a short runbook. Your team or another developer can take over without me.

#What should I send for 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 Console access or an export is ideal). I reply with a written scope: what moves, what stays, which risks I see and how I check each one.

#FAQ

#Why are organizations in the Swiss federal city of Bern moving to Astro?

Bern serves as the political and administrative heart of Switzerland, housing federal authorities, state-affiliated enterprises (like Swisscom and Swiss Post), embassies, and international associations. Sites operating on outdated CMS monoliths struggle with security vulnerabilities, compliance auditing, and slow mobile loading speeds across bilingual German and French audiences. Astro compiles pages into pure static HTML ahead of time, ensuring maximum security against cyber threats, exceptional Core Web Vitals, and minimal ongoing cloud hosting expenditures.

#How do you safeguard Swiss German and French organic search rankings during migration?

Before touching any codebase, I crawl and catalog every indexable path, structured data snippet, and image asset across both language branches. Each legacy endpoint receives a permanent 301 redirection rule configured at the edge or preserves its exact canonical URL. Reciprocal hreflang annotations (de-CH, fr-CH, en) are verified on compiled HTML output to ensure cross-language indexing remains flawless.

#How does Astro support strict Swiss data privacy regulations?

The architecture complies fully with the revised Swiss Federal Act on Data Protection (revFADP / DSG) under Federal Data Protection and Information Commissioner (FDPIC) supervision in Bern. Web assets, fonts, and scripts are hosted locally on secure European or Swiss edge nodes, preventing inadvertent cross-border personal data transfers to unvetted cloud networks.

#What is the expected delivery timeframe for an enterprise rebuild in Bern?

A standard Swiss corporate site replatforming comprising 20 to 50 unique page templates, multilingual archives, and dynamic contact workflows typically requires 3 to 5 business weeks from architectural audit to production cutover. This schedule incorporates thorough testing on staging, accessibility verification, and post-cutover telemetry monitoring in Google Search Console.

#Payments, tax and forms in Bern

Frame: Swiss nDSG and invoicing with UID/MWST. Drivers: revFADP (nFADP), GDPR (EU-facing).