Why Software Systems Become Legacy

SOFTWARE DEVELOPMENT

If you have spent any time in the soft­ware in­dus­try, you would have heard of the term ‘legacy sys­tem’. All soft­ware sys­tems be­come legacy sys­tems at some point. In this ar­ti­cle, we will dis­cuss why this hap­pens but first, we need to de­fine what ex­actly a legacy sys­tem is.

What is a legacy sys­tem?

Depending on who you ask, you may get dif­fer­ent an­swers to this ques­tion. However, a pop­u­lar de­f­i­n­i­tion of a ‘legacy sys­tem’ is a soft­ware ap­pli­ca­tion that has be­come ob­so­lete and is hard to up­date or main­tain. The legacy ap­pli­ca­tion could still be work­ing fine or is maybe just a lit­tle slow, while still per­form­ing its ba­sic pur­pose.

We have a dif­fer­ent opin­ion. Imagine you buy a swanky new car from the show­room. The mo­ment it’s out on the road it starts to be­come ‘used’ or ‘old’ and starts los­ing value. We be­lieve soft­ware sys­tems are the same. As soon as they are de­ployed, legacy starts to set in. This is ap­plic­a­ble to any off-the-shelf (OTS) soft­ware, cus­tom-built soft­ware, or any com­bi­na­tion of the two.

But why does this hap­pen?

Well, as men­tioned above, there are many sce­nar­ios in which sys­tems be­come legacy. Here are some ex­am­ples:

  • The de­vel­op­ment team who built the sys­tem are no longer with the com­pany and there is a lack of proper doc­u­men­ta­tion. This leads to a lack of knowl­edge, which in turn can cause is­sues with main­tain­ing or up­grad­ing the sys­tem.

  • End of life soft­ware/​frame­works were used and are no longer sup­ported. A sim­ple ex­am­ple of this is Windows XP or Angular JS 1. Now, if your soft­ware sys­tem was de­signed for an older ver­sion of Windows op­er­at­ing sys­tem (OS) and Microsoft has stopped sup­port­ing that OS, you would need to up­grade your soft­ware sys­tem as well for it to con­tinue to run.

  • Off-the-Shelf (OTS) en­ter­prise soft­ware that you were us­ing is not sup­ported be­cause the com­pany was ac­quired or has been shut down. Imagine a small Customer Relationship Management sys­tem that is ac­quired by a gi­ant com­pany that de­cides to slowly close a part of their busi­ness down and tells you to mi­grate to their plat­form.

  • Aging tech­nol­ogy with ob­so­lete ar­chi­tec­ture, such as on-premises data­base servers, might no longer be de­vel­oped or main­tained by the ven­dor. Financial in­sti­tu­tions are a fan­tas­tic ex­am­ple of this sce­nario. A bank us­ing an old bank­ing ap­pli­ca­tion based on a lo­cal data­base would need to move to a cloud-based ar­chi­tec­ture in or­der to mod­ernise its op­er­a­tions and cus­tomer ex­pe­ri­ence.

Similarly, there could be other rea­sons for a sys­tem be­com­ing legacy, such as re­sis­tance to main­tain­ing and up­dat­ing the soft­ware. A func­tion­ally re­silient sys­tem might still be work­ing fine but may not be able to de­liver the per­for­mance or ex­pe­ri­ence for mod­ern cus­tomers and users. Think of how fre­quently your busi­ness changes. To pre­vent your soft­ware from be­com­ing legacy, it needs to change with your busi­ness. The old mind­set of “If it ain’t broke, don’t fix it” is not help­ful in the long run.

How do you deal with legacy sys­tems?

Beyond turn­ing a blind eye to the prob­lem, there are mul­ti­ple ways in which you can mi­grate to a mod­ern sys­tem once you rec­og­nize that your soft­ware sys­tem needs an up­grade. Here are some do’s and don’t’s for your legacy mi­gra­tion. There are typ­i­cally two op­tions for mi­gra­tion:

The first op­tion is you re­plac­ing the legacy sys­tem with an OTS so­lu­tion al­ready avail­able in the mar­ket. It could be buy­ing a new ho­tel book­ing sys­tem, POS soft­ware or a mod­ern in­ven­tory man­age­ment sys­tem. There are risks with this ap­proach. While the ini­tial cost of these sys­tems might be lower in the case of a SaaS prod­uct, the cost to cus­tomize it could be high, or al­ter­na­tively, the cus­tomi­sa­tion might be im­pos­si­ble. The queue to fix bugs could be very long due to the large back­log for these sys­tems and you could be­come ven­dor locked.

Another op­tion is to have a cus­tom soft­ware so­lu­tion de­vel­oped for your spe­cific needs. If you need some­thing spe­cific to your busi­ness process which is not avail­able with an OTS prod­uct, or is a niche re­quire­ment to your busi­ness, you can have the sys­tem cus­tom de­vel­oped for you. Based on the com­plex­ity and the num­ber of fea­tures you need, the ini­tial cost could be higher than an OTS prod­uct but you would also have a higher level of cus­tomi­sa­tion and you would own your IP.

But here comes the co­nun­drum, the new sys­tem would be a legacy sys­tem soon enough as well. Even if you have used the lat­est and the great­est tech­nol­ogy or meth­ods to build the new sys­tem, they will need to be up­graded in fu­ture. So how do we break this cy­cle of legacy sys­tems? The short an­swer is tak­ing the ap­proach of con­tin­u­ous mod­erni­sa­tion.

Here at WorkingMouse con­tin­u­ous mod­erni­sa­tion is our bread and but­ter. So, if it sounds like mod­ernising your legacy sys­tem is the right fit for your busi­ness, be sure to sched­ule a free prod­uct strat­egy ses­sion with us to­day.

Discover Software
Secrets

ABOUT THE AUTHOR

Shivam Arora

Account man­ager and hik­ing en­thu­si­ast

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

Migration vs Rebuild

12 November 2018

The top tech­nol­ogy frame­works you can use to build a mo­bile app

21 January 2020

How does end of life soft­ware im­pact you?

10 November 2020

Your vi­sion,

our ex­per­tise

Book a con­sul­ta­tion