Don’t Stress About Legacy Application Migration

Your soft­ware has be­come an in­te­gral part of your com­pany, but it’s age­ing. It’s be­com­ing in­creas­ingly ex­pen­sive to main­tain and in­hibit­ing your com­pa­ny’s growth and in­no­va­tion po­ten­tial. What do you do? You’ve been con­sid­er­ing up­grad­ing your sys­tems, but you’re un­sure if it’s bet­ter to rewrite your ex­ist­ing legacy soft­ware or cut the cord and buy new soft­ware. The prob­lem is, both of these op­tions come with a va­ri­ety of pos­si­ble con­se­quences, and so you’re stress­ing over your legacy sys­tem up­grade. Does this sce­nario sound fa­mil­iar? Let’s un­pack the sit­u­a­tion and dis­cover the pros and cons of each op­tion.

A rewrite bears per­haps the high­est risk of all, as it re­quires fur­ther in­vest­ment into an age­ing, fail­ing sys­tem. Furthermore, de­spite your ef­forts, your com­pany will re­main at a tech­ni­cal dis­ad­van­tage. However, if you go down the path of find­ing a soft­ware de­vel­op­ment com­pany to de­velop a com­pletely new soft­ware stack, then there will be a steep learn­ing curve for your em­ploy­ees, which means de­creased pro­duc­tiv­ity. You also risk los­ing valu­able fea­tures and gain­ing un­nec­es­sary ones. And then there’s the price tag. Of course, you could al­ways con­tinue us­ing your ex­ist­ing legacy ap­pli­ca­tion(s) for the time be­ing, how­ever, this could limit your busi­ness’ po­ten­tial. Enter cloud mi­gra­tion.

Cloud Migration

Migrating legacy sys­tems to the cloud is a third op­tion that you may be in­ter­ested in. This process is usu­ally three to four times faster than a rewrite, and far less in­tru­sive or ex­pen­sive as new soft­ware and/​or sys­tems. Admittedly, there are risks. Some busi­nesses can spend mil­lions of dol­lars mi­grat­ing data be­tween ap­pli­ca­tions, such as legacy ap­pli­ca­tions to the cloud, only to have the re­sults of this mi­gra­tion fall short of ex­pec­ta­tions. This is usu­ally be­cause of flaws in the mi­gra­tion process (sometimes data is in­ad­e­quately val­i­dated for its in­tended tasks). Although there are risks as­so­ci­ated with all of these op­tions, in­clud­ing do­ing noth­ing, cloud mi­gra­tion ser­vices are be­com­ing in­creas­ingly ap­peal­ing be­cause they com­bine the best of both worlds: fix­ing ex­ist­ing soft­ware and de­vel­op­ing new tech­nolo­gies.

Migrations are an ex­per­i­men­tal process. You are tri­alling your legacy ap­pli­ca­tions in a whole new ecosys­tem. Therefore, the best way to go about the move is to be sci­en­tific. This means build­ing a hy­poth­e­sis, test­ing its level of suc­cess, and then build­ing from the data. The ben­e­fits of work­ing in it­er­a­tions are al­low­ing your busi­ness to build upon suc­cesses and ad­dress fail­ures. This build-mea­sure-learn con­cept is an ex­tremely valu­able as­set for all busi­nesses for two rea­sons:

  1. Withholding from one big re­lease of your soft­ware al­lows you to avoid build­ing on flawed code and ideas.

    Finding small prob­lems in your ap­pli­ca­tion as you in­cre­men­tally re­lease up­dates is bet­ter than find­ing a big prob­lem on launch.

Of course, the other big rea­son to not stress about your legacy mi­gra­tion are the in­no­v­a­tive new soft­ware de­vel­op­ment tools and prac­tices be­gin­ning to make an ap­pear­ance in Australian soft­ware de­vel­op­ment com­pa­nies.

Both of these con­sid­er­a­tions syn­er­gise with cloud mi­gra­tion. Nothing is more it­er­a­tive than cloud mi­gra­tion, as the in­ten­tion is to re­tain all ex­ist­ing func­tion­al­i­ties; only mi­grate them to the cloud, where up­grade and main­te­nance costs are cheaper and user ex­pe­ri­ence is bet­ter.

Model-Driven Engineering and Domain Specific Language

There have been huge de­vel­op­ments in au­to­matic pro­gram­ming, which have in­creased the power of code ro­bots, or code­bots. These au­to­matic code writ­ers can be used in a legacy mi­gra­tion. Academic re­search in this area is known as Model-Driven Engineering and Domain Specific Language (DSL). Model-Driven Engineering re­lies on cre­at­ing and ex­ploit­ing mod­els as op­posed to de­pend­ing on com­pli­cated com­puter al­go­rithms and con­cepts. DSL is an al­ter­na­tive to gen­eral-pur­pose lan­guage (GSL). The ad­van­tage of DSL is that it can al­low a par­tic­u­lar type of prob­lem or so­lu­tion to be ex­pressed more clearly than an ex­ist­ing lan­guage, es­pe­cially if the type of prob­lem in ques­tion reap­pears suf­fi­ciently of­ten. Pragmatically, a DSL may be spe­cialised to a par­tic­u­lar prob­lem do­main or rep­re­sen­ta­tion tech­nique, a par­tic­u­lar so­lu­tion tech­nique, or some other as­pect of a do­main. Both Model-Driven Engineering and DSL are awe­some ex­am­ples of the ad­vanced and in­no­v­a­tive tech­nolo­gies that are emerg­ing, they also syn­er­gise with ag­ile busi­ness prac­tices.

Agile, MVPs, And Codebots

The first re­lease of your ap­pli­ca­tion should be a min­i­mal vi­able prod­uct (MVP). By start­ing with a MVP, you can build, mea­sure and learn”. This process com­bines well with the in­no­v­a­tive meth­ods of cod­ing, such as code­bots, men­tioned above. Codebots write code faster than hu­mans do, al­low­ing for more it­er­a­tions, which means more op­por­tu­ni­ties for mea­sur­ing and learn­ing. Furthermore, be­cause both ag­ile and code­bots are pow­ered by prece­dence (earlier builds and mod­els), the tem­plate of your legacy sys­tem serves as an awe­some spring­board, al­low­ing for faster, cheaper, and bet­ter cloud so­lu­tions. So don’t stress about legacy ap­pli­ca­tion mi­gra­tion.


Eban Escott

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

Your vi­sion,

our ex­pe­ri­ence

Book an analy­sis call