How to suc­cess­fully com­plete a legacy mi­gra­tion us­ing the di­vide and con­quer strat­egy

We’ve pre­vi­ously looked at the Firecracker mi­gra­tion pat­tern for mod­ernising legacy ap­pli­ca­tions. We iden­ti­fied that the Firecracker tech­nique works best for small legacy ap­pli­ca­tions. A good ex­am­ple is of­fline data­bases such as Microsoft Access or Excel. But what do we do when we’re not mi­grat­ing a sin­gle legacy ap­pli­ca­tion? How do we mi­grate those mono­liths that are too large to mi­grate in a sin­gle pro­ject? We must stick to our ag­ile prin­ci­ples and chunk down the pro­ject. Hence, we must di­vide and con­quer.

Addressing legacy mi­gra­tion risks

As we’ve es­tab­lished, it is im­por­tant to chunk the legacy sys­tem into mul­ti­ple mi­gra­tion pro­jects. This means we can­not sim­ply turn all the lights off on the old legacy sys­tem. In ef­fect we have an old and new sys­tem live at the same time. It raises a num­ber con­cerns:

  • Data in­tegrity: what sys­tem holds the source of truth?
  • Up-stream and down-stream sys­tems: we must make sure we don’t break other sys­tems
  • Integration: how do we keep the sys­tems com­mu­ni­cat­ing with­out in­vest­ing much time into the in­te­gra­tion.

Divide and con­quer mi­gra­tion pat­tern

The di­vide and con­quer mi­gra­tion pat­tern stems from Eban Escott and Indi Tansey’s book Bots that Code. It uses bots to help ob­serve the ex­ist­ing legacy sys­tem (workerbot) and build the mod­ernised sys­tem (csharpbot or spring­bot).


This fig­ure is more like a de­ploy­ment di­a­gram. The old legacy sys­tem is on the left and the new legacy sys­tem is on the right. Each legacy sys­tem is split into an ap­pli­ca­tion (top) and a data­base (bottom). The hu­mans on the left are the end users of the old ap­pli­ca­tion and the worker­bot on the right will sim­u­late the hu­mans dur­ing the tran­si­tion phase.

Step 1: Follow the steps from the fire­cracker mi­gra­tion pat­tern i.e., re­verse en­gi­neer the re­quire­ments and de­sign the new ap­pli­ca­tion. This should only be done for the up­com­ing scope of work. There may be learn­ings made from the ini­tial mi­gra­tion that in­forms/​changes the way you de­sign the sub­se­quent mi­gra­tion pro­jects. This also in­cludes for­mu­lat­ing a data­base mi­gra­tion plan.

Step 2: If pos­si­ble, add an in­ter­cep­tor be­tween the old ap­pli­ca­tion and its data­base to for­ward all re­quests to the worker­bot.

Step 3: If pos­si­ble, add an ob­server to the legacy ap­pli­ca­tion that is able to for­ward other re­quest data to the worker­bot. Since all pro­jects are dif­fer­ent, think of dif­fer­ent ob­servers and in­ter­cep­tors you can use to send to the worker­bot.

Step 4: Develop the worker­bot to in­ter­pret the re­quests from the ob­servers and in­ter­cep­tors to mimic the same re­quire­ment but in the new ap­pli­ca­tion.

Dr Escott rec­om­mends us­ing an iso­la­tion checker to en­sure the data in­tegrity of the new ap­pli­ca­tion.

It will take sig­nif­i­cant ef­fort to build the frame­work around the old legacy sys­tem. The ob­server, in­ter­cep­tor, and worker­bot will take time to get right. But once you get them go­ing, you will have a path to con­tinue the di­vide-and-con­quer ap­proach on the old legacy sys­tem.

Utilising mi­croser­vices for the mod­ernised ap­pli­ca­tion

If you’ve read up un­til now you prob­a­bly know a thing or two about mono­liths. If this brings up a few bad mem­o­ries (or even re­minds you what to­mor­row could be like) that’s ok. We want to learn from the mis­takes of the past to build bet­ter sys­tems to­mor­row. One learn­ing that is par­tic­u­larly im­por­tant is the need to break down mono­liths into mi­croser­vices.

One help­ful tip is to iden­tify the right mes­sag­ing layer be­tween mi­croser­vices. RESTful APIs has be­come the in­dus­try norm. There are al­ter­na­tive tech­nolo­gies like Hazelcast that some ex­perts sug­gest you get in-mem­ory speeds to get ex­treme per­for­mance for both pro­cess­ing and in­ter-ser­vice com­mu­ni­ca­tion.

Above all else, mi­croser­vices re­quires a cul­tural shift. Protocols need to be stan­dard­ised and new DevOps ca­pa­bil­i­ties need to adopted. This type of shift can be dif­fi­cult to per­form in­ter­nally and can be eas­ier to com­plete by out­sourc­ing the ini­tial de­vel­op­ment. WorkingMouse spe­cialises in legacy mi­gra­tion and will use processes and tech­nol­ogy that will mit­i­gate the risks of mod­ernising your legacy sys­tem.


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.

Your vi­sion,

our ex­pe­ri­ence

Book an analy­sis call