Replatforming a Legacy Website: WordPress vs Next.js vs Shopify

If your website runs on an ageing custom PHP application or a CMS that no longer gets updates, replatforming is usually the right call once security patching, hiring and everyday editing become harder than rebuilding. For most content-led business sites, WordPress is the lowest-risk destination; headless WordPress or Next.js with a headless CMS suits teams that need custom application features and have developers to maintain them; and Shopify fits when selling products is the main job. The choice matters less than the process: audit what exists, inventory the content, map every URL, build in parallel, test, launch and monitor.

This guide is for owners and managers of small and mid-size businesses and professional-service firms in the US, UK and EU whose site was built years ago and has become a liability. It explains the warning signs, compares the main options, covers the responsibilities that come with each, and sets out a staged plan.

Signs it's time to replatform

A single annoyance is not a reason to rebuild. A cluster of these is:

• Unsupported runtime. The site needs a PHP version that no longer receives security fixes. PHP publishes which branches are in active and security support on its supported versions page; if your site cannot run on a supported branch without significant rework, the risk keeps growing.
• Abandoned CMS or framework. The CMS, framework or key libraries have stopped releasing security updates, or the version you run is several majors behind and cannot be upgraded incrementally.
• Key-person dependency. Only one developer (often no longer available) understands the code.
• Editing needs a developer. Marketing cannot publish a page, change navigation or add a landing page without a ticket.
• Accessibility and consent gaps. The templates cannot be brought to WCAG 2.2 AA without rewriting, or analytics fires before consent and the code makes that hard to fix.
• Poor Core Web Vitals and mobile experience that trace back to the architecture rather than a few heavy images.
• Integration friction. Connecting a CRM, booking tool or payment provider requires custom glue every time.

If only one or two apply, a targeted fix (a PHP upgrade, an accessibility remediation, a new consent setup) may be the better investment.

The decision matrix: WordPress, headless WordPress, Next.js with a CMS, or Shopify

How to read it:

• Choose traditional WordPress when the site is mainly pages, posts and forms, the team wants to publish independently, and you want the widest pool of developers and hosts.
• Choose headless WordPress when editors love WordPress but the front end needs to behave like an application, or the same content feeds several channels. It roughly doubles the moving parts. The article on headless WordPress architecture covers when that complexity pays off.
• Choose Next.js with a headless CMS when the site is really an application (logged-in portals, calculators, dashboards, complex integrations) with marketing content around it, and you have developers on hand.
• Choose Shopify when the core of the business is selling products online and content is secondary.

For a broader comparison of the architecture styles, see headless CMS vs traditional CMS and Next.js vs WordPress for business websites.

Content modelling and editor experience

A legacy site's content usually lives in a mix of database tables, hard-coded templates and files. Replatforming is the chance to model it properly.

Model content by type, not by page

List the recurring kinds of content: service, location, team member, case study, article, FAQ, event, product, download. For each, define the fields (title, summary, body, image, related items, SEO fields) and the relationships between them. In WordPress this becomes custom post types and custom fields; in a headless CMS it becomes content types; in Shopify it becomes products, metafields and metaobjects.

Structured content pays off in consistent templates, reusable blocks, easier structured data, and cleaner migration next time.

Design for the people who publish

Ask editors what they do weekly, then make those tasks easy:

• Create a landing page from approved blocks without breaking the layout
• Update navigation and footer links
• Preview before publishing, on mobile as well as desktop
• Schedule posts and manage redirects when a URL changes
• Set roles and permissions so drafts are reviewed

Preview is the feature headless builds most often underestimate. It works out of the box in traditional WordPress; in a headless setup it has to be built and maintained.

Hosting, maintenance and security patching

Every option moves responsibility somewhere. Be explicit about who owns each item after launch.

• Traditional WordPress: you or your host keep WordPress core, themes, plugins and PHP current. WordPress applies minor core releases automatically by default, and automatic background updates can be configured for plugins and themes, but someone still needs to review major updates, test and keep backups.
• Headless WordPress: the same WordPress duties, plus the front-end framework, its dependencies and its hosting, plus the connection between the two.
• Next.js with a SaaS CMS: you own the framework version, npm dependencies, build pipeline and hosting; the CMS vendor patches their platform. Dependency updates need a regular schedule, not an annual scramble.
• Shopify: Shopify runs the platform. You own theme code, installed apps and their permissions, and staff account security.

Whatever you choose, write down: the patching cadence, who approves updates, where backups go and how restores are tested, uptime and security monitoring, and who is called when something breaks.

Accessibility and consent requirements for US and EU sites

A rebuild is the cheapest moment to get these right, because they are designed into templates rather than bolted on.

Accessibility

• In the EU, the European Accessibility Act (Directive (EU) 2019/882) applies to many e-commerce and consumer-facing digital services from 28 June 2025, as implemented in each member state's law.
• In the US, websites of businesses open to the public face litigation risk under Title III of the Americans with Disabilities Act.
• WCAG 2.2 level AA is the practical target in both markets.

