Anything that’s born will age. Some by minutes, some by years. But age they will because that’s the rule of nature.
This bears the question: Does age equate legacy? In most cases, it could though not necessarily for things in the IT sector.
Legacy in the IT and systems-related world is a term which implies systems that function either with very little or no support which keeps it up to face the latest work-related issues including security. Typically, in the IT industry to which this term applies, a system is anything but legacy if there exists an elaborate system of updating and overhauling the present set-up to face up to the latest issues, threats, and work-related demands. Given that legacy has everything to do with back-ups and patch-ups and little to do with age, there are systems which despite age work beautifully due to constant upgrades like most Windows products while there still exist those which though of recent vintage are put in the category of the legacy given its inability to either upgrade itself or align itself with other surrounding software products. No product can be termed legacy from the word go because it’s with the time that things start to unravel. A good example of what happens when faulty systems go un-noticed or unreported is the 2015 case of the US Prison system where it was discovered that close to 3500 prisoners had to be released early due to an anomaly in a patch introduced in 2002 which calculated prisoner’s sentences depending upon the latter’s behavior while being imprisoned. The problem played out for 13 years before a new person at the helm brought it to the notice of the Governor’s office for necessary changes.
Typically, new systems don’t suffer the issue of patches and glitches which become obvious with time. To that extent, legacy does point towards age and not for any other reason.
On the need for re-engineering old legacy platforms versus buying anew, the following points should form one’s standpoint:
Does legacy software equate to uselessness?
Not necessarily, and more so, if its owners have pumped-in large sums of money to keep it afloat. Unless the apparent “uselessness” necessitates a complete shift across systems, a legacy system need not always be dumped in its entirety. That said, there can be a need to shift wholesale when the technology so dictates. Servers for example. At one time, one had to own and maintain them like a holy shrine. And then came the cloud which totally blew away the need to self-own and maintain structures while giving better output under a SAAS-HAAS configuration. The decision may depend upon whether costs first incurred have been recovered and to what extend an existing system can be rejigged to new circumstances.
Has the owner of the legacy system taken its money’s worth?
Systems, legacy, or otherwise are expensive affairs to invest in and keep them up to performance levels. A system should ideally be termed legacy in monetary terms, the owners under a system of fixed amortization recovered its worth and are in a position to re-invest the same in a better system. Financial calculations apart, legacy systems can sometimes be an organization’s most prized possession in terms of money given the amount invested in them, and it could make more sense to invest in its regular upkeep than a complete shift-out. On the other hand, if these are proprietary systems with all resources in-house, the chances of buying/ replacement could be a relatively painless affair.
Is support for a legacy system of a certain quality easily available at reasonable costs?
A system is technically declared a “legacy” where support for its upkeep including timely patches is either not available or can be made available only at excessive costs. Under both these cases, an important system can bring an organization to enormous grief. Important information can either be lost forever or land-up in undesirable hands. It thus makes sense to move on to a new system where the existing one either has no back-up or expensive and/ or unverifiable ones with little guarantee of performance.
Is the use of existing software (the legacy software) dangerous to an organization’s existence?
Imagine the case of a nuclear powerplant operating its reactors on aging platforms which shows or has potential tendencies of slipping once in a while. A truly dangerous situation that should be immediately be rectified either in entirety or at least those parts which can mitigate an outright disaster. Compare this with another software handling the same complex’s canteen needs. Despite being old and creaky, one can still use it because it really does not pose a threat to lives.
What is the level of pain one would feel when replacing a legacy platform?
If the legacy platform forms the central system in an organization or a substantial part of it, enormous pain will be felt if anything sudden is attempted. To reduce the same, it would make sense to first plan out things on a schedule and then take relevant action- if it has to be taken in the first place. Enormous data may need to be shifted from one system to another with the latter taking its own time to settle and respond. The question of re-engineering versus buying may have to take into account what causes less pain, how often, and for how long.
In the end, after asking and answering all the above questions, one should also do the following:
Consult in expert about how legacy platforms can best be handled and if there’s a chance of reviving the element of support- taking cost and time into consideration
Do a thorough study of alternatives available including the use of HAAS and SAAS and other such alternatives that may arise- taking into account costs likely to be incurred and results likely to be derived
Do a study of existing and likely road-blocks and weaknesses within the organization vis-à-vis existing legacy systems and the likelihood of them remaining where an alternative is found.
In the end, the decision is to re-engineer or buy afresh could be a very subjective one given the number of considerations to be taken into account. That said, a decision sometimes HAS to be made. With that being the case, a thorough, studied decision-taking every angle into account ought to be the case. Haste shall otherwise result in substantial waste.
Microsoft Power Platform App Maker
Designing & Implementing Azure AI Solution
Microsoft Azure Administrator
Developing Solutions For Microsoft Azure
Microsoft Azure Architect Design Exam
Implementing Azure Data Solution
Administering Relational Databases On Microsoft Azure