At work, we have a software written in PL/SQL - Oracle Forms 10g, which runs the software as a Java Applet.
My Company bought the software and we have to develop the software, but we feel that Oracle Forms 10g Technology with Java applet is out of date. It's a technology from the past decade and we must move the software to a different platform (ie. Web or some other platform).
Is this a good or bad idea? And why?
Unless you give technical reasons why you're not satisfied with the current solution, and unless you evaluate the financial side of the rewrite, all you will get here be opinions based on nothing but personal preferences. Which is, needless to say, something no business decision should be based on in general.
Edit: To elaborate a bit on the already said, generally the process of decision of a rewrite goes like this (in this order):
1. What's wrong with the current solution? Is there a list of real problems with it? Performance? Client asking for features different to implement, if at all possible? Or are you just unsatisfied / bored with the current technology (this is an often case with technical staff who want to work with the new technologies).
2. What does the current solution "depend" on? Proprietary technologies? Are there alternatives to those in language B (in which you wish to rewrite it). Is it possible to do a rather direct rewrite of codebase or will a large part of it need to be differently structured (architecture wise).
3. Is the current staff familiar with language B? If not, is there enough available staff in the area where your company resides? Commercial support for language B - does it exists? (Do not rely on communities of volunteers for long term projects; they go from one technology to another as their interests change. For a let's say two decade application lifespan you need solid grounds in terms of commercial support.)
4. How many clients depend on the current solution? Your costs of their transfer (you'll have to provide technical support) to new solution? Costs of giving support for how many years to those that have not upgraded?
5. Financial analysis of the whole thing (this is best done by someone from the managerial level; take it as a fact that if there is one thing they value and know how to estimate it is costs.)
I deliberately avoided specifics here since you didn't gave many in your question. Also there is probably more which I forgot to mention ... but it's 2am in my part of the world and I'm starting to get ... zzz <-- sleepy
Honestly, you need a far better justification than "We feel it's out of date" to justify spending the amount of money it will cost. What are the problems with the current incarnation?
While I agree with all the fellow programmers, I also need to introduce less tangible but nonetheless important aspects to this situation. Software development is relatively young discipline and it changes fast, really fast. What's the average age of your dev team? 45? Imagine hiring college grads to work on your stack, do you foresee any difficulty? Is your current stack conducive to rapid development and short iteration cycles? Do you have unit and integration tests? Is it even possible to have them with Oracle Forms? Is your dev team excited (not in hubris and/or wild west sense though) to come to work and augment the system? At this time you know your system and underlying requirements much better than you did at the inception stage. Would you still go with your current stack? Are there significantly better tools and products available now to achieve what you need in a more economic and pragmatic way?
This is just a food for thought. If you do embark on a re-write then do yourself a favour: try to make it as iterative as possible and resist the "big bang" approach. I speak from experience.
Generally speaking, it's best to avoid making such decisions based on feelings. Just because the technology is old does not mean that it should be replaced. Old technology tends to be proven technology. The question usually boils down to the costs involved.
You need to determine what issues you are having with the existing solution and how much that is costing the business. You need to determine how much it will cost to rewrite it. Compare the two and use that to help you make the decision. (Note that not all of the cost is necessarily in terms of money or can be easily quantified. So, this isn't exactly an easy comparison to make.)
Rewriting software tends to take longer and cost more than actually anticipated. Also there is no guarantee that it will actually be better than the existing solution. Don't take my word on this, Joel Spolsky blogged about why rewriting software from scratch is a mistake a long time ago.
So, if possible, an incremental approach should be taken. Rather than scraping the whole thing and starting over, make changes slowly and migrate the solution to newer tech piece by piece.
The short answer to this question, imho, is no. You should seek out existing solutions, be it open source or commercial. I've sat in meetings with developers and heard them utter statements such as "I think technology X is utter garbage, I could write a better product than that!". The truth is, they probably can, but are they in the business to be rolling out their own frameworks? Writing stuff from scratch should be a last resort, unless it's some esoteric domain where existing software solutions are scarce.
It's a technology from the past decade and we must move the software to a different platform (ie. Web or some other platform).
Looking at this, it sounds as though your company has recognized there is heavy baggage associated with the product it is using and that there is a desire to move to something else. It also seems as though you are indecisive about what platform to move to, so you need to take a step back and think about your customers, what their use case scenarios are and then consider what platform/medium would be the best approach to deliver a revised form of what you have currently.
