New digital technologies are designed for mobile devices, the cloud, and in-house databases. They offer a wide variety of opportunities for business today. Unfortunately, they are often completely incompatible with older, legacy database systems, and this incompatibility can make an organization slow and plodding, comparatively speaking, rather than efficient and useful. While new technologies can help businesses improve efficiency and save significant amounts of money, the legacy database systems, which cannot be easily replaced, act as anchors, keeping businesses from moving forward.

In some situations, legacy data must be saved for legal reasons. Specific types of data, such as health or insurance related information, may need to be saved for 10 to 30 years. While this kind of information can be saved in a hard copy format, many organizations find it easier to store it electronically.

Generally speaking, a legacy database is an older, outdated database, but when speaking of a specific database it can also refer to a system inherited from previous owners. These legacy databases typically contain huge amounts of useful information about repeat customers, and a considerable amount of the business’ history. The sacrifices made in maintaining the legacy database include:

• Minimal flexibility: The development of applications and software for legacy databases is typically nonexistent, and blocks the evolution of an organization.
• No support: After a certain amount of time, software and hardware becomes so obsolete, they can no longer be repaired or replaced.
• Wasting of time: The inefficiencies and poor performance of old applications will slow down a business’ processes. Also, obsolete software offers a higher crash-risk.
• Increased security risks: Legacy databases are not designed to meet modern-day security requirements. They become more and more vulnerable to security breaches with each passing moment. (Think Colonial Pipeline’s ransomware attack, and their obsolete legacy security.)
• Incompatibility with new technologies: The legacy database cannot be accessed by mobile devices and is incompatible with modern apps and tools.

The easy, short-term solution is to simply throw out the legacy database, along with all the old data it contains, and replace the system. If the information contained within the old database is of little or no value to the organization, this decision would make sense. However, if the bulk of the information in the old database is needed and useful, that short-term solution becomes a bad idea.

Efforts to gain at least some of the advantages offered by new technologies, without losing a very valuable legacy database, may lead to clumsily operating both the legacy database and a new database, separately and simultaneously, with no integration. The new database cannot access the legacy database, primarily because of software incompatibilities. Generally speaking, however, merging the legacy data with the new system would result in greater efficiency.

Stefan van der Zijden, a research director at Gartner, stated:

“Application modernization is not one thing. If you’re faced with a legacy challenge, the best approach depends on the problem you’re trying to solve. Replacement isn’t the only option. The key is to understand if your problem is caused by technology, architecture, or functionality of the application, and how each modernization approach improves those aspects.”

Research indicates four possible options for saving legacy data, or updating a legacy system:

• Upgrading the software
• Transforming the legacy files to a generalized, printable format
• Transferring the data to the cloud with a virtual machine copy of the data
• Replatforming, or building new architecture, from scratch, on the legacy system

Red Alert! The Legacy Database Is About to Die

The IT person tells management the legacy database has maybe another month before it completely crashes. This is bad news for management. The database has a huge amount of valuable data that needs to be transferred somewhere for purposes of storage, until a solution for transforming and transferring the legacy data to the new system can be found. Simply losing the data, which contains information that must be saved for legal reasons, and/or contains valuable customer information, would damage profits, and is unacceptable.

Two options for saving the legacy data in an emergency are: 1) transforming the files into a generalized format (such as PDF, Excel, TXT) and storing the new, readable files in the new database, and 2) transferring the legacy data to a VM copy of the legacy database, which is supported by a cloud. 

Thomas Griffin, of the Forbes Technology Council, wrote “The first step I would take is to move all data to the cloud so you’re not trapped by a specific technology. Then you can take your time researching the new technology. Find out what competitors are using, and read to see what tools are trending in your industry.”

The Questions to Ask Before Going any Further

Before making any changes to the legacy database, define the specific problems that are happening.

Performing a needs assessment can be done in three steps:

• Assess the business value of the legacy system
• Assess how satisfied customers, partners, and staff are with the legacy software
• Assess specific applications. What problems are its users reporting? How much time is wasted by staff working with these apps, or lack of apps?

Upgrading the Software

It is possible the legacy database can be upgraded with purchased or rented software (it may be necessary to use two or three sequential upgrades), allowing it to then be merged with the new database. Some fairly intense and dedicated research might be required to find the needed upgrades (if they exist).

ModernSystems has an intriguing patch/upgrade system (described as a tool-assisted reengineering process) that alters an existing application so it can be used on a legacy database management system. While the legacy database will still need to be replaced, eventually, the installation of modern apps could transform the legacy database into a “new,” more efficient system.  

Transforming Files to a Generalized Format

Docshifter provides a solution that automatically converts any source format to other formats. Their software supports over 300 file formats, which include Word, Excel, HTML, XML, PDF, PDF/A, TXT and many, many others. It is automated, transforms the files in bulk, and is very easy to set up.

If the data is being stored for several years as a result of legal responsibilities, this process may be all that is needed. If, however, the data is needed for day-to-day usage, there is a high probability the pertinent data will have to be transferred manually to appropriate locations in the new database (old accounts being transferred to the new Salesforce software on the new database, etc.). Depending on the amount of data, that may be reasonable. If it could be accomplished with 80 hours of labor, two people working for a week could complete the project in a cost-effective manner.

Transferring the Data to a Cloud Supported Virtual Machine    

Virtual Machines imitate other operating systems and applications. They can be used to replace failing legacy databases, allowing for the transfer of legacy data. The imitation of a legacy database, and the transfer of data may not be easy. There may be problems imitating the legacy system. There may be problems with APIs (application programming interfaces). And once the decision to use the cloud has been made, and the contract signed, the organization will now be billed for those cloud services. (That may not be a bad thing. There are many eCommerce tools available on the cloud.)

Once the legacy system has been moved to the cloud, it may be possible to upgrade it (perhaps using two or three sequential upgrades) to the point where the data can be transformed into a format the new database can read and work with, in turn allowing the transformed legacy data to be downloaded to the new system.

Replatforming

Replatforming is generally described as upgrading applications/software. It is often used to upgrade a system so it can be moved to the cloud for eCommerce purposes. In terms of replatforming a legacy database, this means starting from scratch with the legacy system, and creating/writing new applications for it, without changing its core architecture. In essence, a new database is created. If done well, this solution could be used for several years, allowing for easy access of legacy data and supporting the installation of new modern apps.

Michael Coté has written an article describing rewriting the software/apps, and code, titled Crafting Your Cloud-Native Strategy. This is not for the inexperienced.

Warning: First, the problems created by a bad replatforming would be significant. Second, replatforming projects can expand/balloon significantly in scope, reaching the point where the architecture is being changed, which becomes very expensive. The DevOps team should minimize code-tinkering and stay focused on simple upgrades.

ModernSystems offers a replatforming service for legacy ADABAS systems, a database package launched in 1971for IBM mainframes. Others include Clockwork and BairesDev.

Image used under license from Shutterstock.com