My initial comment would be that your organization needs to not create a strategy based on marketing hype 😃. Seriously, I will let others with more experience in the DNN ecosystem provide their input, as I know several will say that “DNN IS headless”. Check out this post: https://www.linkedin.com/...es-nisarg-shah-2hf6f

take a look at 2sxc Web API - https://docs.2sxc.org/web-api/index.html
and also DNN API here - https://docs.dnncommunity.org/api/
(although it would be good to have something better than a "coming soon" message on the main page!)

Out of the box, DNN is not a headless CMS, perhaps not even a CMS - but it's a great platform that can be turned into many things including a headless CMS by using existing modules from various vendors. The advantage of staying on DNN is reusing your vast experience and leveraging the flexibility the platform provides. Most of the headless CMS solutions out there would force users to do things in a certain manner, with very little control except writing your own code and using APIs to interact with their platform.

At the moment we help one of our gov customers build a headless CMS in DNN / Plant an App. I'd be happy to demo it to you. Reach out directly at [email protected] if you want to see it.

Hey there, Dutch Customs! 👋🏽😎

As someone who’s long been embedded in the DNN trenches—from dev to evangelist and MVP—I’ve lived through the glory days, the Evoq era, the open‑source renaissance, and the current community-powered momentum. So a quick gut-check: yes, I think you’re in great shape.

1. DNN can be headless—but it doesn’t wear that label out of the box
Straight up: DNN isn’t a headless CMS in the traditional sense. But it absolutely can act like one. With APIs like 2sxc Web API and the core DNN APIs, plus custom modules or OpenContent Razor templates (example: my May 2025 release of OpenContent Templates – Razor‑Powered & Ready for You), you can build headless-capable content pipelines—and do it with control, flexibility, and security.

What really matters here is that you expose the API endpoints you want/need to build and support other apps.  This is something I've seen and done several times over the years.  The first time I saw someone do this was at Orlando Code Camp way back in 2007!  The tooling wasn't even in DNN yet!  

2. Legacy & familiarity = enormous value
You’ve got experience on DNN. Instead of rebuilding, you can leverage that know-how to stand up APIs, tailor workflows, and reuse modules. Many off-the-shelf headless systems force you into their model and lock you down. With DNN, your possibilities are wide open.

You're not limited to just one app, app type, dev pattern, proprietary standards/syntax, etc.  Just ASP.NET!  💪🏽 

3. Community-driven and evolving
DNN may have gone through organizational ups and downs—but it’s the community that’s kept it thriving. Compared to other CMS options, DNN stands out with a passionate, active community and a platform that continues to adapt.  

My only concern here is that the people running the technology group are literally refusing to progress us to .NET Core with all kinds of excuses, despite there being a clear path forward.  It's clear that it has something to do with the personal views of a select few, though.  See the links below to see how exciting this future is!

• A True MVC Pipeline for DNN
• Supporting Video
• DNNCore.org (normally has some great content...)  🤔 

4. Resources you’ll find useful
You’ll want to check out the 2sxc Web API and the DNN API as starting points—others in the thread have already mentioned them. From there, consider pairing with Razor-based OpenContent templates or building custom Web APIs for full headless flexibility.  

You're literally only limited by your creativity and imagination! 🙌🏽

5. My two cents
If you need content delivered to varied front ends (web, mobile, or external apps), go headless—but don’t abandon your DNN investment. Keep DNN as the content engine under the hood. That way, you're not starting from scratch—you're evolving smartly (and saving budget)!  

Thanks for your responses. The discussion is more about the future of DNN. I'd like more information about the pros and cons, and potential pitfalls of implementing a headless CMS. Thanks!

Posted By meffj00 on 8/15/2025 4:30 PM
Thanks for your responses. The discussion is more about the future of DNN. I'd like more information about the pros and cons, and potential pitfalls of implementing a headless CMS. Thanks!

You are absolutely correct. I am going to lock this thread for now and split it up.

Posted By meffj00 on 8/15/2025 4:30 PM
Thanks for your responses. The discussion is more about the future of DNN. I'd like more information about the pros and cons, and potential pitfalls of implementing a headless CMS. Thanks!

 

I apologize to you on behalf of the community for hijacking your question. I think there are a number of people who also would have an opinion on DNN / headless options. Good luck with your project!

 

Hi meffj00,

I have been involved in several headless projects for the last 6 years. And there are numerous pitfalls. 

1. Reason why. The reason any organization wants a headless content management is either because of developers (clean HTML, real division of content and logic) or someone who has a more conceptual or holistic idea of content management: 1 repository of content editors or content managers. Now, this is not the reality. Content is rarely reused cross channel. Simply because content pages on the web are every different than in narrow casting or an insta post. But also if the salutation is different: in formal context we (Dutch) say 'u' whereas in informal context we say 'jij'. Said that: Aiming for content integrity is a very valid point of course. Content being correct should be priority 1, 2 and 3. The way I have seen content being reused is in multi site scenarios, like marketing websites are in a case where customs would work together with police or a ministry. If there is anything I would change to DNN is if I could create portal groups where I don't share (all) users as well, just the content. By the way, in order to have proper content hygiene it is far more important to get an alert as a content manager saying 'this article needs reviewing'. For price changes or laws being mentioned, for example.
    
2. Content modelling. If you want to migrate to a headless CMS, you need to think of the content modelling first. What items are needed, the type, the validation, who has what rights etc. If you have a web page of 5000 pages that needs to be migrated into 10 content types all consisting of 10 fields, that is a lot of work. And: as content might be reused in another way - that was what headless was aiming for - you will have scenarios where the context is missing. 
   
   Combining 1 and 2: the only valid scenarios for content reuse is things like 'The price for this is X'. Or 'The way to accomplish this is a, b, c'.  What you need as a content manager is to inject/connect/add some content from a repo of snippets.  
    
3. Organisational. If you have multiple websites or other channels, most of the time you have owners. Either departments or people. They are in charge of what is being published, how and when. As soon as you are mixing content across owners, you need to realign the editorial processes as well. 
    
4. Headless CMSses only look at content. Which makes sense. But there is a whole bunch of stuff that is part of content management. Simple stuff like being able to control the urls, SEO, upload files, define what filetypes are allowed, redirect management, define (per role) what the wysiwyg offers etc etc.
    
5. Most of all: create and manage pages. Content in a headless cms is by nature not aware of the context. Which is a problem. 

Real story: In a (famous) headless CMS I created content. I was able to define a url and a depublish date. After the depublish date, the url was still available but the content not. So, the website served just the header and the footer instead of a 404. You can imagine that that is a problem that would become bigger over time. 

Real story2: a headless CMS was only able to publish all pages. Not one. Simply because the concept was all about pieces of content. The assumption was that initially you create a few pages and that's it. That is wrong in so many ways...

Summarizing:

• I have never seen a successful headless implementation in a medium or larger context.
• I have seen successful implementations of decoupled CMSses. 
• The concept of Headless is more of a marketing strategy for new CMSses that turned the lack of features around to their advantage. Like Kindle doe not say 'we sell tablets with just 1 app' they say 'we allow you to focus on reading and offer an immersive experience'

Decoupled offers the same advantages as headless. But you have a mature CMS (either DNN or Drupal for instance but that is another story) that allows content managers to do their work. And if you want to migrate to a more refined content model you can do so in a controlled manner. 

I’m not a technical expert, but I think the choice depends on how flexible your content needs to be. A headless CMS usually makes it easier to use the same content across different platforms, while DNN feels more tied to a traditional website setup. Maybe it’s worth testing a small project in a headless CMS first to see if it fits your workflow better.