How to Get off WordPress
2. Choosing a Modern Replacement Architecture
Define boundaries, select services intentionally, and avoid recreating plugin sprawl.
2.1 Architecture philosophy
Good migration architectures share a few principles:
- Fewer moving parts with explicit responsibilities
- Managed services for low-differentiation infrastructure
- Clear interfaces between content, presentation, and integrations
- Failure isolation so one component does not bring down the full site
2.2 Opinionated reference stack
These are recommendations, not strict requirements.
Frontend
- Next.js App Router
- Tailwind CSS with a simple design token layer
Content and CMS
- Payload CMS for structured editorial workflows
- MDX for docs, long-form content, and developer-owned pages
- Custom admin panel only when CMS overhead is unnecessary
Data
- Neon Postgres for relational and reporting-heavy workloads
- MongoDB when Payload-native data modeling is preferable
Media
- Backblaze B2 as object storage
- Cloudflare in front for caching and delivery
- Brevo for transactional plus campaign-level workflows
Hosting and edge
- Vercel for frontend
- Managed hosting for Payload and database
- Cloudflare for DNS, WAF, and edge policies
WordPress vs modern stack
| Dimension | Typical WordPress setup | Modern decomposed stack |
|---|---|---|
| Update model | Plugin/theme core updates in one runtime | Isolated service updates |
| Attack surface | Large, plugin-driven | Smaller, service-scoped |
| Extensibility | Fast via plugins, often opaque | Explicit via APIs and code |
| Performance control | Mixed, plugin-dependent | Predictable with app-level control |
| Observability | Often fragmented | Centralized logs and metrics |
Decision checklist
Before finalizing stack choices, answer:
- Which components are business-differentiating?
- Which components should be outsourced to managed services?
- Which services must stay portable if vendors change?
- What is your acceptable monthly run cost and operational overhead?
Anti-patterns to avoid
- Rebuilding every plugin feature before launch
- Introducing multiple CMS systems without ownership clarity
- Shipping with no migration fallback path
- Selecting tools based on trend rather than team capability