Payload CMS vs Sanity: An Agency’s Honest Take After 20+ Migrations

Intro

If you’re reading this on the Pagepro website, you should know something upfront: we build migrations to Sanity. Our entire Nexity delivery framework runs on it. We’ve completed 20+ production migrations using Sanity + Next.js, and we sell that service.

So why write a comparison that might send you to Payload?

Because engineers and marketing leaders evaluating a CMS for a migration project deserve an honest breakdown, not another feature table engineered to make one platform look inevitable. We’ve looked at both closely. We’ve referred work away where Sanity wasn’t the right fit. This post is what real production experience — not vendor documentation — has taught us.

Two things worth knowing about how this comparison

First, we’re focused on the migration use case specifically. If you’re starting a new project from a blank repo, the calculus shifts in places we’ll flag. If you’re moving an existing content-heavy site — from WordPress, a legacy monolith, or an ageing Drupal installation — this post is written for that decision.

Second, we’re writing this in mid-2026, one year after Figma acquired Payload. That acquisition changed the product roadmap, the managed hosting model, and the risk profile of choosing Payload for a long-term migration. We’ll address it directly, not in a footnote.

By the end, you’ll know which platform fits your team, your migration complexity, and your content workflows — and why we built Nexity on Sanity instead of the alternative.

The fundamental difference: what you’re actually choosing between

Every other difference between Sanity and Payload — pricing, editorial UX, performance, data ownership — flows from one architectural decision made at the infrastructure level. Understanding it first makes everything else easier to evaluate.

Sanity is managed SaaS. Your content lives in Sanity’s hosted backend, called the Content Lake. The CDN, the asset pipeline, the real-time collaboration infrastructure, the GROQ query layer — all of it runs on Sanity’s servers. 

You host the Studio (the admin UI) yourself or let Sanity host it, but the content backend is always theirs. You’re buying a content operating system, not running one.

Payload is a self-hosted Node.js framework. It installs directly into your Next.js application. You choose your database — PostgreSQL for production, MongoDB if your data model calls for it, SQLite for local development. You choose your hosting: a VPS, Vercel, Cloudflare, a Kubernetes cluster. 

There is no external API call between your frontend and your CMS at the data layer. Payload’s Local API queries your database directly from server components. You’re running infrastructure, not subscribing to it.

This is not a minor implementation detail. It determines who manages uptime when things go wrong at 2am, who owns your content data and where it lives, how your costs scale as your team and document count grow, and how much DevOps capacity your engineering team needs to maintain the platform over time.

Neither model is inherently better. The question is which one matches your team’s capacity and your organisation’s risk tolerance. A five-person engineering team with no dedicated DevOps will experience Payload very differently from a fifteen-person team with a senior infrastructure engineer on staff.

Start there. Everything else — visual editing, migration tooling, editorial UX, pricing — is a second-order concern if you get this wrong.

What the Figma acquisition means for your long-term CMS decision

On June 17, 2025, Figma announced that the entire Payload team was joining the company. The MIT licence and GitHub repository remained unchanged. The core product kept shipping — Folder View, scheduled jobs, soft delete, and array copy/paste all landed post-acquisition as fully open-source features. On paper, nothing broke.

But three things changed that are directly relevant if you’re choosing Payload as a migration destination in 2026.

Payload Cloud stopped accepting new projects.

 Managed hosting — the option that removed the infrastructure burden for teams without dedicated DevOps — was paused following the acquisition. 

Self-hosting continues to work normally, but if your team was counting on a Payload-managed option to reduce operational overhead, that path is currently closed. No timeline for reopening has been announced.

The product roadmap is now Figma’s roadmap.

 The acquisition was made to power Figma Sites — Figma’s new product for going from design to deployed website inside a single tool. Payload is being integrated as the content backend for that ecosystem. That’s a legitimate and exciting product vision. It also means the Payload team’s primary focus has shifted from “best standalone headless CMS” to “best CMS inside Figma’s platform.” 

For teams building inside the Figma ecosystem, this is a strong signal. For teams evaluating a pure headless CMS for a content migration, it introduces a question worth asking: will the features you need as a standalone CMS remain a priority as Figma’s integration deepens?

Figma filed for IPO in July 2025. 

