Prismic vs Payload

Prismic and Payload are both headless: the CMS stores content and a separate frontend renders the pages. They differ in who shapes that content and where the rules live. Prismic is a hosted CMS built around slices, the reusable page sections that developers define and marketers arrange in its visual Page Builder. Payload is an open-source TypeScript application that installs into a Next.js project, where collections, blocks and access rules are code in your repository.

This page compares Prismic’s current plans and tools, checked on 29 September 2026, with Payload 3. There is no WAYF migration guide for Prismic yet, so the Prismic migration page is the place to start if you decide to move.

The short decision

Stay on Prismic when marketers publish campaign pages from a slice library every week and the plan’s users, locales and API allowances fit. Prismic hosts and maintains the CMS, previews and releases work on every plan, and the frontend already renders slices.

Choose Payload when the content model and permissions should sit in your codebase, when content feeds an app or catalogue as well as pages, or when plan tiers would otherwise decide how many users, locales and roles you get. Payload can be hosted by your team, deployed from Vercel or Cloudflare templates, or hosted by Payload under an enterprise agreement.

Slice Machine is no longer maintained

Prismic now recommends the Type Builder and Prismic CLI instead of Slice Machine, which is no longer maintained, as Prismic explains in its announcement. The current workflow remains local and code-first: developers use the CLI and model JSON in the repository, while the Type Builder provides an optional visual surface in the browser. The CLI syncs models with Prismic, generates TypeScript types and writes component files. Existing Slice Machine projects still work, and npx prismic init migrates them.

For this comparison the change matters less than it sounds. Slices, page types and the Page Builder are the same. Slice Machine was a local app; the current workflow keeps model files in the repository and uses the CLI locally, with the Type Builder available as an optional browser editor.

Slices, blocks and the editor-developer handoff

A Prismic slice is a section with fields, optional variations and a screenshot that helps writers pick it. Developers write its component in the frontend, with adapters for Next.js, Nuxt and SvelteKit. Writers add slices to pages in the Page Builder, and live editing renders them through a slice simulator page on your website, so the preview uses your real components. Content relationship fields can pull fields from linked documents up to two levels deep.

Payload’s blocks field plays the same role. Each block type has fields, a label and an optional thumbnail for the admin’s block picker, and the frontend maps it to a component. Editors see drafts in Live Preview, rendered by your frontend. Developers can also replace or add React components inside the admin, from a custom field to a whole view.

The handoff works the same way on both: developers own the component library and marketers compose from it. On Prismic, a developer changes the local model files through the CLI, or uses the optional Type Builder and pulls the model into the project, then pushes the model and component changes; the Page Builder picks them up. On Payload, a model change is a TypeScript change deployed with the rest of the application. Payload lists a Visual Editor for its enterprise tier as coming soon; treat it as roadmap.

Releases, scheduling and roles

Releases are one of Prismic’s strongest features for marketing teams. A release bundles up to 200 new or changed pages, can be previewed as a whole on the website, and publishes on demand or at a scheduled time. Releases, scheduling and previews are on every plan. Unpublishing pages through a release is not supported.

Payload’s drafts give each document a draft, versions with restore, autosave and scheduled publish or unpublish, which run as background jobs, so the application needs a jobs runner. Scheduling is set per document. Coordinating a launch across many pages is something to design and test, for example by scheduling each page for the same moment.

Roles depend on the Prismic plan. On Starter and Small, every user is an Administrator. From Medium, users can be Writers, who create and edit pages and releases, or Publishers, who also publish. Custom roles per locale and space, and SSO, are Enterprise features. Payload’s access control is a set of TypeScript functions that can restrict a collection, a document, a field or an operation, and a rule can read the document’s own data. Multi-step approval is Payload’s enterprise Publishing Workflows or custom work.

Plans: users, locales, environments and allowances

Prismic prices per repository. On its pricing page, billed annually, the plans are:

• Free: 1 user, 2 locales, 4 million API calls and 100 GB of CDN bandwidth a month.
• Starter, $10 a month: 3 users and 3 locales, with CDN overages allowed up to 500 GB at $0.30 per GB.
• Small, $25 a month: 7 users and 4 locales.
• Medium, $150 a month: 25 users, 5 locales, user roles, 5 million API calls and 500 GB of CDN bandwidth.
• Platinum, $675 a month: unlimited users, 8 locales, 10 million API calls, 1 TB of CDN bandwidth, and a development environment as a paid option at $3,000 a year.
• Enterprise, by quote: custom quotas, two development environments, backups, custom roles and SSO.

Every plan includes unlimited documents, types, slices and assets, the Visual Page Builder, releases, scheduling and full revision history.

