We had the same problem. Our company has been developng web applications for over 12 years for numerous clients. During that time, we developed shopping carts, distance learning solutions, time tracking/billing solutions, list servers, CRM apps, forums, help desk applications, real estate solutions, mapping solutions, a DRM Digital Rights Management system, and countless other applications. These applications were built for clients and were never commercially sold, only offered as a service.
Many of these applications were cutting edge at the time they were built. However, as time goes on, competition from other companies and from open source products decrease the costs of services for the end user. Generally, you have to lower the price of the service to stay competitive. Additionally, a small company is lucky to stay competitive on one application, never mind a whole suite of applications.
After we built the se applications, we said, these should have been built into one integrated system.
The other problem was that these applications were all built stand-alone.
Furthermore, when these applications were integrated into a website, the client had administrative access to the application (to change settings), but had to use FTP to make changes to other portions of the site. It was difficult for non-tech clients to make changes to a .net site. They then usually had to pay us to make simple changes, which they did not like. We were looking for an alternative solution.
Then last year, we had a client that wanted us to build a website where they could manage all of the content themselves. We quickly realized that we'd be doing a disservice to the client if we tried to build this system from scratch without looking for alternatives.
Since we are a Microsoft shop, we searched for .net solutions and found DNN. The idea of an integrated core framework with modules made perfect sense to us.
This is how we saw the dilemma. First the advantages.
1) There is a core framework controlled by a team, and an excellent user community. There is no way a small company could stay competitive trying to keep up with a system similar to DNN. The separation of the teams for specific modules ensures continual development. A small company just can’t keep up.
2) There are numerous free and commercial modules available at relatively low cost. Something that you would have to charge a client hundreds or even several thousand dollars, can often be found for free, or for a negligible cost (say under $100) .
3) There is excellent user support from the community.
4) The availability of this system is a significant benefit for your clients. You can get them running on a sophisticated system relatively inexpensively. Instead of having to charge them for the basics of the site (news, forum, content mgt.) you can use your billing time to focus more on their specific business needs.
Now the negatives, which we feel are minor compared to the positives.
1) We have some large applications that would have to migrated to DNN and we would have to learn the framework.
2) You have to change some of your coding to fit the system (I’m not a programmer, so I cant give you specifics).
Those were the main negatives that I can think of. Here are a some solutions we used for big applications and websites.
For large websites, we have installed stand alone DNN installations, and overlaid the existing asp.net (or even classis asp) websites over the installation being sure there were no identical folder names. We then made skins to match the existing website. We then had a seamless website that mixed DNN and asp.net (or classis asp) and the typical end user would never know the difference. Obviously a programmer would know. This gave us the immediate benefit of DNN, and took off the pressure to migrate the entire site or application. As we had to make changes to these other pages, we eventually migrated them if it was time-effective to do so. The DNN and non-DNN page co-exist gracefully.
1) For large applications, we have converted the end user front end to DNN and left the administration section alone. Example, we have an extensive DRM system where we converted browse, checkout, login and other end user portions to a module, but left the Content Owners administration as it was, in a separate asp.net application.
This gives our clients a DRM application with all of the DNN forums, news, and other modules. We do not see an immediate need to convert the back-end administration. We’ve done the exact same thing with real estate and lending applications.
None of these systems are converted enough to sell as DNN Modules, however, they will eventually get there. In the mean time, we can offer our clients the benefit of DNN with our custom systems.
We’ve also realized that many of our applications are not worth trying to keep current and it makes more sense to use the modules in DNN. When we need a specific feature not in a module, we will alter the code and offer it back to the community. This makes more sense. After being in the business for 12 years, it seems that a small company needs to be more specifically focused on a particular niche to stay competitive. DNN enables us to attempt this.
After being involved with DNN over 6 months, the positives have far outweighed the negatives.