This matters for enterprise risk assessment. A publicly traded Figma will face pressure to monetise Payload as part of its platform offering. Open-source commitments made by founders pre-IPO carry genuine weight — the MIT licence cannot be revoked — but the commercial layer built on top of the open-source core is where the real product direction will play out over the next two to three years.

To be direct about what this means in practice: Payload is not going away, and the open-source project is genuinely well-maintained. The risk is not abandonment. The risk is that Payload’s roadmap increasingly optimises for the Figma-native workflow rather than the standalone headless use case. If your migration destination needs to work independently of Figma’s ecosystem for the next five years, that trajectory is worth tracking before you commit.

Sanity vs Payload for migration projects specifically

Most comparisons of these two platforms are written for greenfield decisions. That’s not what a migration is.

A migration means existing content, existing URLs, an existing editorial team, and a search ranking you cannot afford to lose. The criteria shift. Here’s where the two platforms diverge specifically when you’re moving an existing site — not building a new one.

Redirect management

When you change your URL structure during a migration — and you almost always do — every old URL needs a 301 redirect to its new destination. Get this wrong, and you can lose years of accumulated link equity overnight.

Bottom line: On a migration with hundreds of redirects and a non-technical project manager, Sanity’s approach saves weeks. Payload’s approach is buildable — but you’re building it yourself, every time.

Content schema migration

Moving legacy content from WordPress, Drupal, or a custom CMS means mapping old data structures to new ones. Both platforms handle this in code. But the experience diverges fast.

Sanity: GROQ’s flexibility makes complex content transformations significantly faster for nested structures. Portable Text handles rich text in a way that preserves formatting nuance across content types. The Studio gives non-technical stakeholders visibility into the schema without touching code.

Payload: Strongly typed TypeScript schemas are genuinely excellent for developers. But without GROQ, complex content transformations require more custom query logic. For straightforward migrations the difference is minor. For content-heavy sites with deeply nested relationships, it compounds over the course of a project.

For content-heavy migrations with complex data structures, GROQ’s query flexibility consistently saves our team two to three weeks of custom transformation work per project.

Editorial team onboarding

Your content team lives in the CMS after launch. Their ability to work independently — without raising a ticket to update a headline — directly determines whether the migration delivers its promised business value.

Sanity wins this category outright. Real-time collaboration, inline comments, live preview, image hotspot editing, and a structure builder for custom navigation — all production-grade, refined over years of daily use. Non-technical editors learn it in a day.

Payload’s v3 admin UI is well-designed and has improved substantially. But it remains primarily developer-facing. For content teams working in the CMS five days a week, the gap is real — and it shows up in onboarding timelines and ongoing support costs.

SEO continuity during migration

The fear every Head of Marketing raises first: “Will we lose our rankings?”

Both platforms cover the technical SEO fundamentals — metadata API, sitemap, robots.txt, canonical URLs. The difference is readiness versus assembly.

On a fixed-price, fixed-timeline migration, every hour of custom SEO setup is an hour not spent migrating content. That trade-off compounds.

When Sanity is the right choice

Sanity is the right migration destination when your primary constraints are editorial velocity, SEO continuity, and infrastructure simplicity — and when the team making the migration decision isn’t also the team that will be running servers at 2am.

Here’s the specific profile where Sanity consistently outperforms.

Your content team works in the CMS daily

If editors, marketers, or content managers are the primary CMS users — not just developers — Sanity’s Studio is in a different category from anything else in the headless market. Real-time multiplayer editing, inline commenting, live preview, and a structure builder that maps to how editorial teams actually think about content are all native, not bolted on.

The practical test: hand your most non-technical content manager a Sanity Studio after two hours of onboarding and see whether they can publish independently. In our experience , the answer is consistently yes.

With Payload, the honest answer is more often: not yet, and not without developer support.

You cannot afford an SEO drop during migration

This is the single most common fear we hear from Heads of Marketing before a migration project starts. It’s also the area where the choice of CMS matters most — not just the choice of agency.

Sanity is the right call here when:

• You’re migrating a site with significant organic traffic and established rankings
• Your URL structure is changing substantially and redirect volume is high
• Your marketing team needs to monitor and adjust the redirect map post-launch without raising dev tickets
• You need SEO-safe metadata, OG images, and sitemap coverage from day one — not after a sprint of custom build work

