Dear Community, before I start I would like to state that I'm currently very happy with the status quo of DNN ecosystem (I've been feeling this way for many years now...) I’m just sharing my two cents here; I apologize in advance if some part of my statement doesn’t make you feel ok, my intention is just to share my POV. Finally, I would like to thank the people responsible for making decisions and all the developers out there contributing to the platform. Thank you all for your amazing work! DNN is what it is because of you! THANK YOU From a DNN implementer POV who consumes skin and modules from third parties: my answers depends on the vendor's action plan since I rely on their products. For me to re-implement modules and skins I'll need to have the same products I currently use available in the new version so I can start the transition, this means that it will not be enough to only have DNN new version available. If the vendors come up with a clear path for transition with real ETA's I would like to believe that more people who consumes third party modules will get onboard to move forward into a new DNN version based on .NET Core. Most of my clients are not technical wise, they don't know which CMS I'm using because they're too busy running their own businesses; they trust my judge and decision making, the only scenarios where I'm going to get a client aware of this transition is a custom development, I've a few of those and I'll certainly need to discuss upgrading their custom modules with them because it requires time and money and I need to get the client onboard, otherwise I won't be able to make the transition in these scenarios. Based on this, I believe supporting 2 versions of DNN for some time could be a good transition process so everyone can have a window to run all the changes. Now, the time... that's something that I don't know how to give you an approximate because it depends on each agency or business available resources time and skills; but just to throw a number... 16-24 doesn't sound bad to me. In a scenario where any of my current vendors are not willing to make the transition and DNN IS moving forward; I'll be more than willing to implement a new solution. This world never stops; in technology you can't stay in the same place forever... (have you tried to play videogames on a play station 1 on nowadays TVs? I've one and I play from time to time with some friends to remember the old good days and last time, we've to rush and purchase an RCA to HDMI converter... it was not an easy task to find a converter on a Saturday afternoon...! and don’t you get me started on burning games on a CDROM! That’s funny and at some point even ridiculous… jajaja) always getting out of your comfort zone it's a good thing, having a vendor thinking otherwise... from my POV, this is a BIG red flag. I'll certainly move forward along with DNN. Now, am I willing to re-implement everything? YES! it's a lot of work, YES! but, from a small agency down here in a Pura Vida place POV this is the long term future and, if you draw me a picture where my son (8 years old) is going to be able to use the best CMS in the whole world, well... in my case, it's an easy answer: YES!!!! If I break a leg I'll certainly be willing to go through the pain and recovery process of a surgery to get back on my feet (in this silly example walking means "keep using DNN"). Talking about .NET Core, MVC and DNN I believe it excites anyone around the DNN ecosystem! we've a one of a kind community, a community that I know for sure a bunch of folks who uses other CMS's have in their Santa's Christmas letter each year! our community is full of experts, smart and very successful folks so... let's continue to have a positive conversation about this and let's all break a leg together!!! :-) Those are my two cents…

Mitch, thanks for your post. While I do see your concerns about the effort that would be required for running solutions to move over to MVC.NET, I know there is no alternative. You say that it would be a great long term goal. I agree, but that long term didn't start today, or last may on DNN Connect. It started some 10 years ago when we all stopped liking post backs in our web applications. DNN must move away from webforms in the first place and move to .NET second. New developers are not joining in anymore, for a long time already. They don't learn about Webforms and learn that .net Framwork is old. It doesn't matter how much of that is true. Since we as a community didn't know how to proceed in that direction, we didn't. But that didn't stop the clock. That makes that this long term goal from years back, is now a short term goal. And fortunately..."komt tijd, komt raad" as we say in Dutch. With time comes counsel. We now have a solution, so let's not hesitate and move towards that now short term goal. Existing solutions will keep on running for as long as webforms will. Even when the DNN version it's running on, is not getting any new features anymore. The only really important question I see in your list, is: "Do you expect that the DNN Community would need to support 2 versions of DNN Platform (.NET Framework & .NET)". My answer would be yes, for a short period of time (months). After that, I think there should be a longer period (2-3 years?) where the community will only do security updates for the .net framework version. It will require quite some planning with clients to transition. We might loose some who take this step to move away from DNN. But new ones will come to DNN, or return to DNN.

