Observations and Learnings From a Cloud Modernisation Scope


We re­cently em­barked on a new Scope with an ex­ist­ing cus­tomer. Having worked closely with this cus­tomer over the last four years, we in­ti­mately know the busi­ness. We’ve helped them move away from re­stric­tive in­dus­try-based COTS (Custom Off-The-Shelf) soft­ware, sig­nif­i­cantly in­crease rev­enue through dy­namic pric­ing and op­ti­mi­sa­tion of in­ter­nal ad­min­is­tra­tion costs.

To read; our quick guide, other blogs or book on Legacy Modernisation check out the Cloud Migration Hub.

The Scope it­self turned into a jour­ney with mul­ti­ple twists and turns. We set out to solve one op­por­tu­nity with the prod­uct and have ended up with the Scope of a com­pletely new prod­uct.

Sound con­fus­ing?

Well, here’s the jour­ney we went on, some tech­ni­cal learn­ings made and why we ended up where we did.


To give tech­ni­cal con­text to the pre­sent dis­cus­sion, the tar­get ap­pli­ca­tion we com­menced Scope on is a Second Generation Codebot Application. Developed 4+ years ago, the tech­nol­ogy set was LAMP, re­fer­ring to Linux, Apache, MySQL and PHP.

LAMP is still a mod­ern web tech­nol­ogy stack but in­ter­nally grand­fa­thered by Codebots third-gen­er­a­tion bots. WorkingMouse com­mences all Greenfields builds at pre­sent on C#bot. The main tech­nol­ogy stack of #C bot is C# Server-side, Graph QL as the API struc­ture and React client-side. This third-gen­er­a­tion bot pro­vides de­vel­op­ers with a broader skillset and a sig­nif­i­cantly more per­for­mant ar­chi­tec­ture for our cus­tomers.

To sim­plify this:

Initial build = LAMP

New Scope = C#

Mobile First

The Scope com­menced from an­a­lyt­ics and ob­served user be­hav­iours. We ob­served an in­creas­ing num­ber of mo­bile vis­i­tors to the site over the few months pre­ced­ing the Scope kick-off. As of September 2021, an­a­lyt­ics showed that 5,300 vis­i­tors were on mo­bile while just over 3,000 were on desk­top.

The user be­hav­iour was that most trans­ac­tions and record man­age­ment oc­curred on the desk­top. This led us to sus­pect we could in­crease con­ver­sion rates on mo­bile to desk­top run rates.

We set out to de­sign a mo­bile-first book­ing process, and we achieved this. We ob­served three user test­ing ses­sions on the de­sign to val­i­date the ease of pur­chas­ing.

Restrictive Technical Debt

We con­stantly stum­bled across tech­ni­cal re­stric­tions of the ex­ist­ing sys­tem’s ar­chi­tec­ture through­out the de­sign process that in­hib­ited cus­tomer-first de­sign think­ing. An ex­am­ple of this was the clas­sic lo­gin and user cre­den­tials sys­tem.

The sys­tem has over 50,000 user cre­den­tials (many of which are dou­ble-ups from peo­ple for­get­ting which email ad­dress they reg­is­tered with). The user’s pri­mary key is as­so­ci­ated with the user email ad­dress, but we wanted to im­ple­ment SMS and phone num­ber as the pri­mary au­then­ti­ca­tion fac­tor.

In re­search­ing this, we found sev­eral great re­sources on im­ple­men­ta­tion and se­cu­rity:

Using two-fac­tor au­then­ti­ca­tion (TFA) and mo­bile num­ber ver­i­fi­ca­tion would have re­duced the num­ber of guest users, made lo­gin quicker and stopped fu­ture ac­count dou­ble-ups whilst be­ing mo­bile-first friendly.

Alongside other points, such as the book­ing en­gine, we de­cided to re­view a mod­erni­sa­tion ap­proach. We knew the cus­tomer was plan­ning to re­brand the soft­ware to sev­eral white-la­bel cus­tomers.

Modernisation Options

We looked at sev­eral mod­erni­sa­tion op­tions. The key ones we in­ves­ti­gated were:

1. Single Sign-On (SSO)

We con­sid­ered the first method of us­ing a sin­gle sign-on be­tween the legacy data­base and the new ap­pli­ca­tion data­base. The user would just log in once, de­pend­ing on the in­ter­nal sys­tem nav­i­ga­tion, by us­ing ei­ther the old or new sys­tem.

We found the up­front cost of do­ing this cou­pled with the risk of data cor­rup­tion to be too great in tak­ing this path. Also, we would­n’t be able to eas­ily white-la­bel the sys­tem.

2. A Gradual Modernisation

The first vi­able op­tion was Gradual Modernisation. This op­tion meant us­ing the new server-side code with a proxy on the pre­sent data­base for builds 4 to 6. We’d be able to keep the old sys­tem live whilst build­ing new func­tion­al­ity.

This grad­ual ap­proach comes from hav­ing to break down more builds, and the out­come of this is a long build time and, there­fore, higher cost. Development was re­stricted - due to the com­plex­ity we could­n’t make im­prove­ments un­til ma­jor parts of the prod­uct had been mod­ernised.

3. The Pop ‘N’ Switch (we just made that up… Trademark pend­ing)

This was a slightly more de­sir­able op­tion. However, it still came with sig­nif­i­cant time con­straints.

The plan was to em­bed React im­prove­ments in the ex­ist­ing LAMP stack. Once done, we would rewrite the server-side logic to fa­cil­i­tate the new build re­quire­ments. Post the React work, we would mi­grate and re­place the server-side. This meant we could mod­ernise the client-side with­out hav­ing to re­build all the server-side.