Payload has no plan tiers. The core is MIT-licensed, localization supports as many locales as the config declares, with fallback, and environments are separate deployments with their own databases. The costs move to hosting, the database, storage and development time. Publishing a document’s locales independently depends on a feature Payload labels experimental and in beta.

A campaign-page publishing exercise

Run the same launch on both platforms before choosing. The exercise is a script to follow with your own team; it reports no results.

The launch. A new campaign landing page, updates to two product pages and a homepage banner, in two languages, going live at 09:00 on a set day. One marketer builds, one reviewer approves, and a stakeholder outside the CMS signs off from a preview link.

On Prismic. The marketer builds the landing page from existing slices in the Page Builder and checks it in live editing. The homepage and product page changes go into the same release, with the landing page. The team previews the whole release on the website. For the stakeholder, check whether a shareable preview link, which opens without a Prismic login and expires, shows the release or a single page. A Publisher schedules the release for 09:00. On Starter or Small, anyone in the repository can publish, so the review step rests on the team’s own agreement.

On Payload. The marketer builds the landing page from blocks in the admin and checks it in Live Preview. The homepage and product pages are edited as drafts and each is scheduled for 09:00. The stakeholder reviews through the preview URLs your frontend provides for each document. Access rules decide who can publish; an approval step beyond that is enterprise or custom work.

What to record. Time from brief to scheduled launch, the number of people involved, every moment a developer was needed, whether the stakeholder could review everything in one place, and how the team would roll back a mistake at 09:05.

Leaving either platform

Leaving Prismic, the content is portable. Published documents come out as JSON through the Content API, assets through the Asset API, and the Prismic CLI pulls the models into your project. What gets rebuilt is everything tied to Prismic’s editing and delivery: slice components that read Prismic’s data shapes and helper packages, the preview routes and toolbar, live editing, releases, and image URLs served from Prismic’s CDN. Rich text arrives in Prismic’s structured format and needs converting for the next platform.

Leaving Payload, the content is in a database you control and the schema is in your repository. The work is rebuilding the content model, the admin and the access rules in whatever comes next; our guide to migrating off Payload covers that direction.

When staying on Prismic is the better call

Stay on Prismic when marketing owns the pace of the site, the slice library already covers the designs, and releases carry most launches. The hosted CMS, releases on every plan and previews tied to your own components suit a team that wants to spend its time on pages and leave the CMS to the vendor. If the only friction is roles, moving from Small to Medium is a smaller change than a replatform.

What a move to Payload rebuilds

A move re-implements the parts of Prismic that sit around the content. Plan for slices as block types, with their variations; the slice components, rewritten against Payload’s data; previews and Live Preview; the release and scheduling routine; roles and permissions as access rules; locales; image handling and URLs; and redirects for any path that changes. The Prismic migration page covers what running that move with WAYF involves.

Two decision scenarios

Both scenarios are illustrative. They are not client projects.

A campaign-led marketing site. A consumer brand runs its site on Prismic Small with a Next.js frontend. Five marketers publish campaign pages every week from a library of about 30 slices, in three languages, and most launches go out as scheduled releases. The recommendation is to stay. The workflow the team depends on, releases previewed as a whole and slices rendered by the real components, is Prismic’s core. If the team needs separate writer and publisher rights, Medium adds them. Payload would mean rebuilding the slice library, the previews and the release routine for no gain in how the team works.

A content model that outgrew the page builder. A software company’s Prismic repository has grown past pages: product data that its app also reads, a partner directory where each partner may edit only its own entries, and ten languages, which is beyond Platinum’s eight and into Enterprise pricing. The engineering team already maintains a Next.js monorepo. Payload fits. Partner access becomes an access rule that checks ownership on each document, the app and the site read the same collections, and ten locales are a line in the config. The move rebuilds the slices as blocks, the previews and the launch routine, so price those against the Enterprise quote.

A short evaluation checklist

Run these with your own repository before choosing:

• Slices. Count the slices and variations in use, and which pages use each.
• People. List who writes, who publishes and who approves, and compare that with the plan’s users and roles.
• Languages. Count the locales now and in two years, against the plan limits.
• Launches. Count how often launches span several pages, and how many pages the largest one touched.
• Environments. Decide whether model changes need a separate environment before production.
• Usage. Read the repository’s API calls and CDN bandwidth against the plan’s allowances.
• Campaign exercise. Run the exercise above on both platforms and compare the records.
• Exit test. Pull every published document through the Content API and list what your frontend would lose.

A note on our position

WAYF is an official Payload partner and top contributor, so we have an interest in this comparison. We recommend staying on Prismic when a marketing team’s weekly publishing depends on slices, releases and previews that already work.

If you choose Payload, WAYF’s Payload development service covers the build. For a move from Prismic, plan the replatforming around the slices, previews and launch routine that need to move.