I am in team marco-stefan :-) I have built my company based on DNN. There are several reasons to stick to DNN. The platform / community are the best. Switching to another platform also costs time and more important : it takes several years before you get the same level of skills/knowledge. About support. One can not expect a community to support 2 versions. This happens nowhere. A 2 year period of supporting security stuff would allow anyone to upgrade to the newer version. Vendors. Yes, it would be very desireable to keep the most important vendors within the ecosystem. This would make transitioning much easier. If it a vendor would not join us, I would search for alternatives.

Merging the MVC pipeline into DNN and planning for .NET Core migration is the preferred path. If this is not possible due to organizational constraints, creating a new DNN .NET Core CMS with a streamlined codebase should be considered.

Opinions! 1) Vendors already left. If we lose more, so be it. The ones that choose to stay will be celebrated. 2) Implementers (like me) will handle the migration and will be hoping to see a commitment of 2 years of security updates happening to the Framework version. Even if its a separate, smaller group of developer volunteers than the core ongoing team(s). We plan to be strong and somewhat vocal supporters of the MVC Pipeline project!

Optics! I am a marketing person by nature. I think the next major version of DNN should differentiate itself by leaping to either v20.00.00 or possible the modern semantic versioning of v2026.00.00. IMHO, everyone should read this: https://workos.com/blog/software-versioning-guide

