Your next website might not need WordPress if its publishing needs are modest and its business functions are better handled by a focused application or external services. It probably should keep WordPress if replacing it would make everyday editing, commerce or integrations harder.
Choose the architecture around the work people need to do. Include the people who publish content and maintain the system in that decision.
“Modern” is a weak requirement. Being able to correct a product description without opening a support ticket is a useful one.
The cheapest hosting bill can conceal the most expensive publishing process.
First, stop comparing things that aren’t equivalents
WordPress, a static site, an edge platform, a frontend framework and a headless CMS occupy different parts of a website’s architecture.
A CMS manages content. A framework helps build the interface. Rendering determines when pages become HTML. Hosting runs or serves the result. Business services handle transactions, identity and other workflows.
Those choices can be combined. Astro, for example, prerenders pages by default but supports selected routes rendered on demand with an appropriate adapter. Cloudflare Workers can deploy static assets alongside application logic. Neither decision automatically determines which CMS you use.
WordPress can also supply content to a separate frontend through its REST API. Leaving a WordPress theme does not necessarily mean leaving WordPress as the editorial system.
This matters because a false either-or decision can produce an unnecessary rebuild. You may need to change one layer rather than replace the whole system.
Five options, five operating responsibilities
The following matrix is a decision aid, not a performance benchmark. These approaches overlap; a framework-built site can use an edge runtime and a headless CMS.
| Approach | Strong starting fit | Editorial responsibility | Cost that deserves scrutiny |
|---|---|---|---|
| Static site | Public content with limited personalization | Decide who edits content and triggers builds | Developer dependency, build failures and external form/search services |
| Workers or edge application | Focused APIs, routing and application workflows | Provide a CMS or another editing interface if needed | Authentication, data access, runtime compatibility and monitoring |
| Modern framework application | Interactive products, portals and custom experiences | Choose and integrate the content workflow | Dependencies, rendering choices, upgrades and application maintenance |
| Headless CMS with a separate frontend | Structured content reused across distinct experiences | Implement preview, publishing and content delivery together | Integration ownership, permissions, cache invalidation and vendor exit |
| Traditional WordPress | Content-led sites with established editorial and integration needs | Configure an existing editing and permission system | Theme/plugin quality, updates, hosting and accumulated customization |
A static site does not mean an unchanging site. It means that pages can be generated before a visitor requests them. Forms and other interactive features can use separate services.
But understand what your chosen output removes. Next.js static exports, for example, do not support framework features such as Server Actions, Draft Mode or request-dependent route handlers. Those capabilities require another implementation or a suitable server deployment.
“Built with Next.js” is therefore an incomplete architecture description. Ask what is deployed and what happens when a request arrives.
Editing is part of the product
Imagine the homepage needs an urgent correction while the developer is unavailable.
Can the content owner make it? Can someone review it? Can the team preview the result accurately? Can it publish without granting broad administrative access?
WordPress core provides roles and capabilities that distinguish contributors, authors, editors and administrators. That is useful infrastructure, although it does not automatically provide every organization’s approval workflow. Additional editorial requirements may need configuration or extensions.
A separate CMS can provide a strong editing experience too. Sanity’s documented visual editing supports draft previews, click-to-edit interactions and rearranging content sections. Its documentation also describes the frontend integration required to deliver that experience.
The fair comparison is between completed workflows.
A polished WordPress editor should not be compared with an unfinished headless preview. A well-designed headless system should not be compared with a neglected WordPress installation carrying years of unnecessary plugins.
Removing a dashboard may simplify infrastructure. It may also transfer routine work to a developer. Include that transfer in the estimate.
Use the Change-Day Test before choosing a stack
Here is an original framework for evaluating the shortlist: ask each proposed architecture to support four ordinary events.
1. Publish a change.
An editor updates a service page, changes an image and previews the result. Record the steps, permissions and people involved.
2. Complete a business action.
A visitor submits an inquiry or requests a quote. Show where the data goes, how failures are reported and how duplicate submissions are handled.
3. Recover from a mistake.
A bad release or incorrect content update reaches production. Explain the recovery process, including any data changes that a code rollback would not reverse.
4. Leave the platform.
Export content and media, identify vendor-specific dependencies and explain how another team could take over.
For each event, record the owner, expected effort, recurring charges and unresolved dependencies. Test representative workflows before making the final selection; a slide deck cannot establish that they work.
Then compare costs over the same planning horizon:
Ownership cost = implementation + hosting and services + maintenance + editorial labor + recovery planning + eventual exit work.
This is a budgeting structure, not a claim that one architecture always costs less.
Disqualify a proposal that has no credible owner for a critical workflow. A low estimate does not compensate for an unanswered operational question.
Three illustrative decisions
These are hypothetical scenarios, not client results.
A small professional-services site has public pages, occasional articles and a contact form. A static build may be a good fit if the editing workflow is straightforward and the form has a reliable submission service. A full application runtime may add little value. A content team publishing frequently could still justify a CMS.
A B2B commerce business already depends on an established WordPress commerce stack, account rules and business-system integrations. Replacing it because the frontend looks dated could turn a design project into a transaction-platform migration. First identify whether the actual constraint is presentation, performance, publishing or order operations.
An authenticated customer portal needs account-specific information and controlled actions. An application framework and suitable runtime may fit that work well, while WordPress continues to manage public content. Every private action still needs server-side authorization; a public page’s rendering strategy does not establish a user’s permissions.
The sensible architecture can differ across one organization’s website estate.
AI changes development economics, not operating obligations
AI-assisted tools can help produce code, layouts and integrations. That does not establish that the resulting system is easier to operate.
A generated publishing interface still needs usable controls. A generated API still needs authorization. A generated deployment configuration still needs someone who understands its failure modes.
Ask a sharper question than “Can AI build this?”
Ask: “Can our team maintain, inspect and change this safely after the original builder leaves?”
Prediction: as generating an initial interface becomes easier, ownership and change management will become more important differentiators. That is an editorial judgment about direction, not a forecast backed by a claimed statistic.
Migrate for a documented constraint
Good reasons to change include a publishing bottleneck, an integration the current architecture cannot support cleanly, unacceptable maintenance burden or a measurable experience problem.
A fashion cycle is a poor reason to migrate.
Before approving a rebuild, inventory URLs, content, media, forms, search, analytics, consent behavior, integrations and account access. Decide what must survive, what can be retired and who approves each change. Preserve useful content and plan redirects where addresses change.
Then evaluate one representative page and one meaningful workflow on the proposed architecture.
Document the result. Include the editor’s experience. Estimate ongoing work. Identify the smallest change that resolves the actual constraint.
Your next website may need less WordPress, more WordPress or a combination of systems. The decision should become clearer once somebody explains who will publish, who will maintain and who will recover it.
Sources
Primary documentation checked October 2, 2026. Platform capabilities are supported by the sources below; the comparison, Change-Day Test and ownership-cost framework are editorial recommendations. No hands-on platform comparison was performed.
- Astro: On-demand rendering
- Cloudflare Workers: Static Assets — documentation updated July 3, 2026
- Next.js: Static Exports — updated August 25, 2026
- WordPress: Roles and Capabilities
- WordPress: REST API Handbook
- Sanity: Visual editing — updated August 5, 2026