Thanks Joe. I did have a GoToMeeting call today. The original point of my thread was to state that DNN can do a LOT more to make this less manual, error prone and robust.

For the record, I spent over 1 1/4 hours on the phone today with your support technician (who was excellent by the way). Everyone keeps telling me "it shouldn't take more than a few minutes" - but it has taken me HOURS. The only variable I had in my deployment was the use of IFinity - hardly an "obscure" module and one that only impacted the very last issue we uncovered (maybe added 15 mins to the 75 we took).

Virtually all the issues we uncovered were things that could easily have been detected / fixed by an upgrade utility. It is very frustrating that just because it CAN be quick and easy is considered justification to pass a bunch of manual checks on to the user. I don't doubt that some folks have just dropped the files in place and magic happens. That didn't happen for me over the past few days - and it didn't work for a very experienced and helpful support person today.

As an aside, I bumped into someone yesterday who used to use DNN. I asked why he stopped using it. He said that too much was left to the individual to manually tinker with things, taking time away from the core job of managing content. I will stay with DNN for now but I agree with him - this (dare I say) arrogance that "is easy" can hurt the impression if the platform.

I am a strong advocate for DNN putting effort into wrapping the upgrade process into a nice utility that checks permissions, versions and the overall integrity of files - and takes that burden of the user. After all - it's easy :)

Mark

< Pile On / >: I agree that DNN upgrades are not easy. Perhaps if you have a small, clean install running only, core modules then sure...but when you add in 50 portals, 50 modules and some providers it can be a VERY technical process to prep the platform and execute a simple dot release upgrade. This doesn't even take into account testing for 3rd party module compatibility between versions.

In my previous environment we would plan a full week of testing, staging and finally upgrading (in the middle of the night over a weekend) to upgrade five production DNN systems. This involved myself, our DBA and a few hours of our network engineer. So we would budget 90 - 100 hours of time per upgrade and have a successful upgrade about 50% of the time. When it failed it would mean another few days of research and retesting. Not a small investment..

It does appear that some people have figured out a way to automate a lot of the process: http://www.snowcovered.com/Snowcovered2/Default.aspx?tabid=242&PackageID=22480. I've used this before with success on personal projects and it even saved my bacon on one particularly unhappy upgrade on a commercial project. It seems to me however that functionality like this should be part of the core.

As DNN matures it's interfaces and workflows (which are looking super sweet) I think the company needs to mature as well...it's not just techies that download and use DNN. Yes, you can modify a web.config or run a script...but most people have not idea how and at the first sign of trouble they'll move on to WordPress or Joomla or some other platform. Yes, they all have their problems and technical details to sort out...but DNN does seem to have a programmers platform reputation which I think hurts it's market perception (I know I've heard it when pitching the SMB market on the benefits of DNN).

DNN 6 is the first version I've put in front of a client where they go "ooooohhh" and "aaaahhhh" because the admin interface make sense and they believe they can actually USE the product in house. Maturing the docs and upgrades and adding some compatibility checking will go far to help these small business owners (all potential pro customers BTW) feel like their investment in the platform doesn't require a significantly larger investment in a technical DNN expert too.

---

Steven Webster
Manager, Community Platform
F5 Networks, DevCentral