How to determine web application end of life? [closed]

Question

This question could bring a lot of opinions to the table, but what I will like to get is a set of measures that will help me and my company determine the end of life of a product that we sell.

We sell a CMS system, with this system we create a few sub-products

• Websites
• Proposal Creator
• Marketing Campaign Tracker

We are ready to start our road planning (for 2010 and 2011) and we are trying to figure when will be the end of the life of our application. Some of you might think that a very well architected application (I don't think our application is well architected) does not need to have an end of life, but this app that we are using goes back at least 6-7 years and has almost no documentation (real life). At this moment only ONE person knows how to change core functionality (scary).

Please advice,

Geo

---

Thanks to All! I really appreciate your comments, opinions and thoughts on this topic.

I will address a few of the post back questions in the list below

• There is one developer that is able to maintain the core functionality of our product. (only and only one)
• There are two developers that are able to increase functionality to a certain point. Both developers are constrained by the limitations of the core product, and they both have to work within those limits.
• A very important note. The product that we are considering to put to end-of-life is for the most part being built by a contractor. The contractor is the only developer able to maintain the core functionality. We only develop on top of the contractor framework.

I will keep adding answers while I read you all responses.

Answer 1

Since application is very well architected you may not want to retire it and loose all investment you have made to date.

Here are my suggestions:

• Have a junior developer join this current developer.
• Dump most of future updates on junior developer (with assistance from sr. developer)
• Ask junior developer to do the documentation of his work
• Ask Sr. developer to review documentation

Over period of time, you have another person who can support this application and it will be documented as well. Now you won't need to kill your own very well architected application with your own hands.

.

Extending this solution with Jefferey suggestion below("Sometimes rewriting is a good investment.")

If you still want to drop current application and re-write it, you still need to document existing system and create requirements for new system based off it.

Using documentation of current and proposed system, you may want to see if you can incrementally module by module upgrade (re-write) components. This is possible if application is very well architected.

---

As per your (Geo) comments

Geo's organization has custom third-party (with one and only one contract developer) CMS application that implements below business requirements and is paying licensing fee for support and use of his code.

• Business requirements for CMS
• Websites
• Proposal Creator
• Marketing Campaign Tracker

Here are my suggestions

• Create module by module detailed use case document for this project. Your developer can do this or would be ideal to have a seperate business analyst for same.
• Hire a Sr. Developer to evaluate if open source CMS can handle all or most of your requirements (e.g. Joomla, Drupal, etc.).
• Most important thing here would be ability to migrate your existing data to new system. You may need help from your existing contract developer to do this.
• You may have to update business process or workflow to use new system.
• Modules that cannot be implemented using open source CMS may be required to be implemented using custom website.

Much of it also depends on your business relation with existing contract developer and license agreement. What you are facing is a vendor lock in scenario. You may want to further research on solutions to eliminate this vendor lock in situation.

Answer 2

This is just my opinion, but if this is a product that you are selling, then it all boils down to business prospects. If the product doesn't sell, then drop it. If the product has a future, then invest in it, and make it the best software you can by refactoring, rewriting, or whatever you have to do. If you have loyal customers or a strong brand, then that's worth protecting.

Sometimes rewriting the whole thing in another technology is a good investment, if the current software has a successful design that can be copied, has a strong brand, and if it can be done right.