CLOUD MIGRATION

Cloud Migration: the Fast Beats the Slow

The cloud en­ables an on-de­mand busi­ness model. No huge up­front re­source costs, sim­ply use as much or as lit­tle as needed. This is why by 2018, more than 60% of busi­nesses will have at least half of their sys­tems on cloud ser­vices and so­lu­tions. Right now, most busi­nesses are un­der­go­ing some sort of dig­i­tal trans­for­ma­tion and the truth is, if you are not in­no­vat­ing in this di­rec­tion, you are at se­ri­ous risk of be­ing dis­rupted.

It’s no longer the big eats the small. It’s the fast beats the slow.

Some of the IT bud­get must go to­wards in­no­va­tion and CIOs around the world have ac­knowl­edged dig­i­tal trans­for­ma­tion as a key chal­lenge. On one hand, you will need to sup­port ex­ist­ing soft­ware, and on the other hand you will need to in­no­vate. This is the role of Bimodal IT. The two modes of de­liv­ery in Bimodal IT are mode 1 and mode 2. Mode 1 is about sta­bil­ity and sup­port­ing ex­ist­ing sys­tems. Mode 2 is about in­no­va­tion and ex­plor­ing new pos­si­bil­i­ties.

At some point in the busi­ness’s dig­i­tal trans­for­ma­tion, you will likely be faced with an ap­pli­ca­tion mod­erni­sa­tion pro­ject. This pro­ject would be con­sid­ered legacy soft­ware and has been main­tained un­der the mode 1 ban­ner, but has be­come at risk due to mar­ket changes or loss of in­ter­nal re­sources. A legacy sys­tem mi­gra­tion legacy can oc­cur un­der the mode 2 ban­ner. Legacy mod­ern­iza­tion is an op­por­tu­nity to in­no­vate, so get on your marks, be­cause the race is on.

From here there are lots of op­tions to con­sider, though they gen­er­ally fall un­der three broad ap­proaches:

  1. Do noth­ing: Ignore busi­ness trends at your own peril
  2. Uncover: Leave the in­tel­lec­tual prop­erty (IP) as is and use a plat­form to un­cover
  3. Rewrite: Start again on a new tech­nol­ogy stack

The do noth­ing ap­proach is the ele­phant in the room, ig­nor­ing the ob­vi­ous. The other 2 op­tions are both le­git­i­mate. So what is the best way to de­cide? The an­swer can be re­vealed by con­sid­er­ing the in­tel­lec­tual prop­erty (IP) in the legacy ap­pli­ca­tion. Consider if the IP is so spe­cialised that rewrit­ing it would be too costly, for ex­am­ple some­thing like a com­plex math­e­mat­i­cal sim­u­la­tion. If it is, then the un­cover ap­proach is good. If the IP could be rewrit­ten or the IP is how a prob­lem was solved, for ex­am­ple, some­thing like a work­flow that helps a busi­ness sec­tor. Then the rewrite ap­proach is good.

The pit­falls of the un­cover ap­proach is to sim­ply repli­cate the legacy user in­ter­face (UI) in a browser, as many op­por­tu­ni­ties to in­no­vate would be lost. Firstly, one of the biggest dri­vers of dig­i­tal trans­for­ma­tion is to in­crease cus­tomer sat­is­fac­tion and to­day’s users ex­pect a great user ex­pe­ri­ence (UX). Secondly, putting more code on top of legacy sys­tems is com­pound­ing the ac­tual legacy prob­lem. The true IP of the legacy sys­tem should be iden­ti­fied and the rest of the ap­pli­ca­tion dep­re­cated. If it is left in play it will nig­gle at the busi­ness for years to come.

A plat­form can un­cover the IP and mod­ernise the soft­ware into a cloud-based en­vi­ron­ment.

Image

So, if the IP is to be pre­served, the rest of the legacy soft­ware that is dep­re­cated will need to be mod­ernised. This means that the un­cover ap­proach still ends up with some rewrit­ing.

To rewrite a legacy ap­pli­ca­tion is an op­por­tu­nity to wipe the slate clean and lay down a new foun­da­tion for the fu­ture. However, there is no doubt that this is a se­ri­ous un­der­tak­ing and that many smart peo­ple have im­paled them­selves on these types of pro­jects. Some of the key chal­lenges to be mind­ful of are:

  1. Break the pro­ject down into it­er­a­tions or sprints. Don’t go for the big bang en­tire rewrite in one go.

  2. Find a light­house client. Users breathe life into the soul of soft­ware and the ear­lier the soft­ware is be­ing used the bet­ter.

  3. Use a sci­en­tific ap­proach. Put for­ward a hy­poth­e­sis that can be val­i­dated. In the lean startup, this is about the build-mea­sure-learn cy­cle.

  4. Test, test and test. To be con­fi­dent that any non-triv­ial sized soft­ware ap­pli­ca­tion works, is to en­sure the qual­ity of the soft­ware through soft­ware test­ing.

  5. Consider the com­mer­cial out­comes. The pro­ject will open busi­ness op­por­tu­ni­ties and the C-suite should be in­volved in the plan­ning process.

  6. Don’t for­get the cul­ture. Introducing new soft­ware changes the land­scape of the peo­ple us­ing it. A change in the man­age­ment plan could be worth­while.

  7. Last and not least, is the tech­ni­cal chal­lenge. Follow a sys­tem­atic process from the legacy ap­pli­ca­tion to the new mod­ernised ap­pli­ca­tion in the cloud. This is such an in­te­gral part of the process that the rest of the ar­ti­cle be­low will be spent dis­cussing it.

Let’s imag­ine a hy­po­thet­i­cal sce­nario where you have iden­ti­fied the first part of the legacy ap­pli­ca­tion to be mod­ernised. This is the Minimum Viable Product (MVP). It should be just big enough to be use­ful for the first light­house client, but not too big to in­clude ex­cess func­tion­al­ity.

The first step, seen in the di­a­gram be­low, should be to start with the legacy data­base and re­verse en­gi­neer it to a model (more on mod­els shortly). The rea­son for start­ing with the legacy data­base is to en­sure there is a data mi­gra­tion plan for ex­ist­ing cus­tomers that will even­tu­ally want to move from the legacy to the cloud.

Image

Now, it is the ac­tual model that is the key to the suc­cess of the pro­ject. Academics every­where have been very busy re­search­ing, but if you have not heard of the work yet it falls un­der the ban­ner of Model-Driven Engineering (MDE) and Domain-Specific Languages (DSL). In essence, the idea is to work at a higher level of ab­strac­tion than the code. Then use ro­bots (or code gen­er­a­tors) to gen­er­ate large por­tions of the tar­get. This cre­ates all sorts of ef­fi­cien­cies.

This means that in steps 2, 3 and 4 in the above di­a­gram, the goal is to cre­ate the mod­els of the tar­get ap­pli­ca­tion. Then in step 5, the new cloud ap­pli­ca­tion can be gen­er­ated. Finally for step 6, since the first step was to start at the legacy data­base and MDE is used, there will be a path for the data mi­gra­tion for the legacy cus­tomers to the cloud.

In sum­mary, a cloud mi­gra­tion pro­ject is a se­ri­ous un­der­tak­ing. With many ex­am­ples of failed cases there is no doubt why the topic can send shiv­ers down your spine. There is still some good news for you! The soft­ware en­gi­neer­ing com­mu­nity has been in­no­vat­ing and there are now some very good and vi­able op­tions that can min­imise the risk in­volved.

ABOUT THE AUTHOR

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