"WordPress is free and cheap to maintain." That's only true for the first year.
Then the real bill starts.
Headless CMS and Sanity as a natural exit from WordPress — it's a topic that keeps coming up in conversations about modern web stacks. Sanity is a solid choice for most projects, especially when paired with Next.js. There is, however, one thing Sanity doesn't give you: full data ownership. Your content and files are stored on Sanity's servers — AWS and Vercel infrastructure. For most clients, that's a non-issue. For some — it is.
That's what this article is about.
What WordPress actually costs
I touched this topic in the post “WordPress Is Not Cheap. It's Expensive — Just Differently”.
SiteGround — one of the most recommended WordPress hosts out there. Startup plan: $2.99/mo for the first year. Renewal price? $17.99/mo — a 501% increase. GrowBig, which you actually need once staging environments and multiple sites enter the picture, renews at $29.99/mo, or around $360/yr.
Kinsta doesn't play those games — it starts at $35/mo with no promotional pricing. But Kinsta doesn't include email hosting. Add Google Workspace separately.
Realistic hosting cost for a business website from year two onward: $15–35/mo. Not $3.
Plugins: the cost that never appears in quotes
WordPress core is free. Every non-trivial feature — isn't.
Every line item has a concrete reason. WP Rocket exists because WordPress is architecturally slow without caching — every request goes through PHP to the database. That's not a weak server problem, it's a built-in cost of the platform. WP Rocket is a workaround for a problem WordPress ships with.
Wordfence Premium — the free version updates threat signatures with a 30-day delay compared to the paid tier. For a month after an exploit is discovered in a popular plugin, your site is running without current protection. For a business site handling customer data, that's not acceptable.
That's before adding the cost of a developer spending 1–2 hours a month on updates and putting out fires after plugin conflicts. At $75–100/hr, add another $900–2,400/yr.
With WooCommerce, you stack Automattic's official extensions on top: subscriptions $279/yr, abandoned cart recovery $79, product add-ons $79. Three or four extensions and you're past $500–600/yr before counting hosting.
Sanity — great, but not for every project
Sanity is a solid tool for Next.js projects — the editor, GROQ query language, smooth Server Components integration. For projects with a content team managing their own copy, Sanity is hard to beat.
There is, however, a scenario where it's out before the conversation really starts.
A corporate client sets a condition: data must stay on their own infrastructure, or at minimum in the EU, fully under the organization's control. Healthcare, legal, finance — where the client contract explicitly defines where data can be stored. Sanity keeps content on US servers. End of conversation.
Which raises the question: is there something that gives you a TypeScript headless CMS, just as smooth with Next.js — but with data on your own server?
Payload CMS is the answer.
Payload CMS — how it works inside Next.js
Payload v3 isn't a separate application requiring a separate deployment. It runs directly inside your Next.js project — one repository, one deploy, one server:
/app
/(frontend) ← your site
/(payload) ← admin panel, generated from config
/collections ← data structure definitions in TypeScript
/payload.config.ts
The admin panel generates automatically from your TypeScript config. Add a field to a collection and it appears in the editor immediately — typed end-to-end on the frontend. Data is fetched in Server Components without any HTTP call:
const payload = await getPayload({ config })
const posts = await payload.find({ collection: 'posts' })In Sanity, every data query is a network call. In Payload it's a local function — zero latency, zero CORS configuration, zero separate project to maintain. Authentication, roles and permissions, content versioning, and a rich text editor (Lexical) all come included, no extra plugins needed.
Infrastructure — the decisions you need to make
WordPress required zero infrastructure decisions. cPanel, one click, WordPress ready. Payload requires four deliberate choices before the first line of code.
Database — Payload supports PostgreSQL and MongoDB. For new projects, PostgreSQL via Neon works well (serverless Postgres, free tier covers most early-stage needs, paid plans from $5/mo) or Supabase (from $25/mo with persistent compute, no cold starts).
File storage — Payload doesn't store files locally in production. Cloudflare R2: 10 GB free, zero egress fees — unlike AWS S3, which charges for every file download. Payload has an official R2 adapter. For most business sites, the cost rounds to $0.
Email — Payload needs SMTP for password resets and system notifications. Resend: 3,000 emails/mo free, templates as React components. Pro from $20/mo.
Hosting — three approaches: Vercel Pro ($20/mo) when you want zero configuration. Railway ($20/mo per workspace, not per seat) for team projects — cheaper than Vercel for two or three people. Hetzner CX22 + Coolify (€4.49/mo) for full autonomy and self-managed infrastructure.
WordPress from year two: ~$845/yr. The difference is roughly $600/yr. The first implementation costs more in developer time — break-even typically lands around 12–18 months in.
When this decision makes sense — three scenarios
Scenario 1 — Business site with accumulating technical debt
Dozens of plugins, no staging environment, two languages handled by Polylang, Core Web Vitals in the red, shared hosting that "always worked." The client asks about a refresh and a better content management experience.
Three paths here: a proper WordPress cleanup and staying on the platform, migrating to Sanity, or moving to Payload. One important caveat: when there's no technical person on the client's side day-to-day — Payload doesn't fit. That's Sanity or a well-maintained WordPress.
Scenario 2 — WooCommerce shop with custom logic
Product configurator, B2B pricing per client, ERP integration, subscriptions. WooCommerce handles this through five or six paid extensions, each on its own update cycle and carrying its own conflict risk on every upgrade. Extension costs exceed $600/yr, and modifying the checkout without workarounds is practically impossible.
This is a case where Medusa.js + Next.js or Payload as a custom application backend has real justification — not just technical, but economic.
Scenario 3 — Data residency requirements
Healthcare or legal sector, contract with a data storage location clause. Sanity is out — US servers. WordPress is out — security with dozens of plugins is a gamble. Payload on a VPS in Germany (Hetzner) with a Postgres database and regular backups is the only option that satisfies the requirements at a reasonable cost.
When Payload CMS is the wrong choice
Small business blog or landing page with a handful of pages. Setting up a database, storage, and hosting for a simple brochure site is overkill. WordPress or Next.js with Sanity on the free tier will get you there faster and cheaper.
The client manages the site on their own, with no technical support. WordPress has two decades of tutorials, a large community, and dozens of agencies the client can turn to at any point. Payload needs technical backup for structural changes — without it, the client loses the autonomy WordPress gave them.
Budget under $2,000–2,500. Designing collections in TypeScript, configuring infrastructure, building the frontend from scratch — that's easily a dozen billable hours before the first page exists. At a tight budget, configuration time eats the margin and the point of the project.
No plan for long-term technical maintenance. Someone has to update dependencies, respond when the database has a problem, check logs when something stops working. Without that resource — in-house or through a planned support agreement — WordPress with managed hosting is the safer decision for both sides.
Tight deadline with no buffer. With WordPress you have a working prototype in a few hours. With Payload, the first sensible development environment takes a day or two. On a schedule without slack, that matters.
Payload is not the default answer to "what instead of WordPress." It's the right answer for a specific group of projects.
Principles of website pricing were published in the post “How Much Does a Modern Website Cost in 2026?”
Migration: what to expect
A full walkthrough deserves its own article — but a few things worth thinking through before making the decision.
Content audit — what to migrate (posts, pages, custom post types, media, forms), what to leave behind. In a typical WordPress install, 30–40% of posts are content with no traffic for years. Moving everything is wasted time with no upside.
Designing collections in TypeScript — mapping WordPress structure onto Payload collections. Custom post types tend to accumulate fields from several different plugins — migration is also an opportunity to design the structure from scratch, without the built-up clutter.
Migration script — export from WordPress via XML or MySQL, import through the Payload Local API. The hardest part is media. Files from /wp-content/uploads/ need to move to R2 or S3 and every reference in the content updated — this is typically 30–50% of total migration time.
301 redirects — WordPress generates URLs in the format /2024/03/post-title/, Next.js will have a different structure. Every unmapped old URL is a lost search ranking. A redirects array in next.config.js covering every old URL is a required deliverable, not optional.
DNS cutover — drop TTL to 300 seconds the day before, flip the switch, keep the old WordPress server running for a week. Just in case.
Summary
Payload CMS is not a better WordPress. It's a different philosophy — more responsibility on the developer's side, but full control over data, infrastructure, and costs. From year two, the cost difference versus WordPress is around $600/yr. The first implementation costs more upfront in time.
For a good portion of projects, Payload simply isn't the right fit — and it's worth saying that clearly before anyone starts designing collections.