“I want to leave a legacy behind that is undeniable” – Samy Zayn
Also said every IT manager ever, when implementing a new technology. Does this sound eerily familiar with the situation at your organization also? Dealing with hidden nuggets of undocumented applications being used on a daily basis for business-critical functions?
Technology managers tend to think that the spanking new systems they implement will outlast humanity – or at least the organization. Ok, at least their tenure at the company.
Legacy Software is software that has been around for at least a few years, and serves a business function. It is frequently tied to the Operating System version & Hardware version, both of which are deemed out of active support by the respective vendors.
The truth is that traditional technology products have to deal with a product life cycle. Software vendors continually launch newer versions of the application using renewed technology stacks & new features. Older versions must be retired – because they become too expensive for the vendors to maintain.
With Cloud Application penetration, that is one problem which is rapidly disappearing. Cloud Apps like Gmail, Salesforce, Kriya, Greenbox, Trello, etc tend to stick around as long as they are relevant & they can find paying customers. Gmail is a teenager now, and is at the height of its adoption – showing no signs of slowing down. Salesforce turned 20 in 2019.
Dealing with Legacy Applications has its own challenges. Replacing obsolete versions of MS Windows (XP, anyone?) with the latest flavour of Windows is a relatively straightforward task. On the other side of the this-is-easy to this-is-hard curve, is replacing a custom, home-grown ERP solution – developing using C/C++, FoxPro, VB6 or similar now-defunct technologies. Between these two extremes lie the many utilities developed using legacy technologies – cost estimators, document storage systems, business logic ‘nuggets’, MS Excel sheets etc.
The challenges of modernization lie because the Legacy App owner has typically moved on. If not from the company, then at least from the role.
So, why do companies continue to use & extend ‘Legacy’ Apps?
OK, a brand new system is not necessarily a ‘Legacy’ App the day it is built. It is definitely headed in that direction the day it goes live – it is a matter of time.
Organizations continue to use legacy applications due to a multitude of reasons.
Legacy Apps aren’t plug-and-play. Today’s popular choices of Microservices architecture, multi-tiered architecture, or even a client-server architecture are results of teams struggling to manage monolithic legacy applications. Modern application architectures are built to solve specific problems, and then fit in a larger architecture as a piece of a puzzle. These pieces are designed to be inherently replaceable (and hence modernize-able) at any time without causing risk to the entire software solution.Gartner predicts that every dollar invested in digital business innovation through to the end of 2020 will require enterprises to spend at least three times that to continuously modernize the legacy application portfolio [source: www.gartner.com].
Legacy applications tend to become, well, a legacy of a large code base and business logic. Even a small update to the source code may result in conflicts across the application that may lead to unpredictable and typically unwanted issues. When taking on a modernization project, you will face the challenges below.
You will need to hire industry experts to apply even the slightest changes to the application. Experts that have worked with your technology stack & are still accepting work are hard to find and also very expensive.
The systems on which legacy applications are built are aged and hard to maintain. Many times the underlying Hardware and/or Software infrastructure is no longer supported by the vendor. Sometimes, the vendors no longer exist as a legal entity. This is true especially when dealing with custom built software.
Legacy data is frequently found in proprietary file-based database structures. Documentation may also not be available. Legacy applications were not developed to be integrated with external systems, and APIs are also not available.
Migration of such legacy data is difficult, but usually possible by writing scripts to extract, transform and load (ETL) the data to the newer systems.
Modern technologies integrate well with other applications, as they rely on API platforms for communication. This is not the case with legacy applications that need coding-level changes to be able to integrate with other applications. Most ageing applications have batch-based integration strategies implemented.
Legacy Applications developed many years ago are frequently left without adequate documentation. Documents are frequently misplaced, or in an archived mailbox – instead of a shared repository on a Cloud based Document Management Document Management Systems (or Document Control Systems) like Greenbox. And many times, these documents are also outdated.
When faced with the task of modernization, the choice of approach is usually based on the problem statement – what type of modernization is required?
There are several approaches to modernizing legacy applications. Here are the most popular methods for modernizing legacy applications:
An upgrade to the latest version is an option – if you must stay with the same vendor. Usually, the Vendor will provide a migration path to the latest version, including all data from the prior version.
In case the data cannot be migrated, the legacy application, along with its data can be kept in a virtualized environment on a Cloud provider such as AWS, a provider of cloud computing services, for future reference.
This is the approach that is recommended for systems such as ERPs. It is near-impossible to port legacy ERP data to modern ERP data from a different vendor such as SAP.
Where possible, it is best to pick a Cloud-based tool such as Kriya that can withstand the test of time to recreate business processes. This also gives the hidden benefit of re-thinking business processes to make them more efficient.
In cases where the legacy data needs to be carried forward, choose a configurable off-the-shelf application that has strong import capabilities & API.
This approach is also recommended for document management systems. Digital records can be scanned & re-indexed using a system such as Greenbox, giving the additional benefit of making the entire document data set searchable.
Sometimes, it is not the application that you wish to update, but the underlying host infrastructure. Use cases include –
Embracing a Cloud provider will resolve points #2 & #3. For #1, AWS allows virtualized instances of legacy OS & DB setups. This is a stepping stone to reduce immediate risk of failure, before planning an upgrade path.
Many legacies are built when companies opt for in-house development teams. An army of 10-20 developers can easily generate millions of lines of code over a course of a few years.
If this seems familiar, it is best to take a step back and look at the current application landscape. Specifically, ask these questions:
Applications that have not been accessed in the past one year are probably never going to be used/accessed and can be safe candidates for deprecation.
Port those applications that are adding value & structure to the organization.
Choose those which have minimal use, or are created as an exceptional business process to an existing process.
Choose the applications that have the highest volume and criticality to the business users. Is an app used for estimation or sales order preparation? Is one used for label printing?
The idea is to ensure that BaU is not impacted in any way, and, where possible, become simpler & more efficient.
This will quantify your effort of migration to a modern landscape. Next step – choosing a Cloud platform on which to migrate. You can read how to choose a No-Code platform here: How do I choose a No-Code platform?