Next.js / Astro Migration in Copenhagen

Teams across Copenhagen and the wider Øresund corridor usually arrive at a migration conversation after something concrete stops working: a supplier site that fails Core Web Vitals on mobile while a trade fair in the Medicon Valley calendar approaches, a marketing stack that cannot ship Danish and English without claim drift, or a design-agency handover where the theme only one contractor understands. 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 Danish teams that need EU data discipline, DA-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 Copenhagen is a WordPress theme welded to an unsupported page builder, so a PHP upgrade breaks the templates that carry product datasheets and regulatory narratives for life-science buyers. Another is a Drupal or custom CMS where a small change needs the one contractor who still knows the deploy path across a Danish parent site and a Swedish sister brand. 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 Nordic SaaS team is rewriting its offer for Danish 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 Copenhagen 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 life-science supplier library, a design studio portfolio or a Nordic SaaS marketing site in Copenhagen 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 product or document 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 - including traffic that still arrives from Swedish partners across Øresund. 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 Denmark and neighbouring markets we verify each hreflang pair and its return link across Danish 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 Copenhagen teams that publish in Danish 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. Danish orthography, formal address conventions and English product copy need the same field structure even when tone differs. Where a Swedish brand page shares assets with a Danish parent, the contract must say which locale owns the canonical claim.

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 of technical datasheets.

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 CRM handoff or newsletter confirmation. 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 Danish holidays and industry event weeks in Greater Copenhagen. 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, Danish-English publishing and EU processors

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 Copenhagen organisation the reference points are the GDPR and Danish supervisory practice through Datatilsynet, alongside sector rules that apply to life-science suppliers, employment-related processing or SaaS account data. 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.

Danish and English publishing is part of the data and SEO surface, not a late localisation task. DA 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. 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 Copenhagen 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 Copenhagen and Øresund

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

#Life-science supplier site with regulated product narrative

A supplier serving hospitals, labs or manufacturing partners in Greater Copenhagen and across Medicon Valley runs WordPress for the public catalogue, application notes and careers pages. Growth experiments added landing templates that never joined a shared content model. Danish and English product claims drifted after successive campaigns, and PDF datasheets still attract indexed hits that the new IA must not orphan. Migration starts with stable identifiers for product entities, indications and downloadable assets, not with a visual redesign. WordPress stays the backend; Astro builds marketing and publication routes from one dataset. Existing guide and datasheet URLs are preserved because they already rank and appear in partner mailings. Interactive configurators or account areas 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.

#Design agency delivery for Danish and Nordic clients

A design or digital studio in Copenhagen 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 Danish and English 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. Peer checks through WordPress Copenhagen can help with hiring later, but project decisions rest on the audit of the concrete system.

#Nordic SaaS marketing hub with bilingual product narrative

A SaaS company with product and marketing based in Copenhagen maintains a dense content hub: feature pages, comparison guides, changelog notes 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. Danish and English product claims share entity IDs so a pricing narrative update in one locale does not leave a contradictory sentence in the other.

#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 industry week in Greater Copenhagen. 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 a Copenhagen 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 Copenhagen 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 Danish notes when that matches the working language of the stakeholders. Meetings sit in hours that overlap Denmark and Poland, and questions that need a business decision go into one register. Local community references such as WordPress Copenhagen 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 Danish and English. The client team gets a preview environment for content changes. Greater Copenhagen and Øresund 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 Copenhagen team can keep evolving the system alone, with a chosen partner or with WPPoland, without a technical lock-in to one vendor.