Which open-source Contentful alternative fits your renewal, residency or lock-in problem
If a Contentful renewal, a data residency requirement or lock-in is pushing you off the platform, the self-hosted options covered on this page are Strapi, Payload and Wagtail, and the right one depends on your stack and your team more than on any feature table. A team that already runs React or Next.js and writes TypeScript will usually find Payload a closer fit, while a team built around Python and Django will look first at Wagtail. Strapi sits in between, with a Node.js backend and a visual content builder, but its license needs a careful read before you commit.
Teams look for alternatives for three common reasons: a renewal that costs more than the team expected, a need to keep content and delivery inside a region or network the vendor does not operate in, or a growing dependency on one provider's APIs and tooling. The Contentful CLI space export is a useful starting point because it writes the published content model, entries, assets, locales, webhooks and editor interfaces to JSON and can download asset files. It does not export roles or permissions, so the lock-in risk sits in the operational rebuild rather than in the data. Before you sign anything, ask your team to list every role, webhook consumer and preview integration in use, and confirm which ones the export leaves out. Those are the items that will take the most effort to recreate.
Strapi, Payload or Wagtail: which headless CMS fits your team
Each option can replace Contentful's content modeling and API delivery on infrastructure you control, but they differ in license terms, language stack and how much of the editing experience you build yourself. The cards below set out the trade-off for each so you can match the choice to your developers, your database preference and your need for multi-site or multi-language editing.
Strapi Community Edition
Strapi is open core. The Community Edition is MIT licensed, but code in ee/ directories falls under the Enterprise Edition license unless you hold a signed agreement or a Strapi Cloud subscription. Before you commit, list every feature your editors need, such as SSO, audit logs, review workflows or granular roles, and confirm each one sits outside ee/ in the version you plan to deploy. Your Contentful roles will not carry over automatically, so map them onto Strapi's permissions during the schema work.
Payload on Next.js
Payload is MIT licensed and installs directly into a Next.js /app folder, so your content schema, access control and front end live in one TypeScript codebase. It supports self-hosted MongoDB and PostgreSQL, which lets you choose the database your operations team already runs and backs up. The trade-off is that your developers own more of the editing interface and front-end wiring, and your team must be comfortable with Next.js as the delivery layer.
Wagtail on Django
Wagtail is a BSD-3-Clause CMS built on Django, with multi-site and multi-language support and a headless content API. It suits teams that already run Python and Django and that need page trees, locales and editorial workflows as core features rather than add-ons. Commercial support is available from Torchbox, the primary sponsor, which matters if you want a contracted support path. Confirm that the Contentful locale fallback rules and your asset transformations map cleanly onto Wagtail's model before you commit.
Match the license to your review
Two of the three options carry permissive licenses that most legal teams accept without a copyleft review, but Strapi's split between Community and Enterprise code means the license check is feature by feature. Ask legal to review the exact edition and the directories your build will use, not the product name alone. Record the decision with the version you deploy, since feature placement can change between releases.
Choose by team skills and database
Pick the option your existing engineers can maintain for years. A JavaScript or TypeScript team leans toward Strapi or Payload, while a Python team leans toward Wagtail. Decide early between MongoDB and PostgreSQL if you are considering Payload, because that choice shapes backups, hosting and recovery testing. Ask your partner to prototype one content type with your real locales and assets before you lock in a schema.
How Contentful capabilities map to self-hosted options
This table compares how Contentful's content modeling, locales, assets, webhooks, editor interfaces, roles, environments and content APIs translate to Strapi, Payload and Wagtail. Read each row as a gap check: where a platform needs custom work or a separate decision, the cell says so. Confirm environment and preview behavior against each project's current documentation before you commit to a design.
| Capability | Strapi | Payload | Wagtail |
|---|---|---|---|
| Content modeling | Content types defined in the admin or code, mapped from Contentful content types by hand or script | Collections and globals defined in TypeScript config, so the schema lives in version control | Page models and snippets defined as Django models, so developers own the schema |
| Locales | Internationalization plugin covers per-field and per-entry locales; confirm it matches your Contentful locale fallbacks | Built-in localization configured per field, with locale fallback settings to verify during mapping | Multi-language support through Django i18n and locale-specific page trees; plan the tree structure early |
| Asset library and download | Media library stores files in the local filesystem by default; move to object storage with a provider plugin | Upload collections store files with configurable adapters for object storage; confirm the adapter for your cloud | Images and documents managed in the Wagtail admin; storage backends are set through Django settings |
| Webhooks | Lifecycle and event hooks exist in code, but Contentful webhooks are not exported and must be rebuilt as endpoints | Hooks run inside collection and global configs; external notifications need rebuilt endpoints | Signals and custom code trigger outbound calls; no export of Contentful webhook definitions, so rebuild them |
| Editor interfaces | Admin panel is configurable, but Contentful editor interface settings do not transfer and need manual rebuild | Admin UI is generated from the config and customized with React components | Admin customized through Python hooks and templates; Contentful editor layouts must be recreated |
| Roles and permissions | Role-based access is built in, but Contentful roles are not exported, so define each role again | Access control functions are written per collection and field, so every rule needs a fresh definition | Groups and permissions are set in the Wagtail admin with a page-level model; rebuild all roles from scratch |
| Environments and preview | Environment handling depends on deployment setup; confirm current preview support in the project docs | Draft and preview features exist, but environment separation is handled by your deployment pipeline | Page preview is built in; separate environments usually come from your hosting and database setup |
| Content API | REST and GraphQL APIs generated from content types; check the plugin version for GraphQL | REST and GraphQL APIs generated from the config, with typed outputs for TypeScript clients | Headless content API for pages and images; custom queries may need extra serializers |
| Hosting and database | Self-hosted on Node.js with a SQL database; you run backups and upgrades | Self-hosted in a Next.js app with MongoDB or PostgreSQL; you run backups and upgrades | Self-hosted Django application with a relational database; you run backups and upgrades |
Which option fits your team and stack
If your front end is already built on Next.js and your engineers are comfortable with TypeScript, Payload is usually the most natural fit. Payload installs directly into a Next.js /app folder, so the schema, access control and admin panel live in the same codebase as your site. Content types become code you review, test and deploy like any other change, which suits teams that want editorial models under version control.
- Co-located code: The CMS and front end share one repository, one build and one deployment pipeline.
- Database choice: Payload supports self-hosted MongoDB and PostgreSQL, so confirm which database your operations team already runs and backs up.
- License: Payload is MIT licensed, so the core carries no commercial restriction for internal or customer-facing use.
- Constraint: Your editors will work in an admin panel your developers maintain, so plan for developer time on every new content type or field.
- Migration mapping: Contentful content types translate into Payload collections and globals, and locales need to be configured up front.
Before committing, confirm with your team how your Contentful locales and preview workflows will be reproduced in the new front end.
If your organization runs Django or other Python services, Wagtail is the closest match to your existing skills and hiring pool. It is built on Django, so content models, permissions and deployment follow patterns your engineers already use. Its multi-site and multi-language features and headless content API let it serve both traditional templates and a separate front end.
- Framework fit: Developers extend Wagtail with ordinary Django models, templates and packages.
- License: Wagtail is BSD-3-Clause, a permissive license with no edition split to track.
- Multi-language: Confirm that the locale structure you need from Contentful maps cleanly onto Wagtail's language and site settings.
- Constraint: If your front end is a JavaScript single-page application, you will run two stacks and must design the headless API contract carefully.
- Commercial help: Torchbox is the primary sponsor and offers commercial support, which is worth weighing if your Python team is small.
Before committing, check whether your Contentful webhooks trigger builds or syncs that your Python services will need to replicate.
If your policy accepts only OSI-approved licenses, narrow the list to options whose core is clearly open source. Payload (MIT), Wagtail (BSD-3-Clause) and WordPress or Drupal (GPL) fit that rule for their core code. Strapi needs more review, and Directus should be treated differently.
- Strapi: The Community Edition is MIT, but code in
ee/directories is under the Strapi Enterprise Edition license unless you hold a signed agreement or a Strapi Cloud subscription. Have legal review which features you plan to use. - Directus: Directus is not under an OSI open source license. It uses the Monospace Sustainable Core License (MSCL-1.0-GPL), which bars competing use, allows internal use and converts each release to GPL-3.0 four years after release. Internal use may be acceptable, but it fails a strict open-source requirement.
- Plugins and themes: Confirm the license of every extension you install, since a permissive core does not cover add-ons.
- Dependencies: Review transitive packages in your Node.js or Python build, not only the CMS itself.
- Written position: Ask each candidate vendor for its license file and any commercial terms in writing.
Before committing, ask your legal team to confirm in writing which license terms apply to your intended deployment, including internal and public-facing use.
If your organization requires a contracted support agreement, service levels and a named escalation path, the options differ in how that support is sourced. Open-source software does not come with a vendor SLA by default, so you either buy support from the project's commercial sponsor or contract an implementation partner. Wagtail has a clear named sponsor offering commercial support through Torchbox. Strapi and Payload offer commercial plans, and Drupal and WordPress have large service ecosystems.
- Named sponsor: Wagtail's primary sponsor, Torchbox, provides commercial support, so ask it to define scope, response targets and exclusions in writing.
- Vendor plans: Ask Strapi and Payload which support tiers they sell and whether those tiers cover your self-hosted deployment.
- Partner support: An implementation partner can provide operational support for any option, but its scope and fees are agreed separately in its own written terms.
- Ecosystem depth: Drupal and WordPress have broad third-party support markets, which can help if you need many vendors to bid.
- Cost driver: Support pricing usually depends on deployment size, hours covered and response targets, so request a quote against your exact scope.
Before committing, confirm response times, what counts as a covered incident and who patches the platform when a security release ships.
What self-hosting Contentful alternatives costs over several years
This table separates the cost of staying on Contentful from the cost of running Strapi, Payload or Wagtail yourself, and marks each item as one-time or recurring. Read it as a checklist for requesting quotes: no prices are given because none were supplied, so the figures you gather from your own environment and vendors should replace every blank assumption. The main takeaway is that the largest recurring items on the self-hosted side are operations, patching and skills, which are easy to undercount.
| Cost component | Who is paid or who pays | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Contentful subscription | Contentful, under your current contract | Recurring | Seats, spaces, environments, locales and asset volume named in your order form. Ask for a renewal quote that lists each of these. |
| Hosting, database and storage | Your cloud provider or data center | Recurring | Content volume, number of environments, backup retention and asset size. Ask your provider to price a staging copy as well as production. |
| CDN and asset delivery | Your CDN or cloud provider | Recurring | Asset download volume and image transformations. Confirm which transformations you need before comparing bills. |
| Content model mapping | Implementation partner or your internal team | One-time | Number of content types, references and locales. Request a written mapping of each Contentful content type to the target schema. |
| Asset and entry migration | Implementation partner or your internal team | One-time | Asset file size, count of linked entries and the number of locales to migrate. Ask whether the scope covers missing or 401, 403 or 404 asset files. |
| Webhook and role rebuild | Implementation partner or your internal team | One-time | Number of webhooks and roles. The Contentful CLI space export does not carry roles and permissions, so these must be recreated by hand. |
| Upgrades and security patching | Your team or a support retainer | Recurring | Release cadence of the chosen framework, plugin count and how many environments must be patched. Ask for the patching scope in writing. |
| Support contract | Vendor or implementation partner | Recurring | Response expectations and hours. Confirm which tiers are offered by the vendor and by any retainer you consider. |
| Internal skills and on-call time | Your own payroll | Recurring | Team familiarity with Node.js, TypeScript or Python and the database you select. Budget for training and staff turnover, not just initial build. |
What you give up when you leave Contentful and how teams work around it
Leaving a hosted headless CMS moves several services from the vendor to your team. Each gap below is a capability you may use today without noticing, so confirm it against your current Contentful contract and configuration before you plan the cutover.
Hosted CDN and image delivery
Contentful serves published content and images through its hosted delivery layer. On a self-hosted Strapi, Payload or Wagtail stack, the API and media files sit wherever you deploy them, so you need a CDN in front of the API and an image transformation service or a media pipeline. Check your current cache hit patterns, image resizing usage and the regions your editors and readers are in before you size the replacement.
Managed uptime and backups
In a hosted SaaS, the vendor operates the database, failover and backups. Once you self-host, a managed PostgreSQL or MongoDB service, scheduled backups and a tested restore procedure become your responsibility. Ask who will own on-call response, what recovery point and recovery time your business needs, and whether your hosting provider's backup tooling meets it.
Roles and permissions rebuilt by hand
The Contentful CLI space export does not include roles and permissions, so access rules must be recreated from a written matrix rather than copied from the export. Map each Contentful role to a Strapi, Payload or Wagtail role, then test that editors can publish only in their locales and content types. Document this matrix as part of your access control evidence.
Webhook history and retries
Contentful webhooks are exported as configuration, but delivery logs, retry behavior and failure alerts belong to the hosted service. Your build triggers, search indexers and downstream syncs need a replacement queue or job runner that records each delivery and retries failures. Confirm which webhooks are business critical, and test a failed endpoint before go-live.
Vendor-managed upgrades
Contentful applies platform changes without a planned upgrade window from your team. Open-source CMS releases, Node.js runtimes and database versions are your schedule to maintain. Plan a patch cadence, a staging environment that mirrors production, and a rollback path for each upgrade, and ask any implementation partner for the scope of ongoing upgrade support in writing.
Editor UI polish and onboarding
Contentful's web app is a mature editing environment that many editors already know. Open-source admin panels differ in layout, preview features and how they handle localized fields, so expect a retraining period and some workflow changes. Run usability sessions with real content tasks, and list the editor features your teams use every day before you choose a CMS.
How to move Contentful content, assets and webhooks in phases
This sequence moves content, assets and integrations from Contentful to a self-hosted headless CMS in controlled stages, so each stage has a check before the next one begins. The result is a validated target schema, a tested import, and a cutover that you can roll back.
Inventory content types, locales and integrations
Your content architecture lead and a developer list every content type, field, locale, reference, webhook and editor interface in the space, along with the consumers that read from it (front ends, search indexes, build hooks, marketing tools). Roles and permissions are inventoried separately from the export, because the export does not include them. Done means you have a written list of content models, locales and downstream consumers that the team has signed off.
Export the space with the Contentful CLI
A developer runs the Contentful CLI space export command, which backs up the published content model, entries, assets, locales, webhooks and editor interfaces as JSON, and can download asset files. Store the export in a versioned, access-controlled location, and record the space ID, date and CLI version alongside it. Confirm the export against your inventory: entry counts per content type and the number of assets downloaded should match what the space shows. Note that unpublished drafts and some editorial state may need a separate check in the web app.
Map content types and locales to the new schema
A content architect maps each Contentful content type to a collection or model in Strapi, Payload or Wagtail, and each field to a field type with the same validation rules. Locales are mapped to the target's localization settings, and fallback chains are written down explicitly. Keep a mapping document that lists each source field, target field, transformation and owner. Done means a reviewer has checked every type against the mapping document and no field is left unassigned.
Transform the JSON and asset files
Developers write an import script that reads the exported JSON, resolves links between entries, converts rich text and locale-specific values, and uploads asset files to your own storage. Rich text and reference fields usually need the most work because Contentful's structure does not map one to one onto every target. Run the script against a copy of the export, not the live target. Done means a sample of entries, including nested references and each locale, renders correctly in a test front end, and the asset URLs resolve.
Rebuild roles, permissions and webhooks
Roles and permissions are not in the export, so administrators recreate them by hand in the new CMS from the inventory, then test each role with a named account. Webhooks are not carried over as working endpoints: developers re-register each one against the new CMS endpoints, update the signing secrets, and point build hooks and search indexers at the new delivery API. Done means each role can perform only its intended actions and every downstream consumer receives a test event from the new system.
Run a pilot with one content area
Choose one content area with moderate volume and a clear owner, then move it into the target and have editors create, edit, publish and schedule content there for a defined test period agreed by the project team. Measure what editors report: missing fields, broken previews, slow asset loading and unclear permissions. Done means the pilot owner signs off on the defect list, and every blocking issue has been fixed and retested.
Operate in parallel, then cut over
Run both systems for the agreed period, with a clear rule for which system holds the authoritative copy of each content type while editors work. Re-run the import for changed content so the two copies stay aligned, and compare published output from both front ends. For cutover, freeze editing in Contentful, run a final export and import, switch delivery and webhooks to the new endpoints, and keep the Contentful space read-only as a fallback. Done means the production front ends serve the new CMS and a documented rollback plan has been tested.
Decommission Contentful after verification
Once the new system has run in production without content or delivery issues for the agreed period, archive the final Contentful export and asset files in your own storage, revoke API keys and webhooks, and cancel or reduce the subscription according to your contract terms. Confirm the retention requirements for the archived export with your compliance and legal teams. Done means the archive has been verified by restoring a sample entry and asset, and the decommission record is signed by the system owner.
Questions buyers ask before moving off Contentful
How much effort does moving off Contentful usually take?
The effort depends mostly on how complex your content model is, not on the number of pages alone. A migration is driven by the count of content types and their references, the number of locales that must be preserved, the volume and state of assets, and the integrations that read from or write to Contentful. A space with a few content types, one locale and a small asset library is far simpler than one with deeply nested references, many locales and custom editor interfaces. Ask the implementation partner to inventory each of these four factors before agreeing on a scope, since they set the size of the work more than anything else.
What skills does the internal team need for a Contentful migration?
Most migrations need three skill sets working together. Someone must design the new schema in Strapi, Payload or Wagtail, which means translating content types, fields and locales into the target model. Front-end developers must rebuild the templates or API consumers that currently read Contentful's delivery API. DevOps or platform engineers must host the database, object storage, backups and deployment pipeline inside your environment. Content owners also need to validate migrated entries. Confirm early which of these roles your team covers and which you need an outside partner to fill.
Can our own engineers run the Contentful migration without a partner?
Yes, a capable internal team can run the migration, provided it has time, a clear schema plan and someone who owns the cutover. The Contentful CLI space export produces JSON for content types, entries, assets, locales, webhooks and editor interfaces, and the asset files can be downloaded, so the raw material is available. The harder parts are mapping that JSON into the new schema, reconciling references and rebuilding roles, which the export does not include. If those tasks compete with ongoing product work, a fixed-scope engagement with DeployOpen can cover planning, implementation, hardening and documentation while your team keeps ownership of the content.
How are Contentful roles and webhooks rebuilt after export?
Roles and permissions are not included in the Contentful space export, so they must be designed again in the new system. Start by listing who edits, publishes and administers each content type and locale, then map those groups to the access controls in Strapi, Payload or Wagtail. Webhooks need separate handling. The export includes webhook definitions, but the receiving endpoints, secrets and retry behavior must be recreated and tested against the new platform. Plan a parallel run where events from both systems are compared before you switch publishing traffic.
How does licensing differ between Strapi, Payload and Wagtail?
The licenses are not interchangeable, so read them before you commit. Strapi is open core: its Community Edition is MIT licensed, but code in the ee/ directories falls under the Strapi Enterprise Edition license unless you hold a signed agreement or a Strapi Cloud subscription. Payload is an MIT-licensed CMS that installs into a Next.js app folder. Wagtail is licensed under BSD-3-Clause and offers commercial support through its primary sponsor, Torchbox. Ask your counsel to confirm which parts of the chosen platform you will run, because the license that applies depends on the directories and features in use.
What should we request in a fixed-scope quote for this migration?
Ask for a written scope that lists the content types, locales, asset volume and integrations in the migration, along with the target platform and hosting environment. The quote should separate one-time work, such as schema mapping, data transformation, front-end rebuild, role and webhook design, testing and cutover, from recurring work, such as hosting, backups, upgrades and support retainers. Request the deliverables, the acceptance criteria for migrated content, the handover documentation and the assumptions your team must meet. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so every quote should trace back to that written scope.
What changes for your editors, developers and security team after the move
The biggest change is who operates the content platform. On Contentful, the vendor runs the database, backups, patching and the delivery infrastructure. After the move, your team owns those tasks for Strapi, Payload or Wagtail, whether the stack runs in your cloud account or your data center. Decide before cutover who is on call for the database, who applies framework and dependency updates, where the application and database logs are shipped, and how long those logs are kept. Confirm with your hosting provider what backup and point-in-time recovery options exist for the database you choose, and test a restore rather than assuming one works.
Editors and developers will feel the change in preview, API access and roles. Contentful's preview and delivery endpoints will be replaced by your own, so every front end that reads fields or sys data from Contentful needs its client and query shape reviewed against the new API. Roles and permissions are not part of the space export, so the access model must be rebuilt by hand: map each Contentful role to a Strapi, Payload or Wagtail permission set, then have editors test publishing, drafts and locale access in a staging copy. Webhook replacements, such as build triggers for your static or server-rendered site, also need an owner and a test.
Your security and compliance team will need evidence that the new controls exist and work, not just a description of the stack. Ask for a written inventory of the systems, administrator accounts, service credentials, network paths and backup locations, plus the procedures for access reviews, patch windows and incident response. Collect configuration records, change history and access logs for the administrative interface and database. Independent auditors, not DeployOpen or the software vendors, assess whether those controls meet a framework you are reporting against, so confirm early which assessment your organization needs and what that auditor will ask to see.
How DeployOpen scopes, migrates and supports a Contentful replacement
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Contentful replacement, we start from a written scope and run the move as a set of agreed deliverables, from content model mapping through handover and ongoing support.
How we scope
- Inventory every content type, locale, editor interface, webhook and role in the Contentful space before choosing a target platform.
- Agree in writing which platform (Strapi, Payload or Wagtail) fits your editorial model, hosting constraints and licensing position.
- Fix the scope, deliverables and timeline in writing before work starts, since most engagements are fixed-scope.
How we build
- Map Contentful content types and locales to the new schema, and move the space export JSON and asset files into the target database.
- Rebuild webhooks, roles and permissions by hand, because the Contentful export does not carry roles and permissions across.
- Test content fidelity, asset links, locale fallback and publishing workflows against the source data before cutover.
How we hand over
- Document the target schema, deployment, backup routines and the mapping decisions made for each content type and locale.
- Deliver runbooks for editors and administrators covering roles, publishing and webhook behavior in your environment.
- Provide the evidence and configuration records your internal or external auditors may ask for, without issuing any audit report ourselves.
How we support
- Offer ongoing support, upgrades and continuous security testing as a retainer after the platform goes live.
- Schedule upgrades of the CMS framework and its dependencies, with backups taken before each change.
- Ask us to confirm the support boundaries, response expectations and retainer terms in the written agreement before signing.