This would have been a great so­lu­tion if the prod­uct were to per­sist as a sin­gle prod­uct. Still, we would have had to deal with a sig­nif­i­cant amount of tech­ni­cal debt in do­ing so, how­ever, we could quickly get the in­tended user ex­pe­ri­ence.

The down­sides were that any­thing built in build 3-5 in LAMP would need to be re­built in #C when we wanted to re-ar­chi­tec­ture in Build 6.

4. A Firecracker mi­gra­tion

Finally, we set­tled on a fire­cracker mi­gra­tion path, us­ing the ex­ist­ing model and data struc­ture to re­build a com­pleted new full-stack ap­pli­ca­tion and then mi­grate the data. Whilst this meant a longer wait, it also meant be­ing wholly re­moved from tech­ni­cal debt.

We have sig­nif­i­cant ex­pe­ri­ence in the cus­tomer busi­ness do­main and thor­ough doc­u­men­ta­tion of the old sys­tem, which fur­ther re­duced the risk. This also re­moved the ex­tra cost of do­ing higher risk con­nec­tions or tech­nol­ogy re­place­ment. The cus­tomer must main­tain the ex­ist­ing prod­uct slightly longer but will get a bet­ter and li­cens­able prod­uct post-build 4.

Licensing Opportunities

The li­cens­ing op­tions were the linch­pin of the mod­erni­sa­tion path­way, and it’s help­ful to ex­plore the dif­fer­ent paths we have avail­able in li­cens­ing a prod­uct. There are two fun­da­men­tal op­tions avail­able. These are:


The ap­pli­ca­tion source code is set up on a new ap­pli­ca­tion in­stance for every cus­tomer. This means a new server and do­main op­er­at­ing in its silo. The cus­tom busi­ness logic for each cus­tomer and their brand­ing are con­fig­ured in the su­per ad­min’s back-end of the tar­get ap­pli­ca­tion.

The Pro’s

  • Can be con­verted to multi-ten­ant later.
  • It does­n’t re­quire any soft­ware so­lu­tion (no added de­vel­op­ment time).
  • Flexibility around de­ploy times (updates can be done when­ever best works for the in­di­vid­ual ap­pli­ca­tion).
  • Debugging and main­te­nance can be iso­lated to dif­fer­ent ap­pli­ca­tions.
  • Zero risk of data con­t­a­m­i­na­tion or leak­ing other ap­pli­ca­tions data.
  • The li­censee can host/​main­tain their en­vi­ron­ment, or the cus­tomer can host all of them.
  • The ap­pli­ca­tions could be de­ployed in dif­fer­ent lo­ca­tions.
  • Individual ap­pli­ca­tions can be scaled in­de­pen­dently.
  • Individual sys­tems won’t af­fect each oth­er’s per­for­mance & down­times.
  • User pri­vacy and data are safer due to dis­tri­b­u­tion.

The Con’s

  • Need to de­ploy mul­ti­ple times (this will be au­to­mated through dev-ops but will still take longer).
  • Higher cost due to split sys­tems (more cloud host­ing re­sources).


This is where mul­ti­ple in­stances of the same ap­pli­ca­tion op­er­ate in a shared en­vi­ron­ment. This means there is a sin­gle data­base, which saves more on servers and data stor­age.


  • Cheaper to main­tain.
  • Cheaper to re­source, as they are shared.
  • Easier to han­dle any com­mon data (users, groups etc).


  • Needs a soft­ware so­lu­tion (which will take time to im­ple­ment).
  • Data sov­er­eignty is es­sen­tial so the cus­tomers can’t ac­cess each oth­er’s data.
  • If one of them is us­ing many re­sources, this will im­pact the other ten­ants.
  • Multiple ap­pli­ca­tions read­ing/​writ­ing to the same data­base could lead to per­for­mance loss.
  • Hard to scale in­di­vid­ual ap­pli­ca­tions.
  • Other ap­pli­ca­tions may cause bot­tle­necks.
  • Attractive to hack­ers due to cen­tralised user in­for­ma­tion for mul­ti­ple ap­pli­ca­tions.


As you can see, we went on quite the jour­ney in a sin­gle build scope! Upon re­flec­tion, we could have negated the mi­gra­tion jour­ney dis­cus­sion with a franker con­ver­sa­tion up­front. However, it felt im­por­tant to go down that path­way at the time.

What stuck with me is the im­por­tance of get­ting the high­est qual­ity prod­uct in front of the users and data. If it takes longer to get the qual­ity right, the in­vest­ment will be eas­ier to achieve. In re­al­ity, the es­sen­tial part of any ap­pli­ca­tion is the data; if this is the case and we can mi­grate the data, should we not re­build as soon as we re­alise the tech­ni­cal debt is in­hibit­ing the de­sign?

As we learn and evolve, we should treat soft­ware as the ve­hi­cle for our pre­sent cir­cum­stances. As with all ve­hi­cles, they re­quire main­te­nance, and as our needs change so too should our cho­sen ve­hi­cle.

The dif­fi­culty lies in this de­ci­sion: up­grade to a peo­ple mover and ac­cept the cir­cum­stance or con­tinue to pile the kids into your hatch­back!

Discover Software


David Burkett

Growth en­thu­si­ast and res­i­dent pom

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

Legacy System Migration Do’s and Don’ts

19 November 2018

Using the fire­cracker method for legacy mi­gra­tion

02 March 2020

Mitigating the risks of brown­fields de­vel­op­ment

21 April 2020

Your vi­sion,

our ex­per­tise

Book a con­sul­ta­tion