django CMS development

Build content management systemswith django CMS and Python

django CMS lets editors change a page where they see it, using placeholders and plugins, while the site stays an ordinary Django project. We build on the 5.x line and upgrade older sites. If yours is on 3.11 or 4.1, their long-term support ended in April 2026.

Discuss your django CMS siteSee Django development

What django CMS work covers

Editors get the page editor. Developers get a normal Django application behind it.

  • Content sites inside a Django system

    A public site that shares users and data with your Django application, so that content and application don't need two separate platforms.

  • Custom plugins

    Components editors can place on a page, such as a product list or a form, written in Python with templates and reusable across the site.

  • Upgrades from 3.x and 4.x

    Planning the step through 4.1 to 5.x, including the data changes, the replacement for built-in publishing and any plugins that have to be rewritten.

  • Headless delivery

    From 5.0, a project can drop the catch-all URL and serve content through an API such as djangocms-rest to a separate front end.

django CMS versions, as of October 2026

From the django CMS documentation and project blog.

  • 5.0 is the current LTS

    Released in February 2025 and supported until March 2028, paired with Django 5.2. It was at 5.0.13 in September 2026. This is our default for sites that change rarely.

  • 5.1 is the newest feature line

    Released on 13 July 2026, it works with Django 5.2, 6.0 and 6.1, and drops anything older. At 5.1.3 in September 2026. It suits projects that upgrade regularly.

  • 3.11 and 4.1 have ended

    Both LTS lines reached end of life in April 2026. Several 5.0 security releases followed this year, so a site on the old lines is missing fixes that matter.

Why the 3.x to 4.x step is the hard one

Version 4 rewrote the core, so this step is more of a migration than an upgrade.

  • Publishing left the core

    In 4.x any content change is live at once, unless you add djangocms-versioning for drafts and published versions. Editors need to know this, and it needs installing and testing.

  • The data model changed

    Title became PageContent, placeholders moved to the content object, and plugins are stored per language. The project's docs say only third-party tools such as djangocms-4-migration can help.

  • Static placeholders were replaced

    They give way to djangocms-alias, and template tags and URLs such as ?edit change too. Every custom template and plugin needs to be read, so count them first.

  • The step to 5.0 is smaller

    Page.node has been merged into Page, which needs a database migration, and code using node__ lookups has to change. Edit mode no longer uses inline scripts, which makes a strict CSP possible.

How a django CMS upgrade runs

We rehearse on real content, because that is where the surprises appear.

  1. Count plugins and templates

    We list every third-party and custom plugin and each template tag in use, then check which have a release for your target version.

  2. Rehearse on a copy

    The migration runs on a copy of the live database, and we compare page by page, in each language, against the current site.

  3. Agree the new editing process

    Your editors try versioning and publishing on the copy, because the way they work may change even if the pages look the same.

  4. Freeze, migrate and verify

    We agree a short content freeze, run the migration that was rehearsed, then check URLs, permissions and media before reopening.

How we arrange django CMS work

We count plugins and templates first. They drive the price, not the page count.

Upgrades are quoted after that count, normally as staged work because 3.x to 5.x has two distinct parts. Smaller changes and plugin work can run at hourly rates, from $20/h in USD and invoiced in USD, GBP, EUR or INR.

We are an engineering team in India with 3–5 hours of overlap with the UK and Europe; US calls by appointment. In the shared hours, an editor can review pages on the rehearsal site with us. If you don't need in-page editing, look at the plain Django admin or a different CMS such as Statamic before committing.

Why django CMS sites aren't named here

Most of our work is delivered under NDA, so many projects cannot be named.

You won't find a site list on this page for that reason. Tell us your version and plugin list and we will show our reasoning on your own site, which is the part that matters when you are planning an upgrade.

Questions about django CMS

Common questions from owners of older sites.

We are on 3.11. Can we go directly to 5?
The route runs through the 4.x data changes, so plan for both, even if the site isn't released on 4.1 along the way. The first step takes most of the effort, and we rehearse it on a copy.
Should we use 5.0 LTS or 5.1?
5.0 gives you long-term support to March 2028 on Django 5.2. Choose 5.1 if you want the newer editing experience and Django 6, and will keep up with its releases.
How does it differ from Wagtail?
django CMS centres on editing a page in place using plugins. Wagtail centres on structured page models edited in an admin. Both are good Django options, and which your editors prefer should weigh heavily.
Can it run as a headless CMS?
Yes, since 5.0, with an API add-on such as djangocms-rest. But if you only want an API and never use in-page editing, a headless-first CMS may be simpler.

Tell us your version and plugin list

Both come from your requirements file. We will reply with the upgrade route and the parts most likely to take time.

Start a django CMS conversationSee Django development

We reply within one business day (IST).