Modernising legacy data can also be fraught with the potential for data corruption and loss with catastrophic implications through not only the risk associated with the data migration, but also through the required changes to the application, which in many cases have been running for years, or even decades without change.
Many project managers get more nervous about touching the application code, especially since many time the original authors have long since retied. So anything that can eliminate, or minimise application code changes, is often of great interest.
To avoid these shortcomings, companies should consider database modernisation in a phased migration process before tearing down their old databases, or even consider an approach whereby they can bring support for modern APIs over the legacy data without requiring application changes.
Although modernisation projects are rarely seamless (the industrial revolution, anyone?), it is important to take the time required to perform testing before going live. Meanwhile, there should be the option of a rollback strategy set up in case the deployment runs into hiccups – this will make sure business continues as usual.
TRP: How do you evaluate the total costs related to using a database as part of an application, including upfront costs, management costs and hardware (or cloud) operational costs?
RH: Frequently, the initial cost analysis focuses on licensing fees (or in the case of some Open Source databases, avoiding license fees), along with the cost of implementing and then managing and maintaining the database.
It's important to factor in the implementation and integration costs up front, along with the ability to add additional functionality and support for standard APIs to support future integration as well.
Some databases require constant maintenance, while others can be configured, deployed and then operate with minimal or no maintenance, which should be factored into the initial deployment decision.
Some databases are much more efficient with processing and storage resources. Clearly the more efficient database architectures can reduce hardware, processing and/or cloud operational costs.
TRP: For websites that handle transactions, is it better to have one database to handle transactions and another to capture and analyse customer data, or can it all be handled by one database? What's the best way to calculate the best value?
RH: This type of deployment offers another great example where more than one database architecture is appropriate. For example, an online retail website may need an ACID-compliant SQL or NoSQL database to process purchasing transactions, which are mission critical. At the same time, the portion of the website that handles customer reviews and comments does not require the same level of consistency.
