Next.js / Astro Migration in Hamburg

Teams across Hamburg and the wider northern Germany corridor usually arrive at a migration conversation after something concrete stops working: a logistics site that fails Core Web Vitals while a peak sailing or fair calendar approaches, a media archive whose TYPO3 stack no living contractor can upgrade, or a Mittelstand exporter site where German and English product claims drift after every campaign. 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 Hamburg teams that need EU data discipline, DE-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 Hamburg is a TYPO3 install from the media and agency years whose extension landscape is frozen, PHP is out of support and the last person who understood the templates left years ago. Another is a WordPress theme welded to an unsupported page builder, so a PHP upgrade breaks career pages, certification PDFs and trade-fair landings that still attract indexed hits. On lead-generation and B2B exporter 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 northern German exporter is rewriting its offer for German 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 Hamburg 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 corporate site, a media landing cluster or a Mittelstand product catalogue in Hamburg 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 dealer or partner 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 partner portals, freight forwarders and archived campaign landings. 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.

Grown TYPO3 estates often carry parallel URL families: speaking RealURL paths indexed next to older index.php parameter addresses that nobody still links in the navigation. Migration is the moment to collapse duplicates on purpose, not to copy both families into the new frontend. 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 Germany and neighbouring markets we verify each hreflang pair and its return link across German 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 Hamburg teams that publish in German 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. German formal address conventions and English product copy need the same field structure even when tone differs. Where a subsidiary brand page shares assets with a Hamburg parent, the contract must say which locale owns the canonical claim.

TYPO3 inheritances follow a different path because the backend is usually part of the problem. We extract content from the database, clean it and move it into a fresh WordPress backend or, for smaller estates, into versioned Markdown inside the Astro project. Unused extensions are not ported; they are evaluated in workshops with the business units and dropped when nobody still needs them. 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 certificates and schedule PDFs.

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 German public holidays and industry weeks that matter to HH logistics and exporter calendars. 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, German-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 Hamburg organisation the reference points are the GDPR and German supervisory practice, alongside sector rules that apply to employment-related processing, logistics partner data or B2B 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.

German and English publishing is part of the data and SEO surface, not a late localisation task. DE 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 Hamburg 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 Hamburg and northern Germany

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

#Port and logistics site with duplicated content paths

A mid-sized logistics firm near the port ran a public WordPress site from the mid-2010s and, in parallel, a TYPO3 intranet where careers, certifications and company news were maintained a second time. Two editorial paths, two maintenance contracts, and neither surface stayed reliably current: applicants saw different vacancies on the public site than inside the intranet, and departments never knew which version was authoritative. Migration here was primarily consolidation. One WordPress backend became the single content source, an Astro frontend took the public site, and the previously TYPO3-only internal material moved into a restricted area on the same platform. Each piece of content is maintained once. After the measurement window the TYPO3 instance was shut down and one of the two maintenance contracts disappeared.

Acceptance covers publication counts, locale parity where German and English both ship, metadata and downloadable certificates. Forms tied to careers and partner enquiry paths are tested separately. A new frontend will not fix ownership drift on its own, so editorial decisions land before bulk import.

#Media and publishing stack with a frozen CMS inheritance

A media or agency-adjacent publisher in Hamburg inherited a TYPO3 estate whose agency no longer exists. No version control access, no documentation, extensions in a state where an upgrade path costs more than rebuilding the public layer. The work starts by extracting and cleaning content, then identifying which features the newsroom still needs in workshops. Astro serves article and landing routes; WordPress becomes the editorial backend when the newsroom wants a familiar publish tool. Two thirds of the old extensions often turn out unused and drop without a replacement. The project is less a visual redesign than an orderly inheritance, and it is planned that way.

Tests cover redirect completeness for archive URLs that still receive hits from newsletters and partner sites, schema for articles and organisation, and consent banners in each served language. Handover includes the repository, redirect map and a short runbook so the newsroom or a northern German partner can keep ownership without lock-in to the migration vendor. Peer checks through WordPress Hamburg can help with hiring later, but project decisions rest on the audit of the concrete system.

#Mittelstand exporter marketing hub with bilingual product narrative

An exporter with product and marketing based in Hamburg or the surrounding northern German corridor maintains a dense content hub: feature pages, comparison guides, compliance notes and downloadable datasheets. The old theme loads marketing scripts on documentation routes and mixes public explainers with authenticated dealer reporting. Astro serves the public knowledge layer; Next.js stays with any authenticated dealer or partner views 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. German and English product claims share entity IDs so a pricing narrative update in one locale does not leave a contradictory sentence in the other. Campaign landings tied to trade fairs are mapped deliberately; expired campaigns are not redirected en masse to the homepage.

#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, peak sailing season for a logistics calendar, or the most important trade fair week of the year for an exporter in the HH region. 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 Hamburg 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 Hamburg 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 German notes when that matches the working language of the stakeholders. Meetings sit in hours that overlap northern Germany and Poland, and questions that need a business decision go into one register. Local community references such as WordPress Hamburg and the wider MediaCity and digital hub networks 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 German and English. The client team gets a preview environment for content changes. Hamburg and northern Germany 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 Hamburg team can keep evolving the system alone, with a chosen partner or with WPPoland, without a technical lock-in to one vendor.