Build it into components: semantic HTML, visible focus states, sufficient colour contrast, labelled form fields with clear errors, keyboard-operable menus and dialogs, captions for video, and alt text fields that editors are prompted to fill. Test with automated tools and manual keyboard and screen-reader checks before launch.

Consent and privacy

• For EU and UK visitors, non-essential cookies and similar trackers require prior consent under ePrivacy rules and PECR, and rejecting must be as easy as accepting.
• Google Consent Mode v2 is required for ad measurement and personalisation for EEA and UK traffic.
• Forms that collect personal data need a lawful basis under GDPR or UK GDPR, a privacy notice at the point of collection, data minimisation, and processor agreements with form, email and CRM providers.
• California residents have rights under the CCPA as amended by the CPRA, and US marketing email must meet CAN-SPAM.

This is general information, not legal advice; confirm obligations for your sector and markets with a qualified adviser.

A staged replatforming plan

The stages below describe order, not a fixed timeline.

1. Audit

Record what exists: technology, hosting, integrations (CRM, payments, booking, email), forms, scheduled jobs, user accounts, and any functionality hidden in the codebase. Capture baselines: organic landing pages and queries from Search Console, conversions by page from analytics, Core Web Vitals, and an accessibility scan.

2. Content inventory

Crawl the site and export every indexable URL. For each, record traffic, conversions, backlinks and owner, then decide: keep, rewrite, merge or retire. Map each kept item to its new content type.

3. Redirect map

Map every old URL with value to its closest new URL, following Google's guidance on site moves with URL changes: server-side permanent redirects, kept for as long as possible (generally at least a year). Legacy PHP sites often have query-string URLs such as /page.php?id=12, which need special handling because most path-based redirect rules ignore the query string.

If the new site is on Next.js, redirects can live in the config. Next.js's redirects documentation explains that permanent: true returns a 308, which Google treats like a 301. A next.config.ts example that handles both clean paths and a query-string URL:

`ts

import type { NextConfig } from "next";

const nextConfig: NextConfig = {

async redirects() {

return [

// Simple one-to-one redirect

{

source: "/about-us.php",

destination: "/about",

permanent: true,

},

// Pattern: /news/view.php/some-slug -> /insights/some-slug

{

source: "/news/view.php/:slug",

destination: "/insights/:slug",

permanent: true,

},

// Query-string URL: /page.php?id=12 -> /services/tax-planning

{

source: "/page.php",

has: [{ type: "query", key: "id", value: "12" }],

destination: "/services/tax-planning",

permanent: true,

},

];

},

};

export default nextConfig;

`

One caveat from the documentation: query parameters on the incoming request are passed through to the destination, so /page.php?id=12 becomes /services/tax-planning?id=12. That still resolves correctly, but set a canonical URL on the destination page. For thousands of legacy URLs, generate the array from a CSV at build time, or handle redirects at the web server or CDN instead.

On WordPress, redirects can live in a redirect plugin or in server rules; on Shopify, in the URL redirects admin. The website redirects guide covers testing and common mistakes.

4. Parallel build

Build the new site on a staging domain that is blocked from indexing (password protection is more reliable than robots.txt alone). Keep the old site live and unchanged except for essential fixes. Migrate content in batches, with automated imports where the data is structured and manual editing where it isn't. Rebuild integrations and forms, with the consent and privacy requirements above in place from the first version.

5. QA

• Content: every kept URL exists, with correct title, meta description, headings, canonical and structured data.
• Redirects: every row returns a single permanent redirect to a page that returns 200.
• Functionality: forms deliver, integrations sync, search works, logged-in areas behave.
• Accessibility: automated scan plus manual keyboard and screen-reader checks on key templates.
• Consent: no non-essential tags fire before consent; reject works; Consent Mode signals are correct.
• Performance: Core Web Vitals checks on key templates on mid-range mobile devices.
• Editor acceptance: editors publish, preview and schedule real content without help.

6. Launch

Lower DNS TTL in advance, deploy redirects with the new site, remove staging protection and noindex, confirm HTTPS, submit the new XML sitemap in Search Console, and inspect the homepage and top pages. If the domain is unchanged, the Change of Address tool is not needed; Google's documentation reserves it for domain and subdomain moves. Keep the old site's code and database archived so you can restore it if something serious goes wrong.

7. Monitoring

Check 404s, redirect errors and form submissions daily at first, then weekly. Compare organic clicks by page and conversions against the baseline, watch Search Console's Page indexing report for old URLs moving to "Page with redirect", and fix gaps quickly. Some fluctuation during a site move is normal; persistent drops on specific pages usually trace back to a missing redirect, lost content or changed metadata.

Choosing your next platform

Replatforming a legacy site is a chance to fix security, editing, accessibility and consent in one move, as long as the choice of platform follows from what the site needs to do and who will maintain it. A careful inventory and redirect map protect the search visibility the old site earned.

If you would like help deciding between WordPress, headless, Next.js or Shopify, or want a replatforming plan built around your content and integrations, see our website development services or contact us.