Next.js / Astro Migration in Brussels

Migration from WordPress, Drupal, Joomla or a legacy application to Astro or Next.js only pays off when it solves a measurable problem. In Brussels that problem might be a slow lead site for a consultancy near the European Quarter, a hard-to-maintain bilingual corporate site whose French and Dutch variants drift apart, or a Benelux SaaS product where a public CMS widens the attack surface without helping editors. Age of the site alone is not enough. WPPoland starts with an audit, not with a framework preference.

We move content, URLs, metadata, structured data and the publishing process as one system. The frontend can change while editors keep WordPress. Cutover arrives with a practised rollback, and acceptance rests on before-and-after measurements. That approach fits Brussels teams that need EU and Belgian data context, multilingual publishing discipline and maintenance that does not lock them to a single agency.

#Migration versus relaunch in the current system

A relaunch changes presentation, information architecture and visual layer without necessarily leaving the current CMS. A migration changes the technical foundation while keeping or deliberately reshaping what already works. The distinction drives risk, timeline and acceptance criteria.

Migration is justified when the same limits return after every local fix. One pattern is a WordPress theme tied to an unsupported page builder, so a PHP upgrade blocks critical templates. Another is Drupal or a custom CMS where a small change needs the one person who still knows the deploy path. On lead-generation sites the symptom can be unstable LCP, scripts loaded on every page and forms wired to a CRM without contract tests. Another optimisation plugin does not remove the cause.

A WordPress relaunch is better when the backend is current, the team knows the publish process and the pain is a heavy theme, messy blocks or inconsistent navigation. A lighter theme and cleaner extensions can deliver the outcome with less operational change. The same order applies when a firm is rewriting its offer for Belgian and EU buyers. Stabilise content and user paths first, then decide whether a new frontend is still required.

The audit ends with a recommendation and a reason. If repairing the existing WordPress stack is enough, we do not add headless only to use Astro or Next.js. Technology should reduce change cost and operational risk, not create a new maintenance project for the Brussels team.

#Astro and Next.js chosen by route

One domain does not need one rendering model. We split the site into route families and record requirements for each: whether content is shared for everyone, how often it changes, whether the user signs in, where data comes from, what response time is acceptable and what should happen when an API fails.

Astro fits service pages, knowledge hubs, documentation, expert profiles and most publications. It builds HTML at compile time and attaches JavaScript only where interaction is required. For a law firm, policy consultancy or association site in Brussels that means fast content pages without an application server on every request. An interactive calculator or form can run as an island without turning the whole site into a React application.

Next.js fits a client portal, a permission-aware dashboard, advanced job or tender search, or a product view that depends on session state. Server or on-demand rendering then has a concrete job. We still limit code sent to the browser and keep the public marketing layer separate from authenticated operations.

On larger sites both can coexist. Astro serves the main site and publications; Next.js serves a portal on a path or subdomain. Routing keeps shared URLs, security headers and observability. The decision stays in the repository as a short architecture note so the next team knows why a route uses Next.js instead of assuming it happened by accident.

#Preserving URLs and SEO signals

The largest post-migration losses usually start from an incomplete inventory. A crawl shows pages reachable through internal links but not the full history. Google Search Console surfaces addresses the search engine already knows. Server logs show old hits from PDFs, newsletters, bookmarks and external sites. We merge those three sources and only deduplicate after retaining provenance.

Every existing URL gets a status in the migration map. The safest option keeps the same path. When content is merged, the old address receives a single 301 to the closest successor. Removed material without a successor returns a deliberately chosen response code. We do not send whole groups of legacy pages to the homepage, because that shortcut frustrates visitors and blurs signals for search engines.

In parallel we compare titles, descriptions, canonicals, robots directives, hreflang, Open Graph data, schema markup and internal links. Migration must not drop organisation, article, FAQ or breadcrumb markup simply because a plugin used to emit it. For sites aimed at Belgium and neighbouring markets we verify each hreflang pair and its return link across French, Dutch and English where those variants exist. The sitemap lists only canonical, indexable URLs and matches what the frontend actually builds.

Before go-live an automated pass fetches representative pages from the old and new environments. It compares response codes, head elements, headers, critical content and links. A separate test walks the full redirect map and flags loops or chains. Failures land in a report before DNS changes, not in Search Console weeks later.