Your engineering team doesn’t have dedicated DevOps capacity

This is where the managed vs self-hosted split becomes a business decision, not just a technical preference.

You’re migrating from a complex legacy CMS

WordPress, Drupal, a custom PHP monolith — the more complex the source content model, the more Sanity’s content architecture advantages compound. GROQ’s ability to query and transform nested content structures, combined with Portable Text’s handling of rich editorial content, makes Sanity a faster and lower-risk destination for content-heavy migrations specifically.

If you’re migrating a five-page brochure site, the CMS choice barely matters. If you’re migrating 2,000 articles, 40 content types, and a taxonomy that’s grown organically over a decade — it matters significantly.

The one-line version: Sanity is built for teams that want to focus on content and product, not infrastructure. For Digital Native SMBs running a migration without a dedicated DevOps function, that trade-off is almost always correct.

When Payload is the right choice

Payload is the right choice when your constraints are infrastructure control, data ownership, and application complexity — and when your engineering team has the capacity to own what they build.

The honest version of this section: the teams for whom Payload is genuinely the better answer are not the same teams Pagepro typically works with. That’s not a knock on Payload. It’s a profile mismatch worth naming clearly.

Your CMS is also your application database

This is Payload’s strongest use case — and one where Sanity genuinely cannot compete.

If you’re building a product where the CMS needs to model not just content but application data — user records, orders, permissions, multi-tenant structures, complex relationships — Payload’s Local API gives you a zero-latency, type-safe database layer that lives inside your Next.js application. There’s no external API call. No Content Lake to query. Your CMS and your product database are the same system.

Sanity is not designed for this. It’s a content operating system, not an application framework. Forcing it into this role creates architectural debt that compounds as the product scales.

If your migration destination needs to handle both editorial content and product data in a single coherent system, Payload is the more defensible long-term choice.

You have dedicated DevOps capacity and want full infrastructure control

For teams in this profile, Sanity’s managed infrastructure is a constraint, not a benefit. Paying for a managed backend you’d rather control yourself is the wrong trade-off.

Compliance or data residency rules out third-party hosting

This is a hard requirement in certain industries and regions, and it’s non-negotiable. If your legal or security team cannot approve content storage on a third-party US-based SaaS backend, Sanity is disqualified regardless of its other merits.

Payload’s self-hosted model means your content lives exactly where you decide it lives — your own VPS, your own cloud account, your own jurisdiction. For healthcare platforms, financial services, and government-adjacent projects, this is often the deciding factor before any other comparison gets made.

You’re deep in the Figma ecosystem and the acquisition roadmap is a feature

If your design-to-development workflow already runs through Figma, and your team wants a CMS that will eventually connect directly to Figma Sites — with design components mapping to CMS collections, real content in prototypes, and a unified design-to-deployment workflow — then the Figma acquisition is not a risk to manage. It’s a product direction to lean into.

This is speculative — the Figma-native CMS integration is not fully shipped as of mid-2026. But the direction is clear and the founding team is intact inside Figma. If this vision resonates with how your team works, Payload is the one to watch.

Your editorial team is very small and per-seat pricing matters at scale

Sanity’s Growth plan charges per editor seat. For teams with one or two people in the CMS, this is negligible. For teams with fifteen editors across multiple markets, it compounds into a meaningful line item.

Payload has no per-seat cost at the CMS level. If your primary driver for switching CMS is reducing platform costs — and your editorial team is large relative to your engineering team — the total cost of ownership calculation can shift in Payload’s favour over a three-year horizon, even accounting for self-hosting overhead.

The one-line version: Payload is the right choice for engineering-led teams building product applications that happen to need a CMS — not content-led teams running a migration who need the CMS to stay out of the way.

Pricing reality at scale

Sticker prices on both platforms tell you almost nothing. Here’s what the real cost looks like when you factor in hosting, editor seats, and developer time — across three scenarios relevant to Pagepro’s ICP.

What Sanity actually costs

Sanity’s free tier is genuinely useful for small projects — up to three users, with generous API limits. Beyond that, pricing scales in two directions: per editor seat on the Growth plan, and API usage at high content request volumes.

