“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?
Why do organizations continue to use & extend ‘Legacy’ Applications?
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.
- Risk of failure – The fear that recoding the entire software on modern technologies is risky. In reality, the cost and risk of continuing to use legacy applications are far more than the option of modernizing the software.
- Risk of loss – What if the project of modernizing Legacy Apps fails? In reality, the hidden costs of using legacy systems are mainly in the area of maintenance and break-fix support.
- “If it ain’t broke, don’t fix it” – Why put money behind something that has worked for the past few years? This holds true until the day that the software Vendor says that your solution is out of support, and will no longer be given upgrades or security patches. In fact, for out-of-support Legacy Apps, even breakdowns are no longer attended.
- Sunk Cost Fallacy – “We’ve already invested so much into this app, that investment will go down the drain”. Actually, the modernization plan should be designed to reduce risk & Total Cost of Ownership (TCO).
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].
What are the challenges of updating Legacy Applications?
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.
Skilled Manpower
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.
Infrastructure
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
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.
Integration
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.
Documentation
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.
Modernization of Legacy Applications
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:
Upgrade to the latest version
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.
Port the functionality to a new Application
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.
Lift-and-Shift migrations
Sometimes, it is not the application that you wish to update, but the underlying host infrastructure. Use cases include –
- Older versions of Database (Oracle, SQL Server, MySQL, etc) – these are easy, since database export & import functionalities are fairly stable & provided by all vendors.
- Out of date Operating System (Windows, Unix, Linux) that are now out of support – can be tricky, due to many factors including serial keys & installation media
- Ageing and out of support hardware (Servers typically come with a 5-year life span)
- Reclaiming real estate – embracing a Cloud strategy
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.
Choose a No-Code solution to recreate your applications
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:
Which applications are under active use?
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.
Which applications should be ported to the modern landscape?
Port those applications that are adding value & structure to the organization.
Which applications should be scrapped, or absorbed into another process?
Choose those which have minimal use, or are created as an exceptional business process to an existing process.
Which business applications are required, in terms of immediacy & priority?
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?