Wagtail vs django CMS: when each one fits a Django content team
A team that has already standardized on Django and needs a CMS it can self-host will find two BSD-3-Clause options in the same ecosystem: Wagtail and django CMS. Both are free for open and closed-source use, so the decision turns on how the platform shapes content and the work around it, not on license cost. Choose Wagtail when editors need structured content built from blocks, since its StreamField model, content workflows and moderation, and multi-site and multi-language support all ship in core. Choose Wagtail as well when the same content must reach a separate front end, because its headless API is part of the core package rather than a separate add-on. Wagtail ships a feature release every three months and an LTS release about every four feature releases, with Wagtail 7.4 LTS supported until November 2, 2027 according to the Wagtail release schedule.
Choose django CMS when editors should work directly on the rendered page. Its front-end inline editing, placeholder and plugin system, and hierarchical page tree suit teams whose editors think in pages and want to place plugins into layout regions. Content versioning, editorial workflows and headless setups come from official add-on packages rather than the core, so a team that needs those capabilities should budget for the add-ons and confirm their support status with the django CMS Association. django CMS 5.0.x on Django 5.2 has LTS until March 2028, and 6.0.x on Django 6.2 is planned with LTS until March 2030, according to the django CMS documentation.
The decision turns on four questions. First, the editorial model: blocks in a stream, or plugins in placeholders on a page. Second, versioning needs: check whether Wagtail's core workflow tooling meets your approval chain or whether django CMS add-ons must be installed, tested and maintained. Third, headless requirements: confirm the API fields and access controls each platform would expose to your front end. Fourth, the Django upgrade path: map each CMS's supported Django versions, including Wagtail's support for Django 5.2.x, 6.0.x and 6.1.x, against your own Django schedule before you commit to either.
Which scenario favors which platform
This table maps common Wagtail and django CMS scenarios to the platform that usually fits better and the condition that makes it true. Read each row as a starting hypothesis, since add-ons, team Django experience and your editorial model can shift the answer. Confirm the fit for your own content with a proof of concept before committing.
| Scenario | Better fit | Condition and what to confirm |
|---|---|---|
| Structured editorial content with reusable blocks | Wagtail | Wagtail's StreamField suits pages built from typed, reusable blocks. Confirm that editors can work within the block definitions you plan to build. |
| Page-builder style marketing sites with many layouts | django CMS | django CMS's placeholder and plugin system and front-end inline editing suit editors who place components directly on the page. Confirm the plugin set covers your layouts. |
| Multi-site and multi-language estates | Either, depending on editor workflow | Both list multi-site and internationalization support. Test how each handles your language fallbacks and site-level permissions in a proof of concept. |
| Headless front ends with a separate JavaScript team | Wagtail | Wagtail includes a headless API in the core. With django CMS, headless setups come from official add-on packages, so budget time to evaluate and maintain them. |
| Content versioning and revision history | Wagtail, with core workflows | Wagtail includes content workflows and moderation in the core. django CMS provides versioning through add-on packages, so confirm which package and version match your Django release. |
| Teams that need a fixed upgrade window | Wagtail, if on LTS | Wagtail 7.4 LTS has security support until November 2, 2027, and LTS releases come about every four feature releases. django CMS 5.0.x LTS on Django 5.2 is supported until March 2028, so match the LTS line to your Django plan. |
| Teams with an existing django CMS codebase | django CMS | Migrating a working django CMS site has a cost that usually outweighs the gain. Keep the platform unless a specific requirement cannot be met. |
How each platform is built and what that means for operations
Wagtail and django CMS both sit on Django, but they make different choices about how content is modeled, searched, exposed to other systems and edited. Each card below names one of those choices and the operational work it creates for a team that will run the platform itself.
Content model: StreamField or placeholders
Wagtail stores page body content in StreamField, a typed set of blocks defined in Python that the database holds as structured data. django CMS places content into placeholders on templates and fills them with plugin instances. For a self-hosting team, StreamField means block schema changes are code migrations that developers must ship and test, while plugin-based content means editors can add plugins without a deployment but the team must track plugin versions and their data. Ask which model fits your editors' workflow before committing to templates.
Page tree and multi-site structure
Both platforms organize pages in a hierarchical tree and support multiple sites and languages, which lets one installation serve several brands or regions. The operational question is how many sites and locales share one database, one cache and one release cycle. A single shared instance simplifies upgrades but couples every site to the same Django version and add-on set. Separate instances isolate risk but multiply patching, backups and monitoring. Confirm how each platform's internationalisation and site configuration map to your content governance before deciding on one installation.
Search backend: Elasticsearch or PostgreSQL
Wagtail integrates search with either Elasticsearch or PostgreSQL. PostgreSQL keeps the stack smaller, since the team already operates the database for content, but search features and relevance tuning are more limited. Elasticsearch adds a second stateful service with its own cluster sizing, index rebuilds and version upgrades. Identify which search features your site needs, then confirm with the Wagtail documentation which backend supports them and what operating load each one adds. Django CMS search depends on its add-ons and the search setup your team chooses, so verify that during scoping.
Headless API built into Wagtail
Wagtail ships a headless API in the core project, so the same page and image data can feed a separate front end without an extra package. That reduces the number of components your team must version and secure. Django CMS handles headless delivery through official add-on packages instead of core, so the team must confirm which add-on version pairs with the CMS version in use and who maintains it. Before choosing either, list the front ends that will consume content and check whether each one needs an API that the core project provides.
Front-end editing and editorial workflow
django CMS offers front-end inline editing, where editors change content directly on the rendered page. Wagtail uses a separate admin interface with content workflows and moderation built into the core. Inline editing can speed up page-building for marketing teams, but it depends on template structure and add-on compatibility after each upgrade. Wagtail's workflow features reduce the need for extra packages when approval chains are required. For either platform, test the editor experience with real approval steps and confirm which versioning and workflow features come from core and which come from add-ons.
Capabilities, licensing and support windows compared
This table sets Wagtail and django CMS side by side on license, current release lines, LTS windows, Django and Python support, and whether editing, workflow, headless and versioning features ship in the core or as add-ons. Where a cell says to confirm, the supplied research does not settle the point, so check the current documentation before you commit. Both projects are BSD-3-Clause, but their LTS timelines and add-on boundaries differ.
| Capability | Wagtail | django CMS |
|---|---|---|
| License | BSD-3-Clause, free for open and closed-source use | BSD 3-Clause, per the project README badge |
| Current release lines | Wagtail 8.0 (August 25, 2026) and 7.4 LTS (May 4, 2026) | django CMS 5.1.3 (September 23, 2026) and 5.0.13 (September 24, 2026) |
| LTS policy | Feature release every three months; LTS about every fourth release, supported for 18 months | Follows Django's LTS policy; 5.0.x supported until March 2028, 6.0.x planned until March 2030 |
| Supported Django versions | Django 5.2.x, 6.0.x and 6.1.x | Django 5.2, 6.0 and 6.1 for the 5.1.x line |
| Python support | Confirm the supported Python range in the current Wagtail documentation | Python 3.10 to 3.14 for the 5.1.x line |
| StreamField and page structure | StreamField for structured content, included in the core | Placeholder and plugin system with a hierarchical page tree, included in the core |
| Workflows and moderation | Content workflows and moderation included in the feature set | Editorial workflows come from official add-on packages |
| Headless API | Built-in headless API | Headless setups come from official add-on packages |
| Versioning and search | Integrated search with Elasticsearch or PostgreSQL; confirm revision history in the docs | Content versioning from add-on packages; confirm search backends in the django CMS docs |
What is free, what is an add-on and what is paid
Wagtail is BSD-3-Clause licensed and free for open-source and closed-source use, so you can self-host it, modify it and ship proprietary sites built on it without a license fee to the project. The core already includes the features many teams look for first: StreamField for structured content, multi-site and multi-language support, a headless API, integrated search, image focal points and content workflows with moderation.
- No license fee: the BSD-3-Clause terms apply to the core you deploy, with no paid edition gating those features.
- Built-in capabilities: StreamField, workflows, moderation and the headless API ship in the core rather than in add-ons.
- Search backends: integrated search works with Elasticsearch or PostgreSQL, and each backend adds its own hosting and operating work.
- Supported Django versions: the core supports Django 5.2.x, 6.0.x and 6.1.x, so the Django version you can run is set by the Wagtail release you choose.
- Release cadence: feature releases arrive every three months, and LTS releases are supported for eighteen months.
Confirm your own staffing and upgrade plan, since the license cost is zero but the engineering time to patch and test each release is yours unless you contract it out. Check the Wagtail release schedule before choosing a version.",
Wagtail's license is free, but Torchbox, Wagtail's primary sponsor, offers commercial support and hosting. These are paid services you contract for, separate from the open-source project. They matter most when your team wants a named vendor to answer for production issues, or when you prefer not to run the hosting stack yourself.
- Commercial support: a contracted support agreement defines response expectations, scope and escalation paths, which the open-source project does not provide.
- Hosting: managed hosting shifts server patching, backups and environment operations to the provider, while you keep responsibility for content and configuration.
- Scope of the contract: ask whether support covers custom code, third-party packages and your Django upgrades, not only the Wagtail core.
- Exit terms: check data export, hosting location and what happens to your environment if you move it in-house later.
- Alternatives: a DeployOpen engagement can also cover implementation, hardening and upgrades inside your own infrastructure, scoped in writing.
Ask Torchbox or any other provider for a written scope and pricing basis before you compare costs, because the quote drives the real total of ownership.",
The django CMS core is also BSD 3-Clause licensed, as shown by the badge in the project README, so the core itself carries no license fee. The core provides internationalization, multi-site support, front-end inline editing, a placeholder and plugin system, rich-text editor integrations and a hierarchical page tree. Versioning, editorial workflows and headless setups are not part of that core, and you add them through official add-on packages.
- Free core: the BSD 3-Clause license covers the core, so the license cost of the base system is zero.
- Plugin model: placeholders and plugins give editors page-building flexibility that you configure and maintain yourself.
- Editorial features: content versioning and editorial workflows come from add-ons, not the core.
- Headless delivery: headless setups also come from add-ons, so your API design depends on which package you adopt.
- Support model: the django CMS Association maintains the project as a non-profit, and its release line includes LTS versions.
Check the license of each add-on, which can differ from the core, and review its maintenance status and last release before you depend on it.",
Versioning, editorial workflows and headless setups are the capabilities most teams need to verify, and django CMS delivers them through separate official add-on packages. Each add-on has its own release history, Django compatibility and maintenance commitments, which means your effective platform is the core plus every add-on you run. Treat the add-on set as part of your architecture rather than a footnote to the core license.
- Versioning: confirm which package provides page versioning, how it stores revisions and whether it supports your Django version.
- Workflows: confirm how approval steps, roles and publishing rules are configured and how they are tested.
- Headless: confirm which package exposes content over an API, its authentication model and its supported serialization.
- License per package: each add-on may use its own license, so record it alongside the core license in your bill of materials.
- Maintenance status: review the last release, open issues and Django version support for every package before you commit.
Check these packages against the django CMS documentation and each package's repository before you finalize the platform choice, and budget engineering time for testing them together on each upgrade.
Both cores are free to download and run, so the recurring costs come from people and infrastructure: engineers who patch and upgrade, hosting, search services, and any paid support or add-on subscriptions. The total depends on which hosting model you choose and how much of the operating work you keep in-house. Ask every vendor and partner to put these components in writing so you can compare like with like.
- In-house operations: salaries or contractor time for upgrades, security patches, backups and monitoring recur every year.
- Infrastructure: servers or cloud resources, search backends and databases scale with traffic and content volume.
- Paid support: a contracted support or hosting agreement recurs, and its scope determines how much you still operate yourself.
- Add-on subscriptions: any paid add-on or support tier adds a recurring line item to the budget.
- One-time work: initial implementation, migration and integration are usually one-time costs, and they vary with scope.
Request a quote that lists the scope, deliverables, support hours and what is excluded, so you can compare Wagtail and django CMS on the same basis.
How LTS windows and Django versions shape upgrade planning
Start with the Django version your organization can actually run, because it caps both platforms. Wagtail ships a feature release every three months, and an LTS release typically arrives about once every four feature releases with eighteen months of support. Wagtail 7.4 LTS, released May 4, 2026, has security support until November 2, 2027, and Wagtail 8.3 LTS is scheduled for May 4, 2027 with support until November 6, 2028. Wagtail 8.0 was released on August 25, 2026. Wagtail currently supports Django 5.2.x, 6.0.x and 6.1.x, so a Django upgrade on your side can force a Wagtail upgrade on the same timeline.
django CMS follows Django's LTS policy rather than a fixed cadence of its own. According to the django CMS documentation, the 5.0.x line on Django 5.2 has LTS until March 2028, and 6.0.x on Django 6.2 is planned with LTS until March 2030. The 4.1.x LTS ended in March 2026, so any site still on it is already past its security window. Confirm the current LTS table in the django CMS documentation before you commit, because a planned line is not a guaranteed one. Ask whether your team would track django CMS minor releases, which Django version each one pins, and whether a Django major upgrade is expected inside the window you plan to run.
Upgrades are where effort accumulates, so plan the calendar before the build. Map each platform's support end date against your Django upgrade date, then budget for the custom StreamField blocks or plugins, third-party packages and any django CMS add-ons that must move with it. Ask a partner to estimate those tasks in a written scope, including test coverage for editorial workflows and search. Both projects publish their support windows, so the decision you are making is which upgrade cadence your team can sustain for the life of the site, not which platform is newer.
What makes moving between them expensive
Moving a site from Wagtail to django CMS, or the reverse, rarely fails on the framework itself. The cost sits in the content model, the templates, the search index, the editorial workflow and the URLs that already rank and receive traffic. Each card below separates what carries over from what has to be rebuilt.
Content model and StreamField mapping
Wagtail stores pages as StreamField blocks, while django CMS stores content in placeholders filled by plugins. Neither structure maps one to one, so each page type needs a written field and block mapping before any data moves. Content that is plain text or image files usually transfers cleanly. Nested blocks, custom block types and inline references need a rebuild. Ask for a field-level mapping document before scoping the migration.
Templates and plugin rebuild
Front-end templates are the most visible rebuild. Wagtail page templates render StreamField blocks, and django CMS templates render placeholders and plugin output, so each template is rewritten rather than copied. Custom Django models, template tags and form logic usually survive because both systems run on Django. Review every custom plugin or block to decide whether it is retired, rebuilt or replaced by an existing package.
Search index rebuild
Search indexes are tied to the content model they index, so changing the model means reindexing from scratch. Wagtail's integrated search can use Elasticsearch or PostgreSQL, and any move must confirm which backend the target system uses and how it is configured. Plan a full reindex in staging and compare result quality for the top search queries before cutover. This step is one-time, but it is easy to skip.
Workflow and versioning rebuild
Wagtail includes content workflows and moderation in the core, while django CMS provides content versioning and editorial workflows through official add-on packages. Approval chains, roles, scheduled publishing and revision history do not move automatically between the two. Confirm which add-on packages are required, check their supported Django versions, and rebuild each approval chain in the target before editors start using it.
URL and redirect preservation
Page paths, slugs and internal links are what search engines and inbound links depend on. The page tree in each system is organized differently, so URL structures may need to be recreated to match the old paths. Export every indexed URL from the current site, map each one to its new location, and keep a redirect file tested in staging. Missing redirects are the most common source of traffic loss after a switch.
Editor retraining and adoption
Editors who know Wagtail's page explorer and StreamField editing will need new habits in django CMS, including front-end inline editing and placeholder-driven layout. The retraining cost is recurring in the sense that every new editor needs it, and it is paid again if staff turnover is high. Budget time for training, a parallel run period and written editorial guides for each content type.
The order of work when moving from one to the other
This sequence turns a move between Wagtail and django CMS into a set of checked stages, so each change to content, data model and URLs is verified before the old site is retired. The order below is illustrative and should be confirmed against your own content inventory before any work is scoped.
Inventory content types and plugins
List every page type, snippet or model, placeholder or plugin in use, custom template tag and third-party package on the current site. Include the editor roles, scheduled publishing jobs and any search or image rendition settings that the front end depends on. The output is a written inventory signed off by the content owner and the lead developer, with each item marked as keep, rebuild or retire. Done means no content type exists on the old site without a named destination.
Map the data model to the target
Translate each source content type into its target equivalent: a Wagtail page model with StreamField blocks, or a django CMS page with placeholders and plugins, and record where each field, relation and rich-text fragment lands. Flag every place where the two models do not map one to one, since those need a decision rather than a conversion script. The output is a field-level mapping document reviewed by the editorial team. It is done when every source field has a target and every exception has an owner.
Decide versioning and workflow add-ons
Confirm which Django version, Wagtail or django CMS release line and Python version the new stack will run, and check each against the supported versions in the release schedule and the django CMS documentation. Then decide how content versioning, editorial approval and any headless delivery will be provided, since django CMS supplies these through official add-on packages. Ask the vendor or your partner to confirm current support windows for the exact versions chosen. The output is a written version and add-on decision record approved by your security and platform leads.
Build a parallel environment
Stand up the target site beside the current one, in the same cloud account or data center, with the same database engine family where practical, and the same search, media storage and authentication integrations. Load the mapped content models and templates without live editors touching it. The output is a working staging environment with a configuration record that matches production controls, including backups and logging. It is done when a clean deployment can be rebuilt from code alone.
Migrate and verify content
Run the migration in repeatable batches, starting with a small sample of each content type, then the full set. After each batch, compare record counts, rich-text output, image renditions, translations and published states against the source. Have content owners review a defined sample of pages in each language and each site. The output is a migration log and a verification report with every discrepancy either fixed or accepted in writing. It is done when two consecutive full runs produce no unexplained differences.
Preserve URLs and redirects
Export every indexed and linked URL from the current site, including media and language prefixes, and map each one to its new address. Implement permanent redirects for any path that changes and confirm that search engine sitemaps, canonical tags and analytics tags carry over correctly. Test a sample of high-traffic and legacy URLs in the staging environment. The output is a redirect map and a test report showing that every mapped URL resolves to the intended page. It is done when no mapped URL returns an error or an unintended page.
Cut over and monitor
Schedule the switch during a window agreed with the content team, freeze edits on the old site, run a final incremental migration, and point DNS or the load balancer to the new stack. Keep the old environment in read-only mode so that rollback remains possible until the agreed acceptance checks pass. Monitor errors, redirects, search indexing and editor login problems for the period you agree in advance. The output is a signed cutover record. It is done when the acceptance checks pass and no rollback has been triggered.
Retire the old stack
After the agreed acceptance period, archive the old database, media files, code and configuration in a form your retention policy allows, then revoke its credentials, DNS records and server access. Remove scheduled jobs and monitoring alerts that still refer to it. The output is a decommissioning record listing what was archived, where, and who approved deletion. It is done when no live system, credential or scheduled job still depends on the old site.
What implementing each one involves and where projects run long
Implementing either Django CMS is a Django project first and a content project second, so the first decisions are about the data model. In Wagtail, that means choosing how page types are composed, where StreamField blocks replace free-form rich text, and which fields belong to snippets instead of pages. In django CMS, the equivalent decisions sit around placeholders, plugins and the page tree. Teams should write down the content types, their owners and their relationships before any theme work starts, because changing a page model after editors have entered content is the most expensive correction in either system.
Theme and template work, editor training, search and multi-language setup follow the model. Confirm which search backend each platform will use (Wagtail lists Elasticsearch or PostgreSQL as integrated options), how each locale is structured across sites, and which editor roles and workflow stages the content team needs. Identity is a separate workstream: confirm with your identity team how SSO is delivered to the admin, whether group membership maps to editor and publisher roles, and whether the chosen version and add-ons support that integration. Hosting and backup need a named owner for database, media files and search indexes, with a tested restore procedure. The Django upgrade cadence also belongs in the plan. Check the Django versions each release supports, and align your upgrade windows with Wagtail's LTS and feature releases or django CMS's LTS line.
Projects usually run long in three places. Content modeling is the first, because stakeholders often disagree about page types only once they see editor screens. Add-on selection is the second: django CMS needs separate packages for content versioning, editorial workflows and headless delivery, so each add-on's maintenance status, Django compatibility and licensing should be checked before estimating integration work. Migration of legacy content is the third, since mapping old URLs, images and metadata into the new model usually takes longer than the initial build. Ask any implementation partner for a written scope that names the model review, add-on decisions and migration rules as separate deliverables, with the acceptance criteria for each.
Questions buyers ask before choosing between Wagtail and django CMS
Which one costs more to run over time?
Neither license adds a fee, since Wagtail is BSD-3-Clause and django CMS is also BSD 3-Clause licensed, so run cost comes from people, hosting and upgrades. Wagtail's core covers StreamField, workflows, search and a headless API, so fewer add-ons may be needed for those features. django CMS keeps versioning, editorial workflows and headless setups in official add-on packages, so budget for those packages and their upgrade cycles. Ask each vendor or partner to price hosting, the search backend, the version-control add-on and the Django upgrade path in one written scope.
Can a team without Django experience operate either CMS?
Both are Python and Django applications, so someone on the team has to read Django code, manage migrations and handle Python upgrades. Wagtail's model-driven content types and StreamField blocks are defined in Python, so developers who know Django will adapt quickly, while editors work in the admin. django CMS relies on placeholders and plugins, which also require Django knowledge to extend. If your team has no Django skills, plan for training or an implementation partner for the first release and for each major upgrade.
How long does a migration take, and what drives the timeline?
The timeline depends on content volume, template complexity, custom plugins or StreamField blocks, integrations, and how many languages and sites must move. No duration is supplied for either platform, so ask for a fixed-scope plan that lists each content type, the mapping rules and the test cycles. Cross-CMS moves usually cost more in content mapping and editorial review than in code, because page trees and plugin structures rarely map one to one. Set acceptance criteria per content type before work starts.
Do editors need training before they can use either CMS?
Yes, editors need training on the admin, but the amount depends on the model you choose. Wagtail's workflows and moderation give editors a defined review path, which means training should cover approval steps, previews and page locking. django CMS offers front-end inline editing and a page tree, which some editors find faster but which also requires them to learn plugin placement. Budget time for a pilot group of editors, and confirm with each vendor which editor features need an add-on.
Is a headless front end supported out of the box?
Wagtail includes a headless API in the core, so a separate front end can read content without a bolt-on package. django CMS does not include headless delivery in its core, since its headless setups come from official add-on packages. Confirm the exact API features, authentication options and caching behavior for your front end framework before you commit, and check whether the add-on is maintained for the Django version you plan to run.
Which LTS release should we pin for production?
Pin an LTS release and plan the next upgrade before you go live. Wagtail 7.4 LTS, released May 4, 2026, has security support until November 2, 2027, and Wagtail 8.3 LTS is scheduled for May 4, 2027 with support until November 6, 2028. For django CMS, 5.0.x on Django 5.2 has LTS until March 2028, and 6.0.x on Django 6.2 is planned with LTS until March 2030. Match the Django version to your hosting and library needs, and confirm the support windows against the official schedules before you pin.
Can our own team run the platform, or do we need outside help?
Your team can run either platform if it has Python, Django, database and deployment skills and time for upgrades. Ongoing work includes applying LTS and feature releases, rebuilding add-on compatibility, patching the database and reviewing security advisories. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with agreed deliverables. Ongoing support and upgrades are also available as retainers. Start with an internal skills review, then compare that against a written scope from a partner.
How DeployOpen helps choose, implement or migrate between them
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 infrastructure. For Wagtail vs django CMS, we work from your content model, editorial workflow, Django version constraints and hosting setup to produce a written scope before any build starts.
How we scope
- Written scope covers content model, editorial workflow, languages and sites, and the headless API consumers involved.
- Scope records the Django version and LTS line you plan to run, and which add-ons your versioning and workflow needs require.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- Build covers StreamField or placeholder-based content models, page templates, and integrations with your identity and search stack.
- Testing covers editor workflows, permission rules, multi-language output and upgrade paths between feature or LTS releases.
- Deployment runs inside your cloud account, data center or air-gapped network, using your database and search services.
How we hand over
- Handover includes configuration, architecture notes and runbooks for upgrades, backups and restores.
- Documentation records which add-on packages, licenses and Django versions the system depends on, so your team can audit them.
- Compliance readiness material is prepared as evidence for your assessors, which DeployOpen does not itself certify.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can track Wagtail feature and LTS release windows, or django CMS LTS dates, against your upgrade calendar.
- Ask in your quote how support covers add-on updates, security patches and Django version moves.
