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


At the core of the IT in­dus­try to­day is dig­i­tal trans­for­ma­tion. The rea­son this trans­for­ma­tion is nec­es­sary is due to the amount of legacy that IT teams are fac­ing. Recognising this, WorkingMouse and Codebots doc­u­mented mul­ti­ple mi­gra­tion pat­terns for mov­ing legacy ap­pli­ca­tions to the cloud.

This ar­ti­cle will step you through the more ba­sic legacy mi­gra­tion pat­tern - the fire­cracker method. If you’re still eval­u­at­ing what to do with your legacy sys­tem, take a look at how to evolve a legacy ap­pli­ca­tion.

When to use the fire­cracker method

This is gen­er­ally used when the legacy ap­pli­ca­tion is small. For larger sys­tems, the mi­gra­tion may be done over a large pe­riod of time and mul­ti­ple small pro­jects. Recently, we’ve seen busi­nesses with crit­i­cal processes built us­ing Microsoft Access. Offline data­bases like Access and Excel are prime can­di­dates to mi­grate into a mod­ern web ap­pli­ca­tion us­ing the fire­cracker method.

The process

The process is to gather knowl­edge about the legacy ap­pli­ca­tion and use that to build the new ap­pli­ca­tion. The di­a­gram be­low shows a con­cep­tual work­flow for a fire­cracker mi­gra­tion.


The mi­gra­tion steps are as fol­lows.

  1. Document the re­quire­ments of the old ap­pli­ca­tion to cre­ate a back­log for the new ap­pli­ca­tion.
  2. Remove old re­quire­ments that were not used or are no longer needed from the back­log.
  3. Reverse en­gi­neer the schema from the old data­base. If you are us­ing Codebots, this step may be au­to­mated.
  4. Clean up the schema. This is a good op­por­tu­nity to eval­u­ate whether the schema con­tains any legacy.
  5. Design the UI. We would rec­om­mend con­sult­ing one of our user ex­pe­ri­ence de­sign­ers to eval­u­ate the ease of the user jour­ney.
  6. Develop and test the new ap­pli­ca­tion.
  7. Deploy and mi­grate the data. Because the new ap­pli­ca­tion is based on the schema of the ex­ist­ing ap­pli­ca­tion, pro­vided no fun­da­men­tal changes are made when clean­ing up the schema, a data mi­gra­tion path is pos­si­ble.

As men­tioned ear­lier, this method works well for smaller ap­pli­ca­tions where the num­ber of de­pen­dent sys­tems is min­i­mal. When we start look­ing at larger sys­tems the mi­gra­tion can’t be done in one hit so we would rec­om­mend the di­vide and con­quer pat­tern.

To be sure the new, dig­i­tally trans­formed ap­pli­ca­tions of to­day don’t be­come the legacy sys­tems of to­mor­row we rec­om­mend doc­u­men­ta­tion. Only when an ap­pli­ca­tion is un­der­stood can it be mod­ernised. This doc­u­men­ta­tion process is an im­por­tant part of the way we work and the tech­nol­ogy we use. If you’re look­ing to mod­ernise your legacy soft­ware, get in con­tact to hear how we would ap­proach the prob­lem, or check this re­source space out!

Discover Software


Yianni Stergou

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

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

21 April 2020

Web Apps vs Excel: Which to Use When

20 October 2020

Your vi­sion,

our ex­per­tise

Book a con­sul­ta­tion