Why or why not use Dot Net Nuke (DNN)?

[Joshen]

I have development team pitching my client on using Dot Net Nuke (DNN) for the CMS.  I have no experience with DNN and not sure why the developers want to use it.  They do want to use Server SQL and may build some software for a different part of the project in .NET.

What SEO and UX questions should I ask about using DNN?

[RyanKent]

My clients look to me for recommendations. Recently I was in a position where I needed to determine which CMS would be best to recommend for clients, as well as use for my own site. I reviewed about a dozen CMS systems including Dot Net Nuke and ultimately narrowed it down to three: Joomla, Drupal, and WordPress. I dropped Drupal after closer inspection and my recommendation for clients is either WP or Joomla.

If a "full-featured" site is needed, I recommend Joomla. Actually, it is my default recommendation because it allows so much flexibility. The biggest drawback for Joomla when compared to WP is it is more complex, both for admins and developers. It will take a bit more time to develop and a bit more knowledge to administrate. If a client needs a basic site I would suggest WP. These are simply my experiences and research and I am only sharing in case it is helpful.

I would also share I have used Windows-based software most of my life. I spent 7 years as a MS SQL DBA working for Verizon Wireless. All my experience is working with windows platforms, yet for web development there is a strong preference towards *nix based platforms. If I was being pitched with a Dot Net Nuke CMS, I would ask for a clear and compelling reason to accept the proposal. My guess is the developer's main experience is with that platform, and they are biased.

When developing a new platform, I would recommend a plan which is based upon the inherent coding of the CMS. When necessary rely on the most established extensions or add-ons possible. Unless you are working for a large company which has their own developers on staff, you want to avoid custom coding whenever possible. CMS software is frequently updated. You will be faced with a constant choice of not updating your software, or paying to have the custom coding updating before each update. Additionally if a key developer leaves, you are often faced with the new developer not working well with the prior code and pitching a plan to recode the site.

The entire point of a CMS is faster development, lower development costs and standardization. My main focus in receiving a pitch for any platform is to examine the development plan with these questions in mind.