#WordPress stays the editorial tool

Headless does not require replacing the admin. WordPress can keep storing content, editorial users, drafts, publish schedules and fields defined per content type. Astro or Next.js fetches data through REST API or WPGraphQL and owns presentation. We change the visitor-facing theme without taking a proven workflow away from editors.

First we describe the content model. Title, lead, organisational author, sections, relations, files and SEO metadata need explicit fields instead of hidden dependencies on an old builder. Blocks need a contract for required data, variants and behaviour when an image or link is missing. That reduces cases where an entry looks fine in the admin but cannot render outside the legacy theme.

During the work the live site keeps publishing. The new frontend builds in parallel on the same data, and a webhook refreshes a preview after content changes. Before cutover we sync and agree a short limited-publish window only when the data source requires it. The runbook states the time, ownership and how to confirm the last edits are visible in the new system.

For Brussels teams that publish in French, Dutch and English, the model must treat language as a first-class field, not as duplicated page copies that diverge after every campaign. Shared identifiers for entities, consistent slug rules per locale and clear ownership for each language version belong in the editorial contract before bulk import.

The admin backend can be network-restricted, wrapped in extra authentication and separated from the public host. That is not automatic protection. WordPress updates, role control, backups and API monitoring remain necessary. The gain is fewer public entry points and no database connection on the static page delivered to visitors.

#Measurement window and practised rollback

Deployment starts from a baseline. We collect Core Web Vitals from real-user data, response times, application errors, form success, primary conversions, organic traffic and indexing depth. Results are tagged by page type and device. A single domain average can hide a slow mobile form or problems that exist only in a publication archive.

Before cutover we define rollback criteria. Examples include an unavailable contact path, a login failure, lost form submissions, unexpected index blocking or a broken critical integration. Criteria must be observable and tied to a named decision owner. Saying the new site feels worse is not enough during an incident.

The previous system stays ready for the agreed measurement window. DNS or routing reversal has a documented procedure rehearsed on a pre-production environment. If the new system writes data, the plan states how to protect records created after cutover. Without that, a technical rollback could restore availability while losing client submissions.

After launch we watch 404s, redirects, function logs, performance, indexing and conversions. Comparison uses a fair reference period, accounting for weekday, campaigns and seasonality around EU calendar peaks or local Belgian events. We archive the old system only after acceptance criteria are met. The archive covers code, database, files, infrastructure config and restore instructions, not a content export alone.

#EU data, GDPR and multilingual publishing in Brussels

A static frontend does not remove data obligations. Contact forms, analytics, CRM tools, recruitment flows, session recordings and infrastructure logs can still process identifiers or user-submitted content. Migration is a practical moment to map real flows, because hosting and integrations must be reconnected anyway.

For a Brussels organisation the reference points are the GDPR and Belgian supervisory practice, alongside sector rules that apply to contractors working near EU institutions. We document data categories, the legal basis the client states, retention, processors, locations and any transfer mechanisms outside the EEA. We do not assume that choosing an EU region for one platform keeps every log and auxiliary service inside the Union. Frontend hosting, CMS, database, monitoring, backups, transactional email and analytics are checked separately.

Multilingual publishing is part of the data and SEO surface, not a late localisation task. French, Dutch and English variants need reciprocal hreflang, consistent canonicals and editorial ownership so a campaign update in one language does not leave stale claims in another. Cookie and consent copy must match the languages actually served. Accessibility checks use WCAG as a technical test standard: keyboard use, focus order, accessible names, contrast, zoom, error messages and form behaviour with a screen reader. Results and exceptions go into the acceptance report so the client can connect technical evidence to its legal assessment.

WPPoland works nearshore inside the EU, with Poland as the delivery base for clients across member states. Overlapping business hours support workshops with Brussels teams and incident response during cutover. External access to client environments must appear in access documentation and processing agreements. We use least privilege, named accounts, multi-factor authentication and an admin operation log.

#Three project patterns around Brussels

The patterns below are design scenarios built from recurring problems observed in the Brussels and Belgian ecosystem. They are not descriptions of specific WPPoland clients.

#EU-adjacent contractor with policy content and proposals

