While we try to be as conscious as ever in providing a clear upgrade path to the newest and lastest version of DotNetNuke, sometimes it's not that easy in my opinion, and now, I'm at the stage of really not moving towards an upgrade path, but to completely redo a site from scratch.. and of course, this is only my opinion, since that's all I've got, but I'll tell you why..
Earlier on, DotNetNuke was primarily a developers product, I 've mentioned this before, but now, with the broader audience of non developers coming into DNN there are challenges I'm seeing that weren't there before, and so,now what happens we have a mixed audience, some skilled, some having access to developers, and a huge amount of people totally relying on building their business model based on modules you can purchase from snowcovered. Sure there are some larger companies developing high end solutions, but like anything these may have big numbers, like the million dollar AFL site, but that's so small when you compare to the many many MANY thousands of smaller companies.
If I were a business looking at using DotNetNuke, here's how I would go about it.. based on hindsight, experience, and a snapshot of how I do things..
Firstly - establish the type of clients you have. For example, are you going to require single builds, or will a multi portal instance be enough. People discount the multiportal instance because I think they have some perception that it's not going to perform for them, but in my own opinion, I believe some of the best installs and least troublesome sites I've got are those that have many sites under a single build. DNN thrives on that.
But you don't just jump in and drop all your clients in that situation, since I'm just working on a new site for a client that was a large one, but part of a multi portal install, when perhaps it might have been better to do it on a single build.
That's where, in your business model you need to look at the type of clients you have, and how they are best managed. And, knowing how DNN works, the modules that are needed for specific sites, the expected growth of the company can help you in deciding what's best in the long term for less headaches.
So how does this affect upgradability, well, you then decide at what point the project is handed over. I will never again provide a suggestion that I will continuously upgrade a particular site for a client. The only time I do this is when I have a site in production, where I'm building the whole portal on my server, to deliver to them, so they can simply attach on there own server. And only if it's an important security fix or a particular flaw you know of. That means if I take on a project that is a current 4.3.6 site, that's what I'll run with for that lifecycle of that job.
It's unreasonable to expect someone to consistently upgrade a site just because DNN brings out different builds, and no matter how fantastic something is, to upgrade can bring about the undoing of a great site, if you aren't experienced.
The biggest changes I've noticed when people are upgrading from earlier versions is that many modules don't exist.. Some people say - well if this is the case -then better to design a site that uses only core modules, since the core modules are getting better.. but I say - no, you should start off by understanding what your client wants, and find a solution that fits, and find a reputable developer and see his history, and if the job is critical where you require the source, for future development, then the choice is yours, but sometimes I see people get discouraged about buying modules without code. Are they looking to far into the distance? What precautionary steps are they taking since chances are that in the future, if something went wrong, would they be creating the same site with the same module source for the same version?
In my own situation, I rarely bother to purchase source code unless I need it for that project and it needs to be developed at the time for successful deployment of the website.
While there have been a couple of instances where there were some handy modules and the developers disappeared, and there was no source code, it was more of an inconvenience, a particular quirky module life wasn't too bad. But these days - with the maturation of DotNetNuke, with the amount of developers around and a wider choice of solutions, it's not that much of an issue.
I also used to think it would be good to have the same builds running on the servers, so that I had the most stable build and eveyone's site on it, and guess what - that died a big awful death when I realised that upgrading is only as good as the build that's got some upgrade path development and the module developer keeps up.... so I ditched that and opted for a solution per client, a mix of child based portals and a variety of builds and things are running just fine.
Not saying that we don't have problems, but for the most instances, my thoughts about those who want to upgrade their DotNetNuke sites to the latest and greatest, you're going to be in this forever upgrade state of mind... First you have to check the module developers have the latest, and has it been tested, then you really should have a dev build of the site to test it on... and then you need so much time to check every element of your sites so that you don't get the surprises showing up in the log viewer.
My site runs on DNN 3.2.2 - I think one of the more challenging builds if you ask me.. and I tried for nearly 3 weeks, it was just the worst time I can remember, and I'd come off the back of misery with the catalook builds that broke my skins... but until then we had all experienced a great run on DNN 3.1.1 - I think that was just after localisation, and before the search functionality was put in, or something close to that - just thinking off the top of my head.
Then we had 3.2.2 which brought around significant changes, just in time for 3.3 builds that incorporated the new memberrole mangement, and the release of DNN 4 running on aspnet2 and along the way literally hundreds if not thousands of changes, multiple upgrades on modules both core and none core.... and we somehow expect that as business owners, we should keep our clients sites running smoothly and being perfectly upgraded from the very first install of DNN.
I had this mad idea that I would become a DotNetNuke expert by doing nothing but DNN, in reference to skinning, designing and managing solutions using the DotNetNuke framework - as I felt for me it was a great choice.. It's not been without pain or financial cost I have to say and sometimes my own clients have had to wear the misery of a lousy build or modules that didn't meet the expectations of what we first started with.
It's been a true apprenticeship for me - three years nearly since skinning became a reality, and my decision to be as best as I could be with the skills I have, and the equipment I own, to create a business infrastructure that I could generate a viable income, which until this year was pretty much the power of one, handling about 100 clients, 600+ mail boxes, 3 servers, and over half my time going to volunteering my efforts for the community to help others learn from my mistakes, rather than make their own.
Now, I'm looking at a few other options that have presented themselves, and next year look forward to some great ventures... But the way I look at it is that it could have been any other application, it's been around 80 hours per week for three years that's seen my knowledge and experience grow, and why I think I can say what works and what doesn't - for a buiness my size.
Now I'm being contacted by large companies, organisations, government and eduction departments who have expressed their interest in using DNN and want to get it right and launching our subscriber site with John Mitchell and Armand Datema means we have something sustainable and resources to put into making DNN a better product with some cool ideas we're experimenting with.. but we have some other plans too - I just can't share them with you at the moment!
When I'm asked about upgrading sites, I've found it easier to simply redo from scratch, and work with better modules, better solutions and a more logical approach to the project.
And we're finding the results and management overall have been pretty good. I think that this is more in tune with sites that are dnn 2 and dnn3, that the later dnn4 builds..
Nina Meiers