Suppose we have a system (in production) written in an obsolete technology and difficult to adapt to changing business needs. The decision has been made to rewrite it in a newer technology. Should we start fresh with a new database schema that will accurately reflect the data models of the new system but accept the risks and costs of developing a database conversion (necessarily 2-way due to a phased implementation plan)? Or should we keep the same schema, even though it will complicate development since it does not reflect the new model, but gain the advantage of eliminating the conversion task?
Suppose we have a system (in production) written in an obsolete technology and difficult
Share
As a developer and application maintainer, getting to start over with a new schema and an application rewrite is a dream that is not realized often. Given only the information in your question I would tend to go for the new schema and the conversion work.
BUT…
There is a ton of missing information needed to make the correct decision. Like: How will the decision effect the budget and/or schedule? What are the problems with the current schema? etc.
SO…
As a project sponsor and business analyst, I want the cost justified by having a good return on investment. Remember, any time and money spent on the new schema is time and money that could be used for features or other projects. Some questions to ask your self when looking at it from this point of view are: Will the new schema reduce maintenance costs? If so, how much? Will the new schema give us an advantage by giving us the ability to add the next set of features faster? Is there some inherit limitation of the old schema that is keeping us from meeting goals? Will the new schema provide performance gains that will lead to more satisfied customers? etc.
I’m afraid the whole picture is needed, and even then once you choose a road you will never know how it would of turned out had you made a different choice.