Next.js / Astro Migration in Manchester

Teams across Manchester and the wider Greater Manchester corridor usually arrive at a migration conversation after something concrete stops working: an agency marketing hub whose page builder cannot ship campaign landings without breaking Core Web Vitals, a university faculty site where research profiles and course pages drift across three CMS installs, or a retail brand storefront whose Black Friday scripts sit on every documentation and FAQ route. 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 Manchester teams that need UK data discipline, overlapping hours with a nearshore delivery base in Poland, and maintenance that is not locked to a single agency. Leeds often leans toward professional-services and fintech-shaped estates; Manchester work more often mixes creative-agency stacks, higher-education communication sites and consumer retail calendars. The delivery method is the same. The failure modes are not.

#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 around Manchester is a WordPress theme welded to an unsupported page builder, so a PHP upgrade breaks case-study grids, graduate recruitment landings and partner microsites that still attract indexed hits from MediaCity and northern England campaigns. Another is a Drupal or bespoke CMS where a small content change needs the one contractor who still knows the templates. On lead-generation and e-commerce 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 Greater Manchester retailer or agency is rewriting its offer for the next season. 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 Manchester 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 an agency portfolio, a university research hub or a retail brand content cluster in Manchester that means fast content pages without an application server on every request. An interactive calculator, course finder or form can run as an island without turning the whole site into a React application.

Next.js fits a client or student portal, a permission-aware dashboard, advanced product or vacancy 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 agency pitch decks, alumni portals, retail partners 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.

Agency and university estates often carry parallel URL families: clean paths indexed next to older query-string addresses, event microsites and campaign folders nobody still links in the main 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 the UK and neighbouring markets we verify each hreflang pair and its return link where 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 Manchester teams that publish across brand, faculty or retail channels, the model must treat ownership as a first-class field, not as duplicated page copies that diverge after every campaign. Shared identifiers for entities, consistent slug rules and clear ownership for each surface belong in the editorial contract before bulk import. Where a university department page shares assets with a central communications team, or a retail brand page shares copy with a marketplace listing, the contract must say which surface 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 application form or problems that exist only in a publication archive of case studies, course PDFs or product 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, ATS feed 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, applications or orders.

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 UK retail peaks, university clearing weeks and agency pitch calendars that matter in Greater Manchester. 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.

#UK data, GDPR-UK and international transfers

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 Manchester organisation the reference points are UK GDPR and the Data Protection Act 2018. We document data categories, the legal basis the client states, retention, processors, locations and any international transfer mechanisms. We do not assume that choosing a London region for one platform keeps every log and auxiliary service inside the United Kingdom. Frontend hosting, CMS, database, monitoring, backups, transactional email and analytics are checked separately.

Equality Act 2010 introduces duties around non-discrimination and reasonable adjustments, but a technical checklist does not replace legal assessment of a concrete service. In the project we 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 between Poland and the UK. Overlapping business hours support workshops with Manchester teams and incident response during cutover. Polish team access to client environments must appear in access documentation and transfer records. We use least privilege, named accounts, multi-factor authentication and an admin operation log. Cookie and consent copy must match the languages and markets actually served.

#Patterns we see around Manchester and Greater Manchester

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

#Agency marketing hub with campaign URL debt

A mid-sized digital or creative agency in Manchester runs a public WordPress portfolio, a separate tool for case studies and campaign landings that live as one-off folders for each pitch season. The same client, sector and capability appear under different names in three places. Migration here is primarily consolidation. One WordPress backend becomes the single content source; an Astro frontend builds the offer, case studies and capability pages from one data set. Historic campaign URLs keep deliberate 301s because they still receive hits from client decks and northern England partner sites. Search uses a prepared index so the whole site does not need to run as an application.

Acceptance covers publication counts, author and sector relations, metadata and downloadable PDFs. Enquiry forms tied to practice areas are tested separately. A new frontend will not fix ownership drift on its own, so editorial decisions land before bulk import. Compared with a Leeds professional-services estate, the Manchester agency pattern usually carries more short-lived campaign paths and fewer long-lived regulatory PDFs, so the redirect map needs explicit rules for expired landings rather than a blanket homepage redirect.

#University and research communication site

A faculty or research institute across Greater Manchester inherited a mix of WordPress, older departmental CMSs and manually maintained profile pages. Course pages, staff profiles and publications drift after every clearing cycle. The work starts by defining a shared content model and stable identifiers, not by picking a visual theme. WordPress stays the editorial backend when communications teams want a familiar publish tool. Astro serves public course, research and news routes; Next.js stays only where authenticated student or applicant views need session and on-demand data.

Tests cover redirect completeness for archive URLs that still receive hits from alumni newsletters and partner universities, schema for organisation and articles, and form paths for open days and applications. Accessibility checks focus on filters, validation messages and application forms. Candidate or applicant data does not enter the static build, and logs do not store CV contents. Handover includes the repository, redirect map and a short runbook so a central digital team or a chosen UK partner can keep ownership without lock-in to the migration vendor. Peer checks through WordPress Manchester can help with hiring later, but project decisions rest on the audit of the concrete system.

#Retail and consumer brand storefront with seasonal landings

A retail or consumer brand with marketing operations in Manchester maintains a dense content hub: product stories, comparison guides, store locator pages and seasonal campaign landings. The old theme loads marketing and remarketing scripts on documentation and FAQ routes and mixes public explainers with authenticated account or loyalty views. Astro serves the public knowledge and product narrative layer; Next.js stays with any authenticated account 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. Campaign landings tied to UK retail peaks are mapped deliberately; expired campaigns are not redirected en masse to the homepage. Inventory from Search Console often shows more seasonal URL churn than a Leeds fintech help centre, so measurement windows should avoid comparing a post-launch week against an unrelated peak trading period without noting the calendar.

#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, university clearing week, or the most important retail trading period of the year for a Greater Manchester brand. 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 Manchester 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 Manchester 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. Meetings sit in hours that overlap the UK and Poland, and questions that need a business decision go into one register. Local community references such as WordPress Manchester 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. The client team gets a preview environment for content changes. Greater Manchester 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 Manchester team can keep evolving the system alone, with a chosen partner or with WPPoland, without a technical lock-in to one vendor.