The per-seat model is Sanity’s most significant pricing vulnerability for larger editorial teams. A marketing organisation with fifteen editors across multiple markets is paying a meaningful monthly subscription, regardless of how much content they actually publish. For content-light sites with small teams, this is negligible. For media companies or large e-commerce operations, it compounds.

What Sanity does not cost: DevOps time, database administration, server maintenance, backup management, or infrastructure incident response. Those costs are absorbed into the subscription. For teams without dedicated infrastructure engineers, this is where the managed model pays for itself.

What Payload actually costs

Payload’s MIT licence means the software itself is free. What you’re actually paying for is the infrastructure to run it.

Self-hosting on a VPS runs roughly €7–45 per month depending on your provider and traffic requirements. Add a managed Postgres service — Neon or Supabase for serverless — and you’re looking at an additional €20–50 per month at moderate scale. There are no per-seat fees at the CMS level.

What Payload does cost: the developer hours to set up, maintain, and monitor that infrastructure. A senior engineer spending two to four hours per month on Payload infrastructure management is a cost that doesn’t appear on any invoice but shows up directly in your effective delivery rate.

Real cost comparison across three scenarios

The pattern is consistent with what most production teams find: Sanity wins on total cost at small scale because the free tier absorbs the overhead. Payload’s cost advantage grows as editor count rises — but only if you have the engineering capacity to maintain the stack. If you don’t, the developer time cost erases the subscription saving entirely.

The cost nobody budgets for: migration between platforms

If you choose the wrong CMS for your migration and need to switch eighteen months later, budget 40–120 hours of developer time for a CMS-to-CMS content migration depending on content complexity. Sanity’s NDJSON export is readable and complete, but GROQ queries and Portable Text don’t map directly to any other platform’s primitives. Payload’s SQL or MongoDB data is more portable by nature.

This is not a reason to choose either platform. It is a reason to make the decision carefully the first time.

Why we built Nexity on Sanity

We’ve been transparent throughout this post about the conflict of interest. Here’s the full version of it: we didn’t choose Sanity because we’d already decided to build a migration framework and needed to pick a CMS. We chose Sanity first, across multiple client projects, and built Nexity because of what those projects consistently taught us.

What is Nexity?

Nexity is Pagepro’s proprietary delivery system for migrating legacy web stacks to Next.js and Sanity. It’s two things simultaneously:

• An open-source starter kit — a production-grade Next.js + Sanity foundation that developers install and build on. Free, MIT-licensed, publicly available on GitHub.
• A migration system — the methodology, tooling, and service wrapper we use to take a client from their current stack to a modern headless architecture in a fixed-price, 4-week engagement.

It’s not a SaaS product. It’s not a generic boilerplate. Every pattern inside Nexity came from a real migration — which means every recurring problem we solved on a client project is now solved by default on every project that follows.

The decisions that led here

When we started doing replatforming work for Digital Native SMBs, the problems that came up most often were not technical in the narrow sense. They were operational.

• Content teams locked out of managing their own redirects
• Marketing managers raising dev tickets to update metadata
• SEO rankings dropping post-launch because redirect maps lived in spreadsheets, not the CMS
• Editors unable to preview content before publishing because live preview required custom infrastructure

Sanity solved the operational problems, not just the technical ones. That distinction mattered more than any feature comparison, and it’s what determined the foundation Nexity was built on.

What 20+ migrations actually taught us

The moments that determined whether a project succeeded or failed rarely happened in the codebase. They happened at handover.

When the editorial team sat down in the CMS for the first time. When the first post-launch redirect needed updating. When the Head of Marketing asked whether the rankings had held.

Sanity’s Studio consistently shortened the distance between those moments and a good outcome. Not because the technology is superior in every dimension — this post has been honest about where it isn’t — but because it is built for the people who live in a CMS after developers have left the project.

What Nexity adds on top

Nexity is not a Sanity reseller arrangement. It’s what happens when numerous migrations worth of recurring problems get solved once and embedded into a reusable delivery system.

When we’d recommend something different

If a prospective client came to us with a product application that needed a CMS and an application database in a single system, we would tell them to look at Payload. If they had dedicated DevOps and data residency requirements that ruled out managed SaaS, we would tell them Sanity is the wrong fit. We’ve had both conversations.

Nexity exists for a specific use case. So does this post.

