SOFTWARE DEVELOPMENT

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

One of the great­est mis­con­cep­tions in soft­ware de­vel­op­ment is that a soft­ware pro­ject is a one-off un­der­tak­ing. As we’re about to dis­cuss in greater de­tail, the in­dus­try is very sim­i­lar to many oth­ers. You would­n’t ex­pect a house built in the 1700′s to still be stand­ing with­out proper main­te­nance. Software is sim­i­lar in many ways, ex­cept the in­dus­try changes at a much faster rate. This ar­ti­cle will fo­cus on end of life soft­ware and the risks that it poses to your busi­ness and your cus­tom soft­ware ap­pli­ca­tion.

What is end of life soft­ware?

For ex­am­ple AngularJS 1 stopped ac­tive de­vel­op­ment as of June 30, 2018. It is now in long term sup­port mode un­til the end of 2021. This does­n’t nec­es­sar­ily mean AngularJS 1 was­n’t a pop­u­lar frame­work. In fact, they have since de­vel­oped a fur­ther 10 ver­sions of Angular (at the time of writ­ing Angular 11 is cur­rently in de­vel­op­ment). It just means that the frame­work has evolved and Angular chose to cre­ate a new frame­work over adding com­plex­ity to an ex­ist­ing one.

Technology that has gone end of life should not be taken lightly. There are a few key risks that we’ll break down in fur­ther de­tail be­fore as­sess­ing what the op­tions are for peo­ple us­ing end of life soft­ware.

What are the risks of end of life soft­ware?

Security risks

The key rea­son to up­date soft­ware that has gone end of life is to mit­i­gate se­cu­rity risks. Once some­thing has tran­si­tioned to EOL, the ven­dor is no longer re­leas­ing se­cu­rity fixes for it. This pre­sents a se­ri­ous risk that hack­ers could breach your ap­pli­ca­tion through an un­patched vul­ner­a­bil­ity.

Outdated skills base

Developers are gen­er­ally in­ter­ested in lever­ag­ing the newest and great­est tech­nol­ogy. Once some­thing has gone end of life, it has long passed this state. This may mean there is a re­luc­tance for ex­ist­ing per­son­nel to learn the tech­nol­ogy or for those that know it, to con­tinue to use it.

Poor per­for­mance

By re­main­ing on age­ing tech­nol­ogy there is a strong like­li­hood that is im­pact­ing the per­for­mance of your soft­ware or hard­ware. Consider the old dial up in­ter­net mo­dem (circa 2008). How long did it take to con­nect to the in­ter­net? I still re­mem­ber the tune it would play as it con­nected. Now we’ve be­come ac­cus­tomed to in­stant ac­cess to the in­ter­net. This is the same for soft­ware frame­works. Applications built us­ing a mod­ern .NET Core 3.0 frame­work per­form bet­ter than the sig­nif­i­cantly older .NET 2.0 frame­work.

Incompatibility

If you’re us­ing an end of life op­er­at­ing sys­tem, the chances are you won’t be able to ac­cess the most re­cent ap­pli­ca­tions. This cir­cle of in­com­pat­i­bil­ity can spi­ral un­til you’re left us­ing a suite of EOL sys­tems.

What to do if you’re us­ing soft­ware that is end of life

Option 1: Keep us­ing it

You may be tempted to con­tinue to use the soft­ware - af­ter all, it still works. But this is ul­ti­mately a short sighted ap­proach. As the soft­ware gets older, you’ll face more and more per­for­mance is­sues, with a grow­ing list of se­cu­rity vul­ner­a­bil­i­ties.

Option 2: Bring in line with most re­cent ver­sion

In many cases there will be a mi­gra­tion path to the lat­est ver­sion of the soft­ware. For ex­am­ple, Angular 7 has a mi­gra­tion path to Angular 8 to al­low busi­nesses to lever­age the most re­cent tech stack with­out re­build­ing an en­tire ap­pli­ca­tion. In many cases, this will be the sim­plest and most ef­fec­tive so­lu­tion. Some mi­gra­tions may take longer than oth­ers as the com­plex­ity ul­ti­mately de­pends on the tech­nol­ogy that you’re mi­grat­ing to and from.

Option 3: Rebuild and mod­ernise

This bring us to the third and fi­nal op­tion, re­build and mod­ernise. As men­tioned above, you may have iden­ti­fied a new or bet­ter frame­work ca­pa­ble of tak­ing your ap­pli­ca­tion to the next level. This may pro­vide a num­ber of sig­nif­i­cant ad­van­tages to the ap­pli­ca­tion in­clud­ing speed, qual­ity, ex­per­tise or a com­bi­na­tion of all three.

The trade off when it comes to op­tion 3 is cost and time. To switch en­tirely from one frame­work to an­other means you’re ef­fec­tively hav­ing to re­build the ap­pli­ca­tion. For ex­am­ple, switch­ing from us­ing PHP as a server side lan­guage to some­thing more mod­ern like Spring boot. There may be an ar­ray of fea­tures and li­braries you can lever­age with the new frame­work that will make it more ben­e­fi­cial down the track. However, there will be a time and cost in­vest­ment to en­able this.

Both op­tion 2 and 3 are valid ways to progress for­ward. At WorkingMouse we as­sess every sit­u­a­tion uniquely to rec­om­mend the best path out of end of life. There are far too many risks and pit­falls when it comes to run­ning end of life soft­ware. If you have dis­cov­ered your cus­tom soft­ware ap­pli­ca­tion is end of life, or want to un­der­stand what op­tions there are for mod­ernising it then we’d rec­om­mend book­ing a free con­sul­ta­tion.

ABOUT THE AUTHOR

Yianni Stergou

Marketing en­thu­si­ast and FIFA ex­tra­or­di­naire

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

What Are the Top CRM APIs?

Your vi­sion,

our ex­per­tise

Book an con­sul­ta­tion