A consultancy or specialised contractor near the European Quarter runs a WordPress site for services, a separate archive of briefings and manually assembled expert profiles. The same author, policy theme and sector appear under different labels in three places. Migration starts with a shared content model and stable identifiers, not with visual redesign. WordPress stays the backend; Astro builds services, publications and profiles from one dataset. Existing briefing URLs are preserved because they are cited in partner documents and institutional mailings. Search over the knowledge base uses a prepared index so the whole site does not need to run as an application.

Acceptance covers publication counts, author relations, metadata and downloadable files. Contact forms tied to practice areas and consent recording are tested separately. A new frontend will not fix taxonomy drift on its own, so editorial decisions land before bulk import.

#Bilingual corporate site with FR-NL-EN drift

A Belgian corporate or association site publishes French and Dutch as primary languages, with English for international stakeholders. Over years, locale copies diverged: campaigns updated one language, navigation labels drifted and hreflang pairs broke. The old theme loads heavy scripts on every page. Route split creates a clear boundary. Astro serves the public corporate and news surfaces; Next.js appears only where a member area or personalised dashboard justifies session state.

The URL map separates durable corporate pages from short-lived campaign landings. Expired campaigns are not redirected en masse to the homepage. Depending on value and available successors they show an expired state, point to the right category or return an agreed status code. Tests cover reciprocal hreflang, language switchers, consent banners in each served language and downloadable reports. Form submissions never enter the static build.

#Benelux SaaS with public knowledge and a protected account area

A product team selling across Belgium, the Netherlands and Luxembourg combines marketing pages, a help centre and a customer account area. The legacy frontend bundles everything, so a simple article downloads authentication code and panel components. Astro serves the public offer and help content; Next.js stays with the account area where session, permissions and on-demand data are justified.

Routing keeps one domain and consistent security headers. Contract tests cover the account API; a comparative crawl guards public URLs. Migration proceeds in stages: content first, then login and account views. Rollback can target one route group instead of withdrawing the whole service. Monitoring and backups for the account area stay separate from the public marketing CDN.

#When not to migrate

We do not recommend migration when the task is only to fix a few slow templates and WordPress already has current extensions, a clean theme and a technical owner. Query profiling, removing surplus scripts, caching and image work can solve the problem without introducing a second stack.

A new frontend will not fix outdated offers, duplicated copy or missing editorial ownership. If the team cannot say which content to keep and who approves changes, a content audit comes first. Migration before that stage moves contradictions into a faster system and makes later cleanup harder.

We do not cut over immediately before a major campaign, institutional deadline or Benelux product launch. Inventory, tests and the new frontend can be prepared earlier, but publish needs room for the measurement window and team response. A date with no space to reverse raises the risk of lost enquiries and broken indexing.

Migration is also a poor choice if nobody will maintain dependencies, the build process and monitoring after acceptance. Astro limits client-side code yet still needs updates. Next.js has its own release cycle and infrastructure requirements. Before starting we name a service owner on the client side or agree external maintenance.

#How WPPoland runs migration with a Brussels team

Work is split into stages with separate outputs and acceptance criteria. The first stage audits the system, data, integrations and traffic. Deliverables include a URL inventory, dependency map, baseline measurement, risk register and a recommendation: repair, relaunch in the current system or migrate. Scope and pricing are individual, because two sites with a similar page count can have very different URL histories and integrations.

The second stage designs route architecture and the content model. Together with the Brussels editorial team we decide what must stay in WordPress, which fields need cleanup and which operations must work without API access. Decisions are recorded in English by default, with French or Dutch notes when that matches the working language of the stakeholders. Meetings sit in hours that overlap Belgium and Poland, and questions that need a business decision go into one register.

The third stage is parallel build. Imports are repeatable, not one-off. Tests cover critical components, API contracts, redirects, metadata and primary user paths, including language switching. The client team gets a preview environment for content changes. Local Belgian and EU specialist networks can supply people for later maintenance, but project decisions rest on the audit of the concrete system.

Before publish we run a cutover rehearsal. The runbook lists change order, owners, incident channel, smoke tests and rollback. After launch the measurement window starts with regular difference reports against the baseline. We react to causes, not to a single chart spike.

The final stage is handover. The client receives the repository, architecture documentation, redirect map, environment configuration described without secrets, publish procedure, restore steps and a maintenance responsibility list. Secrets go into an agreed manager; accounts remain client-owned. The Brussels team can keep evolving the system alone, with a chosen partner or with WPPoland, without a technical lock-in to one vendor.