If you’re migrating a content-heavy site with a small engineering team and an SEO ranking you cannot afford to lose — we’re confident Sanity is the right foundation. And if you want to see what that looks like in practice before signing anything, we can rebuild a section of your site using your real content in 48 hours.

That’s the honest version of why we built what we built.

Got it. Correcting the record on Nexity — it’s a proprietary system, not open-source, not on GitHub. Rewriting now with the accurate details.

Why we built Nexity on Sanity

We’ve been transparent throughout this post about the conflict of interest. Here’s the full version of it: we didn’t choose Sanity because we’d already decided to build a migration framework and needed to pick a CMS. We chose Sanity first, across multiple client projects, and built Nexity because of what those projects consistently taught us.

What is Nexity?

Nexity is Pagepro’s proprietary delivery system for migrating legacy web stacks to Next.js and Sanity. It is two things simultaneously, and the distinction matters:

• A production-grade starter kit — a Next.js + Sanity foundation built and refined across dozens real client migrations. Every pattern in it came from a live project with real content, real traffic, and real deadlines. None of it was designed in the abstract or optimised for a demo.
• A fixed-price, 4-week migration service — the methodology, tooling, and engagement model built on top of that foundation. Scope and price confirmed before any code is written. Delivery ends with a production-ready site, all content migrated, core journeys working, and editors trained

The decisions that led here

When we started doing replatforming work for Digital Native SMBs, the problems that came up most often were not technical in the narrow sense. They were operational.

• Content teams locked out of managing their own redirects
• Marketing managers raising dev tickets to update metadata
• SEO rankings dropping post-launch because redirect maps lived in spreadsheets, not the CMS
• Editors unable to preview content before publishing because live preview required custom infrastructure

Sanity solved the operational problems, not just the technical ones. That distinction mattered more than any feature comparison, and it’s what determined the foundation Nexity was built on.

What 20+ migrations actually taught us

The moments that determined whether a project succeeded or failed rarely happened in the codebase. They happened at handover.

When the editorial team sat down in the CMS for the first time. When the first post-launch redirect needed updating. When the Head of Marketing asked whether the rankings had held.

Sanity’s Studio consistently shortened the distance between those moments and a good outcome. Not because the technology is superior in every dimension — this post has been honest about where it isn’t — but because it is built for the people who live in a CMS after developers have left the project.

What Nexity ships by default

When we’d recommend something different

If a prospective client came to us with a product application that needed a CMS and an application database in a single system, we would tell them to look at Payload. If they had dedicated DevOps and data residency requirements that ruled out managed SaaS, we would tell them Sanity is the wrong fit. We’ve had both conversations.

Nexity exists for a specific use case. So does this post.

If you’re migrating a content-heavy site with a small engineering team and an SEO ranking you cannot afford to lose — we’re confident Sanity is the right foundation. And if you want to see what that looks like in practice before signing anything, we can rebuild a section of your site using your real content in 48 hours.

That’s the honest version of why we built what we built.

Which CMS should you choose?

Sanity and Payload are both serious, production-grade platforms. The comparison is not about which one is better in the abstract — it’s about which one is right for your specific situation.

If you’re a content-led team migrating a site with established SEO rankings, a non-technical editorial team, and no dedicated DevOps capacity, Sanity is the lower-risk, faster-to-value choice. The managed infrastructure, the editorial UX, and the migration tooling — redirect management in particular — are built for exactly that context.

If you’re an engineering-led team building a product application that needs a CMS and a database in one system, or if data residency requirements rule out third-party hosting, Payload is the more defensible long-term choice. The Figma acquisition changes the roadmap, but the open-source project is actively maintained and the technical fundamentals are strong.

The teams those two descriptions fit are different teams. If you’re reading this post because you’re planning a content migration and you’re not sure which platform to build on, the profile you’re likely in is the first one.

Ready to see what your site looks like on Sanity?

Before any contract is signed or scope is agreed, we rebuild a section of your site using Nexity — with your real content, on a live staging environment — in 48 hours.

No generic demo. No placeholder copy. Your actual pages, running on the stack we’re proposing, so you can evaluate the editorial experience and the technical foundation before committing to anything.

If you’re evaluating a migration to Next.js and Sanity, that’s the right place to start.

Talk to us about your migration →

FAQ