My understanding is that most of the critical vendors - including 2sxc (so that's us), Open-Content and easyDNN are already on board. Others such as DNNSharp will not need much convincing, since they too already use JS+API approach, which is easy to migrate. I do agree that all the "custom" stuff will need time, so a reasonable transition scenario is critical.

This topic has already been a pain point in some of my client conversations, and while I fully recognize the challenges involved, it’s something we must do. We’ve been here before—DNN had to navigate a similar transition between 3.x and 4.x as we adopted .NET 2.0 features from 1.x, and we found a way forward then. We can model that same type of plan now. Above all, we need to move forward with adopting .NET Core in a responsible way. I’m supportive of a brief period where we maintain both platforms (.NET Core and WebForms), but I don’t believe that window should extend beyond two years. At Upendo, we’re ready to begin preparing our own extensions for transition as soon as a timeline is defined. No matter what we do—whether it’s moving toward .NET Core or continuing with the MVC pipeline updates—DNN will inevitably lose some people. The reality is, it already has and will continue to without this update. But without making the move, we’re only ensuring that DNN’s end of life arrives sooner than it needs to.

Hello all, as a web development agency that is using DNN for so many years now I can tell you how great the platform is and especially the Community around it. I must start this reaction to this blog with a great shout out to the people involved and keeping DNN as great and secure as it is. This discussion that has been started about integrating a MVC pipeline into the existing DNN Platform and ultimately a move to .NET Core is one that is more than welcome in our vision for many reasons. I can tell you this subject is high on our list for some years now and not only with us but we get questions from client as well regularly. One of the great things about the platform is the stability and the fact that it is running on the .net platform is one of the things that supports that stability. And it could do that for many years to come. The great thing and at the same time the pitfall of this is that clients are more or less used to the fact that we develop a solution that runs for many years without major updates needed. We are well aware of the changes and challenges using .NET Core will bring to our way of working but we see more advantages and we welcome the fact that it will involve more active maintenance of projects and code. It will keep the clients more involved. We already do hybrid solutions with DNN and .NET Core services and it would be great if we can solve those in an integrated solution. For these cases where we need the hybrid it will not need investments but it will generate savings. As we use DNN for a really long time now we have them all. Webform modules, the “MVC” modules and for some time now we mainly use the javascript + web api setup. The latest will be easy to migrate and when DNN is ready we will migrate these projects for clients willing to make the move together with us. And for some we might even do it silently without client involvement and just make this move on our own for them. We would not expect the DNN team to support two versions but it would be really great if for, say 2 years, security updates could be done to the latest .net framework DNN version. This will give everyone time to make decisions and transitions. As we want to be involved and committed to these exiting changes we will follow the discussions and participate in them where possible. We are willing to do tests and give feedback on them and we will also sponsor work done for this move. The same will be for the time the team will support security updates on the .net framework version of DNN. I really think we should value this.

Hi Mitchel,

thank you for this post and asking relevant questions!

I work for a company where we run a multitenant solution on DNN for a large group of customers. Just to provide some numbers, we host on 1 database more than 5000 portals with more than 600,000 users. Each portal has about 10 aliasses each with a unique certificate using automated renewal. And our application is localized across more than 10 languages, when you multiply our 100 page menu, we have a tabs table with more than 5 million rows.

We have previously talked on the phone concerning the perfomance of DNN under this load. When we were running DNN version 7.4.2 our infrastructure would often grind to a halt.

This volume means we need to optimize our DNN instance in many ways. This process has been difficult to say the least with DNN. We have had many problems when we almost ditched DNN for another solution.

Just to summarize some of the DNN issues:
Localization in DNN is full of bugs, Localized content just does not work 100%. Upgrade process of an installation this size is not possible, upgrade scripts will timeout due to the size of the database. Performance of DNN is not scalable in this size. We need to spread the load across servers in a webfarm with centralized caching. But DNN caching is flawed and slow.

What did we do to overcome these issues?

We build a custom caching provider for a webfarm using Redis with reduced cache access.
We built our own DNN Menu localization using DDRMenu.NodeManipulator
We had to customize DNN at various levels to increase performance:
Database tweaks using indexes, modify stored procedures
Added data to ObjectCache to further reduce frequent SQL Server access,
Added smarter use of cache to reduce cache access on Postback, some Postback calls retrieve the same object from cache over 100 hundred times. When cache is over a network this becomes an issue.
Support for hybrid content localization to prevent Tabs table to have one row for each localized menu, we now have a Tabs table with 0.5 million rows, and we localize content at our application level.
Custom installer and upgrade routines to handle large databases (thank you Stefan Kamphuis!)

Running this volume on one database has been quite a journey. We currently run 9.11.2 with a custom built DNN install to handle the load. We currently scale well!

Back on Subject. We have been changing our application logic to move away from custom DNN modules to a JS + API solution. We use Vue in the browser and we talk to our own .Net Core API which runs on lightweight loadbalanced linux servers.

We are very impressed with the speed of .Net Core on linux and the simplicity of maintaining the infrastructure. Our JS + API solution means we will reduce our DNN modules from 50 to 1 with a generic loader for JS. In the long term we would really like to remove our Windows IIS dependency and move to a full linux (container) infrastructure.

And to finish on a positive note, there are a few things we really like about DNN:

We can manage 5000 portals from 1 database. This greatly simplifies maintenance.
Almost every aspect of DNN can be influenced from the database.
We greatly depend upon the multi tenant options where we have sub portals with aliasses.
Customized skinning is important. Having one set of files to changed the look and feel is mandatory for us.
User access and Security is an important subject, we need to work according to best practices.

So for us we need to have .Net Core support in DNN. Not having .Net Core would have as look into other options in the future.

Thank you,
Evert

Unfortunately, many poor decisions have been made over the last years, leading to DNN's ongoing decline. Some of the most beautiful and useful modules, such as Ventrian, have been abandoned, and fewer and fewer developers are willing to invest their time into DNN products. Suffice it to say that there is still no valid e-commerce solution today, while WordPress has made great strides with an unparalleled range of modules and themes. At this point, the only things that keep me using DNN to build new websites are the DNNGo themes and the still-functioning Ventrian modules. For e-commerce sites, however, I have already been forced to switch to WooCommerce. The abandonment of WebForms would be the final blow to DNN, stripping away the last valuable parts it still has and reducing the community to a small group of highly experienced .NET developers. Let me also remind you that for those who need a CMS native .NET Core platform, Oqtane already exists.

Has anyone migrated sites over to Oqtane?