Next.js / Astro Migration in Amsterdam

Teams across Amsterdam and the wider Randstad usually arrive at a migration conversation after something concrete stops working: a lead site that fails Core Web Vitals on mobile, a marketing stack that cannot ship bilingual Dutch and English without copy drift, or a checkout path where iDEAL and consent tooling sit on a theme nobody wants to touch. Age of the CMS alone is not the signal. WPPoland starts with an audit of URLs, editorial process and integrations, not with a preference for Astro or Next.js.

We move content, addresses, metadata, structured data and the publish workflow as one system. The public frontend can change while editors keep WordPress. Cutover ships with a practised rollback, and acceptance rests on before-and-after measurements. That fit matters for Dutch teams that need EU data discipline, NL-EN publishing rules and maintenance that is not locked to a single agency.

#Migrate or relaunch where you already are

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

Migration is justified when the same limits return after every local fix. One pattern in Amsterdam is a WordPress theme welded to an unsupported page builder, so a PHP upgrade breaks the templates that carry product and pricing narratives. Another is a Drupal or custom CMS where a small change needs the one contractor who still knows the deploy path. On lead-generation sites the symptom can be unstable LCP, third-party scripts on every route 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 scale-up is rewriting its offer for Dutch and international 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 Amsterdam team.

#Astro versus Next.js by route family

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 logistics content hub, fintech explainer library or agency marketing site in Amsterdam 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 product search, or a 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.

#URL inventory and SEO continuity

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 the Netherlands and neighbouring markets we verify each hreflang pair and its return link across 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 as the editorial system

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 Amsterdam teams that publish in 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. Dutch spelling, formal address conventions and English product copy need the same field structure even when tone differs.

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 such as iDEAL return handling. 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 Dutch holidays and retail peaks. 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.

#GDPR, Dutch bilingual publishing and payment paths

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 an Amsterdam organisation the reference points are the GDPR and Dutch supervisory practice through the Autoriteit Persoonsgegevens, alongside sector rules that apply to fintech, logistics or employment-related processing. 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.

Dutch and English publishing is part of the data and SEO surface, not a late localisation task. NL and EN 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. Where checkout or donation flows use iDEAL, the return, cancel and error paths belong in the smoke tests for cutover, because a static marketing build must not swallow payment callbacks. 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 Amsterdam and Randstad 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.

#Patterns we see around Amsterdam and the Randstad

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

#Scale-up marketing site with NL-EN product narrative

A product team based in Amsterdam or elsewhere in the Randstad runs WordPress for the public offer, blog and careers pages. Growth experiments added landing templates that never joined a shared content model. Dutch and English product claims drifted after successive campaigns. Migration starts with stable identifiers for product entities, features and pricing narratives, not with a visual redesign. WordPress stays the backend; Astro builds marketing and publication routes from one dataset. Existing blog and docs URLs are preserved because they already rank and appear in partner mailings. Interactive demos or account signup sit on a Next.js boundary only where session state is required.

Acceptance covers publication counts, locale parity checks, metadata and downloadable assets. Forms tied to product 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.

#Agency white-label delivery for Dutch clients

A digital agency in Amsterdam delivers sites under its own brand while the technical stack must stay maintainable after handover. The legacy pattern is a heavy theme per client with custom plugins that only one developer understands. Route discipline creates a clearer boundary: Astro for content-heavy client sites, Next.js only where a logged-in client area or configurator justifies it. The URL map separates durable service pages from short-lived campaign landings. Expired campaigns are not redirected en masse to the homepage.

Tests cover redirect completeness, hreflang where NL and EN both ship, consent banners in each served language and form submissions that never enter the static build. Handover includes the repository, redirect map and a short runbook so the agency or the end client can keep ownership without a lock-in to the migration vendor.

#Logistics or fintech content hub with regulated copy

A logistics operator or fintech publisher maintains a dense content hub: guides, status pages, glossary entries and downloadable reports. The old theme loads marketing scripts on documentation routes and mixes public explainers with authenticated reporting. Astro serves the public knowledge layer; Next.js stays with any authenticated reporting where session and on-demand data are justified.

Routing keeps one domain and consistent security headers. Contract tests cover any authenticated API; a comparative crawl guards public URLs. Migration proceeds in stages: content first, then authenticated views. Rollback can target one route group instead of withdrawing the whole service. Monitoring and backups for authenticated areas stay separate from the public marketing CDN. Where payment or identity flows appear, iDEAL and related return paths are named in the cutover checklist.

#When migration is the wrong move

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, product launch or peak retail window in the Netherlands. 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 works with an Amsterdam 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 Amsterdam 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 Dutch notes when that matches the working language of the stakeholders. Meetings sit in hours that overlap the Netherlands and Poland, and questions that need a business decision go into one register. Local community references such as WordPress Amsterdam help with hiring and peer checks, but project decisions rest on the audit of the concrete system.

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 between Dutch and English. The client team gets a preview environment for content changes. Randstad specialist networks can supply people for later maintenance when the client prefers a local handoff.

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 Amsterdam team can keep evolving the system alone, with a chosen partner or with WPPoland, without a technical lock-in to one vendor.