Contentful vs Payload: which fits a team that wants to own its CMS
Choose Contentful if your team wants a hosted headless CMS with a mature editing experience and no database or media storage to operate. Choose Payload if you want an MIT-licensed CMS that installs into your own Next.js app, keeps collections in TypeScript code and stores data in a database you control. Usually the deciding factors are a renewal or pricing change, a data residency rule, or a wish to review schema changes in the same pull requests as the frontend. Payload fits teams already comfortable with TypeScript and Next.js. Contentful fits teams whose editors need polished workflows and whose platform team does not want to run infrastructure.
Contentful's hosted model covers the database, the APIs, asset delivery and the editing interface, so the operational work is largely with the vendor. Payload moves that work to you: you choose MongoDB, PostgreSQL or SQLite, you run the database and backups, and you decide where uploaded media lives and how it is served. Payload can deploy to Vercel, to Cloudflare Workers with R2 and D1, or be self-hosted anywhere, so confirm your storage and CDN path before you commit. Payload's built-in authentication lets you manage admin and customer users inside the CMS, which may reduce a separate identity dependency, but you should still confirm how roles and access control will map to your existing policies.
Before you choose, answer three questions. Who will run the database and media storage, and who is on call for them? How strong are your TypeScript and Next.js skills, since Payload's collections, hooks and generated types are code you will maintain? How much editorial workflow do you need, including approvals, scheduled publishing and multi-stage review? Payload has versions and drafts, localization and live preview, but confirm each editorial requirement against the current documentation. Also note that Payload's v4.0.0 beta line is in progress, so production plans should pin a stable release and confirm its release notes at the Payload GitHub releases page before scheduling a migration.
Which option fits which team situation
This table matches common team situations to the option that usually fits better, with the reason and where the other option is still reasonable. Read each row as a condition to check against your own team, not as a verdict on either product.
| Team situation | Better fit | Why |
|---|---|---|
| Next.js team where developers own the schema | Payload | Collections, fields and access rules live in TypeScript beside the frontend, so schema changes go through code review. Contentful can still fit if developers want a hosted model with less to operate. |
| Marketing-led team that needs a polished editor on day one | Contentful | Editors work in a mature hosted interface with established roles and workflows. Payload's React admin panel can be customized heavily, but that customization is engineering work you would own. |
| Regulated organization that must keep content in its own cloud account | Payload | Payload can run self-hosted on MongoDB or PostgreSQL inside your account, so content and media stay under your controls. Contentful remains reasonable if its hosting and data terms already meet your assessor's requirements. |
| Team with no database operations skills | Contentful | A hosted service removes database backups, patching and storage management from your staff. Payload is viable if you use a managed database service or an implementation partner to run it. |
| Team with an existing Next.js app and a small content model | Payload | Installing into the /app folder keeps one codebase, one deployment and one set of types. Contentful suits a team whose frontend is not Next.js or who prefers a separate content service. |
| Team that needs many non-developer editors with complex approval chains | Contentful | Hosted workflow and role features reduce the custom build work for editorial governance. Payload offers versions, drafts and field-level access control, but approval workflows are generally built by your team. |
| Team that wants no vendor-controlled content API | Payload | The content API is part of your application and runs on infrastructure you choose. Confirm which Payload features your chosen deployment target supports before committing. |
| Team that needs to rebuild content quickly with minimal engineering time | Contentful | Hosted spaces, the Contentful CLI export and existing integrations shorten the first months. Payload needs schema work and a migration script, which takes engineering time up front. |
How editors and developers feel the difference
Contentful gives editors a hosted web interface that the vendor maintains, so the editing surface changes when Contentful ships updates and does not depend on your release calendar. Payload takes a different route: its admin panel is a customizable React application that your team builds and styles inside the same codebase as the site. Payload's built-in features relevant to editors include the Lexical rich text editor, versions and drafts, live preview and a block-based layout builder. Those features cover much of the daily editing work, but the polish of a hosted product is not something this page can verify.
- Rich text: Payload uses the Lexical editor, so ask editors to test tables, embedded assets, links and custom blocks against the content they actually write.
- Drafts and versions: Confirm how publish, unpublish and version history behave for your approval steps, since Contentful's workflow features are not a one-to-one match.
- Live preview: Test preview against your real frontend route, including how it handles unpublished references.
- Admin panel: Budget time for React work if you want custom views, because the panel is code you own rather than settings you toggle.
- Editor hands-on test: Run a timed editing session with a few editors on both systems before deciding that the experience is comparable.
Before you move editors, run a hands-on test of the actual workflows on a staging copy of the content model.
In Contentful, content types are defined in the hosted space, and developers consume them through the delivery API and generated typings that follow that model. In Payload, collections, fields and hooks are written in TypeScript as part of the application. Payload generates TypeScript types automatically from those code-defined collections and fields, so the schema, the API and the frontend types come from the same source file. Changes to the model become pull requests that go through the same review and testing as the rest of the frontend.
- Schema in code: Collections and fields live in the repository, so schema changes are reviewed, versioned and rolled back like any other code change.
- Generated types: Payload produces TypeScript types from the collection definitions, which reduces drift between the CMS and the frontend.
- Hooks: Document and field hooks let you run logic on create, update and read, which replaces some Contentful webhook and extension patterns.
- Local development: Developers can run the CMS next to the frontend, but they also own the database setup for each environment.
- Migration effort: Contentful content types must be rewritten as Payload collections, so plan for the mapping work and for fetching data through Payload's API rather than Contentful's.
Review the generated types and the existing Contentful query patterns with your frontend team before estimating the rebuild.
Contentful is a hosted service, so your platform team typically manages integrations, environments and access rather than the CMS runtime itself. With Payload, the CMS runs as part of your Next.js application, which means your team owns the hosting target, the database, the media storage, backups and upgrades. Payload supports self-hosted MongoDB and PostgreSQL databases and can also deploy to Vercel or to Cloudflare Workers with R2 and D1. Payload's v3.91.0 release is dated October 15, 2026, and a v4.0.0 beta line is in progress, so upgrade planning should account for a major version change before it becomes stable.
- Hosting: Decide where the Next.js app runs and how it scales, since no vendor operates it for you.
- Database and media: Choose PostgreSQL or MongoDB and define how uploaded files are stored, backed up and served.
- Upgrades: Plan regular dependency upgrades for Payload and Next.js, and track the v4 beta path against your release schedule.
- Access and auth: Payload includes built-in authentication, so admin and customer accounts are managed in the CMS itself, which you must secure and audit.
- Support model: Ask for a written scope with your implementation partner covering on-call, patching and backup testing.
Confirm the upgrade policy, backup restore test and support scope in writing before you commit to a production cutover.
Contentful vs Payload capabilities, feature by feature
This table compares Contentful's hosted headless CMS with Payload, an MIT-licensed CMS that installs into a Next.js app. Where a Contentful detail is not covered by our research, the cell tells you what to confirm with Contentful, so you can check it against your own requirements. Payload's feature list should be verified against the version you plan to deploy before you commit.
| Capability | Contentful (hosted) | Payload (self-hosted) |
|---|---|---|
| Licensing | Commercial SaaS subscription; confirm plan terms and usage limits with Contentful | MIT licensed; no license fee for the software itself |
| Content modeling | Content types defined in the hosted web app; confirm how the model is versioned and promoted between environments | Collections and fields defined in TypeScript code and stored in your repository |
| APIs | Hosted content delivery and management APIs; confirm rate limits and API availability terms with Contentful | Auto-generated REST and GraphQL APIs from your collections, served by your own app |
| Localization | Locale management in the hosted space; confirm how many locales your plan includes | Built-in localization defined per field in the collection config |
| Drafts and versions | Entry states and publishing workflow in the hosted app; confirm workflow features on your plan | Built-in versions and drafts with live preview support |
| Rich text editing | Hosted rich text field type; confirm how embedded entries and assets are represented in the API | Lexical rich text editor, configurable within your admin panel |
| Access control | Roles and permissions in the hosted space; confirm granularity with Contentful | Field-level access control and document hooks defined in code |
| Built-in authentication | Editor accounts managed in Contentful; customer identity handled by your own system | Built-in authentication covers admin and customer users inside the CMS |
| Live preview | Preview of draft content in the hosted app; confirm integration steps for your frontend | Live preview supported, with a customizable React admin panel |
| Database options | Managed by Contentful; you do not choose the database engine | MongoDB, PostgreSQL or SQLite; you choose and operate the database |
| Deployment targets | Hosted by Contentful; confirm regions and data residency options with Contentful | Vercel, Cloudflare Workers with R2 and D1, or self-hosted anywhere |
| TypeScript type generation | Generated types depend on the SDK and tooling you use; confirm with Contentful | Types generated automatically from collections and fields |
| Feature list currency | Confirm feature availability by plan with Contentful at the time of purchase | Verify the stated feature list against the exact target Payload version before planning |
Who runs the database, media storage and uptime
With Contentful, the vendor hosts the content, the assets and the uptime, and your team manages the integration. With Payload, the organization chooses the database, the media storage and the hosting target, and each choice moves a set of responsibilities onto its own team.
Where the data lives
Contentful stores content and assets in its own hosted environment, so data location is set by the vendor's service terms rather than by your architecture. Payload runs against a database you select: MongoDB, PostgreSQL or SQLite. Your team decides the region, the network path and the encryption settings for that database. Confirm with your security team which regions and data residency commitments your regulators require before choosing the database.
Hosting target choices
Payload installs into a Next.js app and can be self-hosted anywhere, deployed to Vercel, or deployed to Cloudflare Workers with R2 and D1. Each target changes who patches the runtime, who scales it and where logs go. A managed platform reduces server work but may constrain database choice or file size. Document the chosen target in your architecture record and test failover before go-live.
Backups and restore
Contentful's space export captures the published content model, content and assets, but it is an export, not a point-in-time database backup. With Payload, backups are your responsibility: snapshots of PostgreSQL or MongoDB, plus a copy of media storage kept in step with the database. Schedule backups, store copies outside the primary account, and run a timed restore drill. Ask your hosting provider for its backup retention and restore procedure in writing.
Media storage ownership
Contentful serves assets through its own delivery infrastructure. Payload stores uploads wherever your deployment sends them, often a local volume or object storage such as an S3-compatible bucket or Cloudflare R2 on the Workers path. Assets are the part of a migration most often lost, so confirm who owns bucket permissions, lifecycle rules and CDN caching, and check that image URLs keep resolving after cutover.
Admin users and authentication
Payload includes built-in authentication, so admin and customer users are managed inside the CMS itself. Contentful manages editor roles and memberships in its own console. Under Payload, your team owns password policy, MFA enforcement, session lifetimes and the offboarding process for former editors. Decide whether single sign-on sits in front of the admin panel and who reviews access on a fixed schedule.
Compliance evidence and uptime
Moving the database, media and hosting in-house means your organization must produce the evidence auditors ask for, such as access logs, change records and backup test results. DeployOpen prepares these controls and evidence for assessments, but it does not issue audit reports, and independent auditors decide certification. Ask your auditor which controls they will test, and set an uptime target and an incident owner before cutover.
Contentful vs Payload cost: what you pay for instead of a subscription
Moving from Contentful to Payload replaces a recurring subscription with recurring infrastructure and people costs, plus a one-time migration. On the Contentful side, the subscription and the usage limits attached to it recur every billing period, and they scale with the plan tier, seats, content and asset volume and API usage that your current contract measures. Pull your own invoices and usage reports to see which limits you actually hit. No Contentful prices are given here, so use your contract as the baseline. On the Payload side, the software is MIT licensed, so there is no license fee. The recurring costs move to the places where Payload runs: application hosting for the Next.js app, a PostgreSQL or MongoDB database that you or a provider operates, object storage and a CDN for media, backups, monitoring, and developer time for upgrades. Payload is also deployable to Vercel or Cloudflare Workers with R2 and D1, and each of those choices carries its own metered bill.
Some costs are one-time and some recur, and mixing them up distorts the comparison. One-time work includes defining collections in code from your content types, scripting entries and assets into Payload through its API, rebuilding roles and access rules, setting up localization and live preview, retraining editors, and planning redirects. Recurring work includes database operations, storage growth, CDN egress, security patching, Payload version upgrades, and the engineering time that goes into collections, hooks and the admin panel as the content model changes. Cost drivers move in predictable directions: more content and larger assets raise storage and CDN bills, more locales multiply entry variants and field rules, more environments (staging, preview, production) multiply database and hosting footprints, and a larger team raises the access and review workload. Ask the partner which of these your own numbers push up.
When you request a quote from any implementation partner, ask for a fixed-scope estimate with each item separated: schema work per content type, import scripts, asset transfer, editor training, redirect mapping, hosting and database set-up, backup and restore testing, monitoring, upgrade windows, and optional support or retainer terms. Ask which assumptions the estimate depends on, such as content volume, number of locales and environments, and expected traffic. No price figures are supplied for this comparison, so treat any number you hear as unverified until it appears in a written scope with deliverables. Compare the recurring lines on both sides over the same period, and include the cost of the person who will own Payload upgrades after the project closes.
What a move from Contentful to Payload involves
The sequence turns a hosted Contentful space into a Payload project that your team owns, with content, assets and access rules checked against the source before any traffic moves.
Inventory the space, locales and integrations
List every content type, locale, editorial role, webhook, environment alias and consuming front end in the Contentful space. Your content owner and a developer who knows the current site should sign off on the list, since the export does not carry roles or permissions and those must be written down by hand. Done when every content type has a named owner and every consumer of the Contentful delivery API is identified.
Export the space with the Contentful CLI
Run the space export command from the contentful-cli to capture the published content model, entries, assets, locales, webhooks and editor interfaces as JSON, and download the asset files. The export does not include roles or permissions, so record those separately from the admin console. Done when the export files open locally, the entry counts match the Contentful web app, and the asset download has no gaps you have not explained.
Map content types to Payload collections in code
Rewrite each Contentful content type as a Payload collection or global with typed fields, relationships, and localized fields where the source uses locales. Payload generates TypeScript types from these definitions, so a Next.js developer will work in one codebase. Decide early which content will use the block-based layout builder and which will stay as plain fields. Done when a reviewer has signed off a mapping document that lists each source type, its Payload target and any field that changed shape.
Script entries and assets through the Payload API
Write an import script that reads the export JSON, creates media documents for the downloaded files, and creates entries through Payload's local or REST API in dependency order, so referenced entries exist before the entries that point to them. Rich text needs a transform into Payload's Lexical format, and links between entries need an ID map. Done when a repeatable script runs against a staging database and a spot check of rich text, references and localized fields matches the source.
Rebuild webhooks and access rules
Recreate the publish and unpublish triggers that Contentful webhooks used to call, using Payload hooks and your own build or revalidation endpoints. Define field-level and collection-level access control to match the roles you recorded in step one, and set up built-in authentication for admin and customer users if the site needs them. Done when a test publish triggers the same downstream rebuild as before and each role can only read and edit what it could in Contentful.
Set up drafts, versions and live preview
Enable versions and drafts on the collections that editors publish, configure live preview so editors see unpublished changes in the front end, and test scheduled or staged publishing against the workflow your editors actually use. Walk editors through the admin panel and confirm the custom fields display as intended. Done when a content owner completes a full edit, review and publish cycle on staging without developer help.
Choose and provision the database and media storage
Select MongoDB, PostgreSQL or SQLite based on your existing database skills, backup tooling and hosting plan, then provision the database and an object store or file system for uploaded assets in infrastructure your organization controls. Your team, or DeployOpen under a written scope, owns backups, restore tests and upgrades from this point. Done when a restore from backup has been tested into a separate environment and the asset store is reachable from the production front end.
Validate in parallel and cut over with redirects
Run the Payload site alongside Contentful for a defined validation period, comparing rendered pages, search results, and API responses for the same URLs. Build a redirect map for any URL that changes, load it into the new host, and switch DNS or the routing layer only after the content owner signs off. Keep the Contentful space read-only for a fallback window. Done when the validation report shows no unexplained differences and the redirect test passes for the sampled URLs.
Questions buyers ask before choosing Payload over Contentful
What does switching from Contentful to Payload cost, and who pays for it?
The switch has two cost groups: one-time work and recurring operations. The one-time work covers modeling collections in code, scripting content and assets into Payload, rebuilding the frontend integration, and testing. Your developers or an implementation partner are paid for that work, and the price follows from the written scope rather than from any tool fee. Recurring costs are the database, media storage, hosting, a CDN if you use one, and the engineering time to upgrade and patch. Ask any quote to separate these lines so you can compare them with your current Contentful subscription and usage charges.
How long does a Payload migration take, and what drives that time?
The duration depends mostly on the size and shape of your content model, not on the CMS itself. The main drivers are the number of content types and their references, how much rich text needs transforming, the volume of assets to re-upload, how many locales you publish, and whether editorial workflows, drafts and live preview must work on day one. Each driver adds planning, scripting and verification steps. No duration is fixed in this page, so ask for a scoped timeline in a written plan that lists these drivers against your actual Contentful space.
Can our own team run the migration without outside help?
A team with strong TypeScript and Next.js experience can do the work in-house, provided it has time for the modeling, scripting and editor training that a CMS change requires. The questions to answer honestly are whether anyone has built a Next.js application that talks to a database, whether someone owns the export and import scripts, and whether editors can test content before cutover. If those skills are thin, a fixed-scope engagement can cover parts of the work. DeployOpen plans, implements, integrates, hardens and documents self-hosted platforms in your own infrastructure, and it works from a written scope agreed before work starts.
What does Payload require from our developers and operators?
Payload installs into a Next.js /app folder, so developers need to be comfortable with TypeScript, React, Next.js routing and the chosen database. Operators need to run the chosen database, either MongoDB or PostgreSQL (SQLite is also supported), along with the media storage, backups, deployment pipeline, and monitoring. Collections and fields are defined in code, so schema changes go through version control and review rather than a web console. Ask your team to confirm who owns on-call support for the application, who applies Payload upgrades, and how database restores are tested before go-live.
Is Payload free to run, and what does it still cost?
Payload is MIT licensed, so the software itself carries no license fee to run it. You still pay for the infrastructure and the people who operate it. Those costs include the database service, file or object storage for uploaded assets, application hosting (Payload can deploy to Vercel, to Cloudflare Workers with R2 and D1, or be self-hosted anywhere), CDN bandwidth, and engineering time. Confirm with your hosting provider and storage vendor what those services charge at your expected volume, because those line items replace the Contentful subscription and usage charges rather than disappearing.
How does Payload's licensing differ from Contentful's terms?
Contentful is a hosted service that you use under its subscription terms, while Payload is MIT licensed software that you install and operate yourself. The MIT license permits commercial use, modification and redistribution with a notice, so your content model and application code are yours to keep. Contentful's terms govern your access to its hosted service, plan limits and data export. Have your legal team read the Contentful agreement for exit and data return terms, and read Payload's LICENSE file in the repository for the terms that apply to the version you deploy. Also check the licenses of any plugins or third-party packages you add.
Does the Payload v4 beta matter for a new build?
For a new build, plan on a stable release line rather than the beta. The Payload releases page shows v3.91.0 released on October 15, 2026, and a v4.0.0 beta line in progress, with v4.0.0-beta.2 published on October 16, 2026. Beta releases can change APIs and configuration before a stable v4 ships, so a production build on a beta carries upgrade risk. Ask your developers which version they will pin, what the upgrade path to v4 looks like, and whether the team has tested that path in a staging environment before committing to a timeline.
How DeployOpen helps teams evaluate and move to Payload
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Contentful vs Payload, we help you test whether a code-defined CMS fits your content model, editors and operating model before any content moves.
How we scope
- Inventory your Contentful content types, locales, roles, webhooks and asset volumes before choosing a database target
- Agree which environments, editors and integrations are in scope in a written, fixed-scope document
- Confirm whether PostgreSQL, MongoDB or SQLite fits your database standards and hosting constraints
- Define which Contentful features you need to keep, such as drafts, preview and localization, and how each maps to Payload
How we build
- Translate Contentful content types into Payload collections, fields and blocks defined in TypeScript code
- Install Payload into your Next.js app and configure access control, hooks and the admin panel to your editorial rules
- Script entries and assets into Payload through its API and test localization and live preview with your editors
- Run security testing on the application and API surfaces before the platform is exposed to production traffic
How we hand over
- Document the schema, deployment topology, backup routines and the database and media storage ownership model
- Provide a runbook for upgrades between Payload releases, including the v4.0.0 beta line if you choose to track it
- Set up backups for the database and uploaded media and test restore steps with your operations team
- Hand over the code repository, access records and the list of Contentful features that were rebuilt rather than carried over
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Retainer scope, response expectations and upgrade cadence are agreed in writing before work begins
- Ask us to confirm the support model for your own environment, including who owns on-call duties for the CMS
- Quotes follow from the written scope, and we do not publish a price list
