Which CMS fits a team weighing Contentful against Wagtail
Choose Contentful if you want a managed SaaS with no servers to run and a JavaScript-first workflow, where your front-end and editorial tooling already live in the same ecosystem. Choose Wagtail if your team has strong Python and Django skills and you want the CMS code, database and media storage under your control. Neither answer is correct in the abstract. The decision turns on four questions: which language your team will maintain the platform in, where your content and personal data must physically reside, how complex your editorial workflow is, and who will operate the platform after launch.
Team skills matter more than feature lists. Wagtail's content modeling uses Django models and StreamField blocks, so editors and developers who write Python will be productive quickly, while a team of TypeScript developers may find the Django stack unfamiliar and need to hire or train for it. Data location is the second test. Contentful stores content in its hosted environment, so a residency rule may require you to confirm where its services process data. With Wagtail, the database and the media files sit wherever you deploy them, which makes residency questions easier to answer but moves backups, patching and storage capacity onto your team. Ask Contentful for its current hosting regions and data processing terms in writing before you rely on them.
Editorial workflow and operations close the decision. Wagtail includes content workflows and moderation, along with multi-site and multi-language support, so confirm that its approval chain and locale setup match your publishing process before you commit. Then name the owner for upgrades. Wagtail's release schedule publishes LTS versions with fixed support windows, which you should map against your own patch calendar, and Torchbox, Wagtail's primary sponsor, offers commercial support and hosting if you want a vendor behind the platform. Write down who handles on-call, backups and Django upgrades before you compare quotes, because those answers determine the true cost of owning the CMS.
Which option fits which scenario
This table matches common team and regulatory situations to the option that usually fits better, along with the condition that decides it. Read each row as a starting point: the condition column tells you what to verify in your own environment before choosing.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| Python or Django team that owns the backend | Wagtail | Wagtail is built on Django and runs on Django 5.2.x, 6.0.x or 6.1.x, so existing Python skills and deployment practices carry over. |
| JavaScript-only frontend team with no Python experience | Contentful | Contentful's hosted API and SDKs fit a JavaScript workflow without anyone maintaining a Python application server. Wagtail would add a new language to the stack. |
| Strict data residency or on-premises requirement | Wagtail | Wagtail runs in your own cloud account, data center or air-gapped network, so content and media stay where your policy requires. Confirm where Contentful stores your space's data against your residency terms. |
| Multi-site publishing with several domains | Wagtail | Wagtail includes multi-site support in its core feature set. Confirm the site-level permissions and page tree design you need, since multi-site setups affect how editors are grouped. |
| Multi-language publishing across many locales | Wagtail | Wagtail provides multi-language support, but translation workflow and locale fallback still need to be designed and tested against your editorial process. Contentful's locale model is already in use for many teams, so compare the workflows you actually need. |
| Team with no in-house operations or on-call capacity | Contentful | Self-hosting Wagtail means someone owns the database, upgrades, backups and media storage. If no one can take that on, a hosted service or a Wagtail support partner such as Torchbox should be priced into the decision. |
| Team that needs structured page layouts for editors | Wagtail | Wagtail's StreamField lets developers define structured blocks that editors arrange on a page. Confirm that your content model maps cleanly to pages and blocks before committing. |
How editors and developers work in each CMS
Contentful gives editors a hosted web app in which the content model drives the forms: content types define fields, and entries are created and edited against them. Wagtail works differently. Editors work in the Django admin, where the page tree defines the site structure, and each page type is a Django model whose body can be built from StreamField blocks that editors add, reorder and fill in. Workflows and moderation sit on top of that: a page can be drafted, submitted for review and approved by a moderator before publishing. The practical difference is that Contentful's model UI is a product your vendor maintains, while Wagtail's admin is code your team extends. Ask a Wagtail-leaning team to sit a non-technical editor in front of the admin with a realistic page and time how long it takes to publish a change before deciding how much custom block design is worth it.
Editor experience in either system depends heavily on what your team builds around it. Contentful's delivery is decoupled, so the editing app is only half the story; previews and layouts live in whatever frontend you connect. Wagtail renders pages through its own templates or through its headless API, so the preview, the block templates and the page tree labels are decisions your developers make. A poorly named StreamField block or an unclear page hierarchy will confuse editors whichever tool you pick. Plan a short onboarding for every editor either way, covering the publishing path, preview, and what happens when a change needs review. Confirm with the Wagtail team or Torchbox how preview and draft viewing are set up for your frontend before you estimate editor training.
The developer workflow also diverges. Contentful teams usually define content types in the web app or through its management tooling and consume entries through an SDK in JavaScript or another client language. In Wagtail, the models, blocks and templates live in your Django codebase, so schema changes go through code review, migrations and deployment, and the people maintaining them need Python and Django skills. Teams that already run TypeScript frontends can still use Wagtail, but they should expect a second language on the content side. Decide where the content model will be owned, by the platform team, by the frontend team, or jointly, because that choice determines who approves a new field and who gets paged when a migration fails.
Python versus JavaScript teams: who maintains what
A team that builds mainly in React, Next.js or another JavaScript framework usually consumes Contentful through its REST or GraphQL delivery APIs and an official SDK, so most of the integration code already lives in the frontend. Wagtail changes that picture: its content API is available, but the editorial model, page types and StreamField blocks are defined in Python, so a JavaScript-only team will depend on a Python-capable group for those changes.
- Frontend work: Wagtail's headless API returns JSON that a Next.js or other JavaScript frontend can fetch, so the rendering layer can stay in JavaScript.
- Backend ownership: Page models, StreamField blocks and API serializers are Django code, so someone with Python skills must own them.
- Contentful equivalent: Content types are edited in the web app and consumed through an SDK, while webhooks and space roles are managed by whoever administers the space.
- Hosting work: Running Wagtail means operating a Python process, a database and a search backend, which a JavaScript-only team may not have run before.
- Confirm: Name the Python-capable people who will maintain models and upgrades, and confirm they can take on Django release changes.
Before deciding, ask whether the Python-capable group has time to own the content model over the life of the site.
A team that already runs Django applications will find Wagtail familiar: it is built on Django, uses Django's ORM, templates and admin conventions, and follows the same deployment patterns. The main work is aligning the CMS with the Django versions your organization supports, because Wagtail publishes support for specific Django release lines and the team must keep both in step.
- Django alignment: Wagtail supports Django 5.2.x, 6.0.x and 6.1.x, so confirm which line your organization already runs before choosing a Wagtail release.
- Release cadence: Wagtail ships a feature release every three months and LTS releases that are supported for eighteen months, which sets the upgrade rhythm.
- Template or API frontends: You can render pages with Django templates or serve a separate frontend from the headless API.
- Contentful side: Under Contentful the team still integrates through SDKs and webhooks, and administers the space, but the platform itself is not theirs to upgrade.
- Confirm: Check whether the Django line you use matches a supported Wagtail release and who owns security patches for both.
Before deciding, ask how the team will test Wagtail upgrades against its existing Django applications.
Many organizations have a JavaScript frontend group and a separate backend or data group that works in Python. In a mixed team, Wagtail splits ownership along a clear seam: the Python group owns the CMS platform and content models, and the frontend group consumes the API or templates. Contentful splits differently, with the frontend group owning SDK calls and the platform or content operations group owning the space, webhooks and roles.
- Clear boundary: Define which group owns page models, API schema changes and the frontend contract before build starts.
- Shared responsibilities: Both groups share hosting, backups and incident response, which need a named owner.
- Change flow: Schema changes in Wagtail go through Python code review, while Contentful content model changes are made in the web app and need governance rules.
- Support path: Commercial support for Wagtail is available from Torchbox, the primary sponsor, which can cover parts of the Python side.
- Confirm: Agree in writing who approves model changes, who receives Django security notices and who is on call for the CMS.
Before deciding, document the handoff between groups so that a content model change does not stall waiting for the other team.
Where the content lives and who controls it
Contentful keeps your content in a vendor-hosted service, while Wagtail runs inside infrastructure you choose and operate. The cards below cover where data sits, what you must verify about the host, and which operational duties move to your team in each model.
Data location and hosting model
Contentful stores spaces, entries and assets in its hosted platform, so your data residency depends on the regions and hosting arrangements Contentful offers to your contract. Wagtail is a Django application that runs in the cloud account, data center or air-gapped network you specify, with the database and media files in the locations you pick. Ask Contentful in writing which regions hold your space data and where assets are delivered from, then map those answers against your residency obligations.
Hosting provider certifications
A self-hosted Wagtail deployment inherits the certifications of the cloud or colocation provider underneath it, and the provider's attestations do not automatically cover your application. Contentful will provide its own security documentation and attestation reports under agreement. For each option, request the current reports, confirm their scope and dates, and check that the services you actually use appear in that scope. DeployOpen does not issue attestations or certifications; your independent auditor makes that call.
Identity and access control
In Contentful, user roles, SSO and space permissions are configured in the vendor console, and the space export does not carry roles or permissions over. In Wagtail, editors, groups and permissions are part of the Django application, and login is usually connected to your own identity provider. Plan who administers accounts, how offboarding removes access from the database and any media storage, and where audit logs of publishing actions are kept.
Backups and restore responsibility
Contentful operates its platform, but the export tooling gives you a copy of published content, entries and assets, not a restore plan for its service. With Wagtail, you own backup of the PostgreSQL database, the media files and the deployment configuration, and you must test restores. Agree in writing with the vendor or implementation partner who runs backups, how often they run, where copies are stored and how long they are kept.
Patching, upgrades and uptime
Contentful applies platform updates on its own schedule, and availability terms sit in its service agreement. Wagtail releases follow a published schedule that mixes feature releases and LTS releases with defined support windows, so your team or partner must plan upgrades, Django compatibility and security patches. Choose the LTS line that matches your support horizon and decide who monitors uptime and responds to incidents.
What the BSD-3-Clause license and Torchbox support mean in practice
Wagtail is BSD-3-Clause, so the software itself carries no per-seat, per-request or per-site license fee. The license is free for open-source and closed-source use, which means your organization can run it internally, modify it, and build proprietary templates, blocks or integrations on top without publishing that code. Contentful's bill is different in kind: it scales with the plan, seats and usage, and those terms change at renewal. With Wagtail, the recurring costs move to the infrastructure you run (application hosting, PostgreSQL, object storage for images and documents, search and a CDN if you use one) and to whatever support or engineering time you buy. Ask your team to list each of those lines before comparing totals with a Contentful quote.
Torchbox is Wagtail's primary sponsor and offers commercial support and hosting, but that is a separate contract from the license. Buying Torchbox support does not change the software terms, and a hosting or support agreement does not come with the code. An implementation partner, such as DeployOpen, is a different choice again: it builds, hardens, migrates and operates the system in your environment, and it can work alongside Torchbox or without it. Decide early whether you want the vendor that maintains the project, a partner that delivers your build, or both, because each one covers a different part of the risk.
Before you sign anything with any provider, confirm the support terms in writing: response times and severity definitions, whether an SLA applies and what credits it offers, who handles Django and Wagtail version upgrades and when, and whether the provider gives any intellectual property indemnity. Also confirm where your data is processed if the provider hosts it, what happens to backups and exports on exit, and whether you can run the same code yourself if the relationship ends. Torchbox's own terms and the Wagtail repository are the starting points for these questions, and your legal and procurement teams should review the answers against your own requirements.
What Contentful and self-hosted Wagtail cost to own
What does Contentful cost each year once we are on a paid plan?
Contentful bills through a subscription plus usage-based charges, so the annual figure depends on your contract, not on a public list you can copy. Check your own order form and renewal notice for the base plan fee, included seats, and the usage meters that can add charges, such as API requests, asset bandwidth, asset storage, and environments. Ask your account team to show the overage terms in writing. Costs rise as traffic, asset volume, seat count, or environment count grows, and they can change at renewal.
What are the recurring cost lines for self-hosted Wagtail?
Wagtail's license is BSD-3-Clause and free to use, so the recurring costs are the infrastructure and the people who run it. The main lines are application hosting for the Django app, a PostgreSQL database, search (Elasticsearch or the PostgreSQL search backend), media storage for images and documents, a CDN for delivery, backups, monitoring, and developer and operations time for upgrades. Ask each provider for its own metered pricing and confirm the storage and egress terms in your target cloud or data center.
Which Wagtail costs are one-time and which recur?
One-time costs include discovery, the content model and StreamField block design, the migration of entries, assets, and locales, frontend build, redirect planning, and testing. Recurring costs include hosting, database and search services, media storage and CDN bandwidth, security patching, dependency updates, and on-call support. Wagtail ships a feature release every three months, and an LTS release is supported for eighteen months, so budget for regular upgrade cycles rather than a single upgrade. The Wagtail release schedule lists the current versions and support windows.
Does Wagtail's support cost money, and who provides it?
Wagtail is free to use, but commercial support is optional. Torchbox, the project's primary sponsor, offers commercial support and hosting, and implementation partners can also support a self-hosted deployment under a written scope. Support is the line that changes most with risk tolerance: a team with strong Django skills may need little external help, while a regulated team may want a fixed retainer for patching and incident response. Ask any provider what response times and coverage they commit to in writing.
How do developer and operations hours compare with a hosted CMS?
A hosted CMS moves the platform's uptime, patching, and scaling to the vendor, while your team keeps the frontend, integrations, and content modeling. With Wagtail, your team also owns the Django application servers, database backups, search index health, media storage, and security updates. The hours depend on how many environments you run, how much custom StreamField and API work you build, and whether you already operate Python services. Estimate these hours from your own staffing plan and ask an implementation partner to size them against a written scope.
What drives Wagtail's infrastructure costs up or down?
The largest drivers are traffic volume and cache hit rate, the number and size of images and documents, the number of sites and languages, search index size, and the number of environments such as staging and preview. Caching at the CDN and reducing image renditions usually lowers bandwidth and compute. Multi-site and multi-language setups add content and index volume, so model them early. Ask your cloud provider for a pricing calculator estimate based on your traffic and asset profile.
What should we ask for in a quote for a Wagtail migration?
Ask for a written scope that lists each deliverable: content model and StreamField design, export and import scripts, asset and locale handling, frontend build, redirect plan, environments, backup and restore testing, documentation, and handover. Ask which items are fixed-price and which are time-and-materials, what is excluded, and how change requests are priced. Request the post-launch options separately, including patch cadence, upgrade support for each Wagtail feature release, and any retainer terms. DeployOpen works from a written scope, and its quotes follow from that scope.
What a move from Contentful to Wagtail involves
The sequence below takes a Contentful space from a hosted export to a Wagtail site you run, with each phase closing on a check you can verify. Most of the effort sits in modeling content types as Wagtail pages and StreamField blocks, and in rebuilding what the export leaves behind.
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. Roles and permissions are not included, so record them separately from the Contentful settings screens before you start. The step is done when you have a complete archive, you have checked entry counts per content type against the Contentful web app, and you have a written list of roles, memberships and UI extensions to rebuild.
Map content types to Wagtail page models
Decide which Contentful content types become Wagtail page models, which become snippets or reusable models, and which fields become StreamField blocks for flexible body content. Map Contentful references to Wagtail foreign keys or page links, and note any rich text fields that need a conversion path. The output is a reviewed mapping document signed off by the content team and the developers, with each content type assigned a target model. Ask the implementation partner or Torchbox, if you engage them, to review the model design before code is written.
Build the Wagtail models and content API
Implement the page models, StreamField block definitions, locales and site structure in a Django project, then configure Wagtail's headless content API for the endpoints your frontend needs. Set up the search backend and image handling you plan to use. The step is complete when a test page for each content type renders in the Wagtail admin and returns the expected JSON from the API.
Import entries, assets and locales
Write import scripts that read the export JSON, create Wagtail pages and snippets in dependency order (referenced items first), upload asset files, and attach them to image and document fields with their focal points and alt text. Import each locale into the matching Wagtail locale structure. The check is a reconciliation report comparing counts and sample records per content type against the export, with failed rows logged for manual repair.
Rebuild roles, workflows and webhooks
Recreate editor, reviewer and admin access using Wagtail groups and permissions, and configure content workflows and moderation to match the approval steps you used in Contentful. Replace each Contentful webhook with an equivalent in your build or publishing pipeline, and recreate any custom editor extensions as Wagtail panels or admin customizations. The step closes when a test user for each role can perform only the actions the old role allowed, and each webhook fires in a staging environment.
Serve the frontend through the API or templates
Decide whether the existing frontend keeps consuming content through an API or whether the site moves to Wagtail templates, then connect the frontend, update preview and draft handling, and confirm caching behavior at your own CDN or proxy. Run both the old and new frontends against staging content and compare rendered output for a sample of pages. The step is done when the frontends match on the agreed test set and preview works for editors.
Plan redirects and cut over
Build a URL map from the old Contentful-driven paths to the new Wagtail page URLs, implement the redirects at the web server or application layer, and confirm that search engines and deep links resolve. Run a final content delta import at cutover and retire the Contentful space only after you have archived the export and checked the redirect coverage. The output is a redirect map with test results, a cutover runbook, and a retained archive of the Contentful export.
Questions buyers ask before choosing Wagtail over Contentful
How much does it cost and how long does a move from Contentful to Wagtail take?
No duration or fee is published for this move, so the answer depends on the drivers you can measure in your own space. The main ones are the number of content types, how much rich text and how many references need converting into StreamField blocks, the number of locales and sites, the asset volume, and how many integrations read from Contentful's API today. Costs are one-time for the migration itself and recurring for hosting, database and media storage, search, backups, and upgrade work. Ask any vendor for a quote built from a written scope that lists these drivers, and ask for each cost component to be priced separately.
Can our own team do the migration without outside help?
A team with Django and Python experience can run the migration in house, since Wagtail is BSD-3-Clause licensed and free for open and closed-source use. The risk lies in the parts that are easy to underestimate: mapping content types to page models, converting rich text, re-uploading assets, planning redirects, and rebuilding editor roles. Teams that have not run a CMS in production before often bring in an implementation partner for scoped parts of the work, such as the import pipeline or the hardening and backup setup, while keeping content modeling in house.
What skills does a Wagtail project need that a Contentful project does not?
Wagtail is built on Django, so the work needs Python, Django models and migrations, template or API serving, and basic database administration. Contentful projects usually need JavaScript or TypeScript for the frontend and familiarity with its web interface. Your team will also need to operate a database, the media storage, search (Elasticsearch or PostgreSQL), and deployment pipelines. Check which of these skills already exist internally before you choose between an in-house build and a partner-led one.
Can Wagtail replace Contentful's content modeling?
Wagtail covers most structured content needs through page models, StreamField blocks, and image focal points, which lets editors compose pages from typed blocks. It does not copy Contentful's content type builder or its reference model one to one, so content types become Django models and blocks defined in code. Confirm the model shapes you need, especially deeply nested references and multi-entity relationships, with a proof of concept against your largest content types before you commit.
How are roles and permissions rebuilt after leaving Contentful?
The Contentful space export does not include roles and permissions, so they must be recreated by hand. In Wagtail you define access through Django users, groups and page-level permissions, and you can configure content workflows and moderation for review steps. Write down who edits, approves and publishes each content area before you build, and test those rules with real accounts in a staging environment.
What does Torchbox support cover, and when do we need an implementation partner?
Torchbox is Wagtail's primary sponsor and offers commercial support and hosting, according to the Wagtail repository. Its published scope, response times and terms are set in its own agreement, so ask Torchbox for a written description of what its support includes. An implementation partner such as DeployOpen works on a fixed scope agreed in writing, covering planning, integration, hardening, backups, upgrades and documentation in your own infrastructure. The two options can be combined: a vendor for framework support and a partner for the environment and the migration work.
How is Wagtail upgraded, and how often do releases arrive?
Wagtail ships a feature release every three months, and an LTS release typically arrives once every four feature releases with eighteen months of support. Wagtail 7.4 LTS has security support until November 2, 2027, and Wagtail 8.3 LTS is scheduled for May 4, 2027 with support until November 6, 2028, according to the Wagtail release schedule. Plan upgrades around the LTS line, keep Django within the supported range (5.2.x, 6.0.x or 6.1.x), and budget the recurring test and upgrade work as an ongoing cost.
How DeployOpen helps evaluate and implement Wagtail
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Contentful vs Wagtail decision, we start with a written scope that tests whether Wagtail fits your content model, editors and hosting before any build begins.
How we scope
- Map your Contentful content types, locales and editor workflows to Wagtail page models and StreamField blocks in a written scope.
- Confirm which Contentful features your team relies on, such as roles, webhooks and preview, and agree how each will be handled.
- Agree in writing which Wagtail deployment model, Django version and search backend the engagement will target before work starts.
How we build
- Install Wagtail in your own cloud account, data center or air-gapped network, with the database, media storage and search backend you choose.
- Build the page models, StreamField blocks, workflows and multi-language configuration described in the agreed scope.
- Test editor workflows, API responses, redirects and asset handling against the Contentful export before content is loaded.
How we hand over
- Deliver documentation for the content model, deployment, backup routines, upgrade path and the Wagtail release cycle you will follow.
- Walk your Python and frontend teams through the codebase, editor training material and the operational runbook.
- Provide evidence of configured controls and backups so your internal or external assessors can review the environment.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover, scoped in writing.
- Plan Wagtail upgrades against its published feature and LTS release schedule, including support end dates for each release.
- Ask for a quote built from your written scope, which sets out the one-time migration work separately from any recurring retainer.
