The right web stack is the smallest architecture that can support the next few years of publishing, customer experience, integrations, governance and change—without making routine work unnecessarily expensive. That may be conventional WordPress, a static site on the edge, a hybrid or headless build, or a custom application. The winner is not the newest tool. It is the option your business can operate responsibly.
Migrate when a measured constraint is more costly than the move. Otherwise, improve the system you have.
Stack debates become unproductive when tools turn into identities. “We are a headless company” is not a requirement. Neither is “everything must stay in WordPress.” A useful decision starts with what people must accomplish, who owns the work after launch and what happens when conditions change.
Four valid answers to different problems
Conventional WordPress fits when editors need direct control, structured content and commerce or publishing capabilities benefit from a mature ecosystem. Its costs include updates, plugin governance, performance work and the discipline to keep extensions supportable.
Static or edge-delivered sites fit focused websites with modest publishing complexity, predictable integrations and a team comfortable with the chosen deployment workflow. They can be fast and resilient, but a cheap runtime can hide an expensive content-change process. Cloudflare’s current Workers documentation supports deploying static assets and server code as one unit, with assets served and cached across its network. That is a capability, not a reason by itself to replatform. [3]
Hybrid or headless systems fit when content must serve multiple experiences, front-end releases need a separate cadence, or application behavior cannot live comfortably inside the CMS. They also create two operating surfaces: preview, caching, revalidation, authentication, search and incident ownership all need explicit design.
Custom applications fit when the website is primarily a product or workflow: complex permissions, proprietary data, decision logic, account experiences or automation. Custom should mean deliberately owned—not endlessly bespoke. Every unique subsystem becomes something the business must test, secure, observe and eventually replace.
These are not maturity levels. A ten-page editorial site is not “behind” because it does not have a decoupled front end. An enterprise platform is not “modern” because it has more repositories.
The Seven-Lens Stack Scorecard
This is an original decision framework, not a vendor benchmark or certification. Score each candidate from 1 (poor) to 5 (strong), multiply by the weight, and require a named owner plus evidence for every score. Add the weighted scores and divide by five for a result out of 100. A spreadsheet full of unsupported fives is just architecture theater.
| Lens | Weight | The business question |
|---|---|---|
| People & publishing | 15 | Can the actual team create, review, preview, schedule and correct content without a developer bottleneck? |
| Experience | 15 | Can it deliver the accessibility, performance, search and interaction quality users need? |
| Integrations & workflows | 15 | Does it support commerce, CRM, search, identity, analytics and automation with clear failure handling? |
| Governance & risk | 15 | Can permissions, privacy, security, approvals and compliance responsibilities be enforced and demonstrated? |
| Operations & resilience | 15 | Who monitors, deploys, restores and supports it—and can that team do so during an incident? |
| Economics | 15 | What is the three-year cost of licenses, hosting, engineering, editorial labor, integration maintenance and downtime? |
| Exit & changeability | 10 | Can content, data, URLs and business logic move without a hostage negotiation? |
The weights should change only when the business case says so. A regulated publisher may raise governance. A campaign site may emphasize speed to launch and editorial simplicity. Keep the total at 100, publish the assumptions and run the scorecard with editorial, marketing, engineering and operations in the room.
Official GOV.UK service guidance makes the same underlying point: technology is a significant investment, decisions should include total cost of ownership, and teams should preserve the ability to change direction. Its technology-choice guidance also warns that splitting a system into components too early can create the wrong boundaries, and recommends open standards to make later change easier. [1] [2]
Use migration triggers, not migration moods
A migration becomes defensible when one or more of these conditions is documented:
- Repeated user failure: important journeys miss agreed accessibility, reliability or performance outcomes despite targeted remediation.
- Editorial obstruction: ordinary publishing requires development work, workarounds or risky production changes.
- Integration ceiling: critical systems cannot be connected or maintained within acceptable security and reliability boundaries.
- Product mismatch: the experience has become an application whose permissions, data or workflows strain the current CMS.
- Supportability risk: the platform, dependencies or knowledge base can no longer be maintained responsibly.
- Economic proof: a realistic three-year comparison shows the move costs less—or unlocks measurable value worth the difference.
“A competitor uses it,” “the redesign would be fun,” and “one lab test produced a dramatic screenshot” are not migration triggers. Core Web Vitals are useful experience signals, but web.dev explicitly describes them as imperfect and recommends field measurement alongside lab tools. Treat performance as an acceptance criterion measured with real users, not a framework popularity contest. [5]
Leaving a functioning system alone can be the modern choice
If people can publish, customers can complete the important journeys, risks are managed and the operating cost is understood, replacement may create more risk than value. Modernization can happen inside the current architecture: simplify the theme, standardize components, remove unsafe extensions, improve caching, add deployment checks, repair semantics and structured data, tighten permissions and instrument real-user performance.
WordPress’s own REST API handbook makes a refreshingly practical point: do not feel pressured to use the API if a site already works as expected. Use it when an external or custom experience needs structured access to content—not because decoupling looks sophisticated on a diagram. [4]
Illustrative scenario: a manufacturer has a stable WordPress site, a small editorial team, several CRM forms and a product catalog that does not transact online. If the experience, security posture and publishing workflow are sound, rebuilding the front end headlessly may add preview, cache and deployment work without creating customer value. A better first move might be a component cleanup, integration tests and an edge-caching review.
Illustrative counterexample: a B2B portal needs account-specific catalogs, approval chains, contract pricing and actions across several systems. That behavior may justify a custom application layer, with WordPress or another CMS still governing public content. The architecture changes because the work changed.
A 90-day modernization roadmap
Days 1–30: measure and map. Inventory content, templates, plugins, integrations, data flows, permissions, redirects and deployment responsibilities. Establish field performance, accessibility, search, conversion and editorial baselines. Interview the people who publish and support the site. Write down what must not break.
Days 31–60: repair and prove. Fix high-value problems that do not require migration. Remove dead dependencies. Add backups, restore tests, monitoring and release checks. Prototype the riskiest proposed change in a contained slice—one template, workflow or integration—and measure the operating effort, not just the demo.
Days 61–90: decide and sequence. Score the realistic options. Compare staying, improving in place and migrating. Name owners, costs, exit plans and acceptance criteria. If migration wins, phase it around business capability, rehearse content and data movement, preserve URLs, define rollback and make the first release smaller than the ambition.
Supported fact
The cited platform and standards documents describe current capabilities and decision principles. They do not select a stack for a particular company.
Editorial position
Architecture should minimize total organizational burden while preserving the ability to change. “Boring to operate” is a compliment.
Prediction
More organizations will run mixed portfolios: conventional CMS sites, edge-delivered experiences and custom applications connected by governed APIs. Stack purity will matter less than knowing which team owns each boundary.
The web stack is not a vote for or against WordPress, headless, static or custom. It is a commitment about how the business will publish, integrate, govern, recover and change. Make that commitment with evidence. Then stop arguing about labels and improve the work.
Sources
- GOV.UK Service Standard, Point 11: Choose the right tools and technology — updated January 29, 2026; total cost of ownership, future flexibility, legacy and inclusive user experience.
- GOV.UK Service Manual: Choosing technology—an introduction — updated October 15, 2024; component boundaries, reversible decisions and open standards.
- Cloudflare Workers: Static Assets — updated July 3, 2026; integrated deployment of static assets and Worker code with network caching.
- WordPress REST API Handbook — official explanation of structured content access and explicit guidance not to adopt the API when an existing site already meets the need.
- web.dev: Web Vitals — current Core Web Vitals definitions, limitations and measurement guidance.