How to Move From Excel to a Web Application


One of the more com­mon busi­ness prob­lems that we come across is clients cre­at­ing or val­i­dat­ing a process us­ing Excel and want­ing to scale that into a web ap­pli­ca­tion. There are tools that will get you half way there but it’s more im­por­tant to un­der­stand the en­tire process and how the cus­tom fea­tures are trans­lated into the ap­pli­ca­tion.

This ar­ti­cle will dis­cuss the step by step process we use to trans­form from an of­fline Excel doc­u­ment to a full stack web ap­pli­ca­tion.

Step 1: Reverse en­gi­neer the schema

Because we are work­ing from an ex­ist­ing ap­pli­ca­tion, there is al­ready a schema that the Excel spread­sheet fol­lows. This means there are en­ti­ties and those en­ti­ties have re­la­tion­ships. For ex­am­ple you might have a spread­sheet that keeps track of your in­ven­tory. Let’s say lawn­mow­ers have a one to one re­la­tion­ship with price. That means one lawn­mower has one price. You al­ready know all these rules and the spread­sheet has been cre­ated with these in mind. But re­verse en­gi­neer­ing it helps to cre­ate a more scal­able so­lu­tion and lever­age ex­ist­ing tech­nol­ogy (see step 3).

Step 2: Settle on the scope

This might seem ob­so­lete. If you’re start­ing with an Excel ap­pli­ca­tion, is­n’t the scope of work just repli­cat­ing that as a web ap­pli­ca­tion? The short an­swer is, it can be, but never is. Once you open up new pos­si­bil­i­ties, for ex­am­ple in­te­grat­ing with third party apps, the scope be­gins to ex­pand. Because the same lim­i­ta­tions no longer ex­ist, the pos­si­bil­i­ties grow. That’s why it’s im­por­tant to see what new ad­van­tages can be lever­aged from the web ap­pli­ca­tion dur­ing a scop­ing process.

Step 3: Leverage tech­nol­ogy

As men­tioned in step 1, one of the rea­sons for re­verse en­gi­neer­ing the schema is to lever­age tech­nol­ogy that can save de­vel­op­ment time. WorkingMouse utilises the Codebots tech­nol­ogy to stream­line mi­gra­tion pro­jects. By giv­ing the bots the data­base schema, they can cre­ate the frame­work for the ap­pli­ca­tion. Based on the scope from step 2, we may also be able to lever­age the bots be­hav­iours for more ad­vanced func­tion­al­ity.

Step 4: Add cus­tom fea­tures/​in­te­gra­tions

This is where we can start to get cre­ative. The ap­pli­ca­tion is no longer lim­ited by the na­tive func­tion­al­ity of Excel. We’ll dis­cuss in more depth soon but one past ex­am­ple in­volved tak­ing some pre-writ­ten python cal­cu­la­tions and cre­at­ing an API layer be­tween the new web app and the python code. This cut an en­tire step out of the com­pa­ny’s pre­vi­ous process and meant de­ci­sions could be made in­stantly. This part car­ries the most value, as well as the most risk. That’s why step 2 is de­signed to set­tle on a de­fined scope and in­ves­ti­gate the cus­tom fea­tures/​in­te­gra­tions that form part of the pro­ject.

Step 5: Scale!

Importantly, the mi­gra­tion to a new web ap­pli­ca­tion en­ables scal­a­bil­ity. This means dif­fer­ent things for dif­fer­ent com­pa­nies. In some cases it may mean be­ing able to cre­ate a new user group to al­low cus­tomers to in­ter­act with the ap­pli­ca­tion. In oth­ers, it might mean col­lab­o­rat­ing on an app that they pre­vi­ously could­n’t. One of the more com­mon rea­sons we’ve heard is that it cen­tralises the knowl­edge and does­n’t re­main trapped in the mind of the cre­ator.

With the abil­ity to reach cus­tomers it also pro­vides the po­ten­tial for li­cens­ing the ap­pli­ca­tion. This might act as the pri­mary or sec­ondary rev­enue stream. It’s one of the key ad­van­tages of de­vel­op­ing your own soft­ware rather than choos­ing an off the shelf sys­tem.

Case study: Migrating a com­plex de­sign sys­tem to a full stack ap­pli­ca­tion

This sounds great in the­ory, but how has it been done in prac­tice? My first ex­pe­ri­ence man­ag­ing an Excel to web app pro­ject was a com­plex de­sign sys­tem that took 3 min­utes to open due to the size and num­ber of func­tions used. Not only that, there were 3 of these spread­sheets that formed the over­all de­sign sys­tem.

It was a com­plex sys­tem in a com­plex in­dus­try. Safe to say, the chal­lenge was size­able.

After a few deep breaths and sev­eral cof­fees, we be­gan a three week scope to set­tle on the fu­ture state of the ap­pli­ca­tion and re­verse en­gi­neer the schema. The three seper­ate spread­sheets were con­sol­i­dated and some steps were able to be re­moved by mov­ing away from Excel. We dis­cov­ered a huge op­por­tu­nity to op­ti­mise the sys­tem by set­ting up the scaf­fold of a de­sign quickly and get­ting users to make ed­its on a table. In ad­di­tion, we could cre­ate an API layer and in­te­grate with ex­ist­ing code which would save the com­pany days in back and forth com­mu­ni­ca­tion.

Once the scope was set­tled, we cre­ated the scaf­fold of the ap­pli­ca­tion in the first week, with the code­bots us­ing the schema our web de­vel­oper built. From there on, it was cus­tom fea­ture de­vel­op­ment us­ing the process out­lined in the Way of Working. With the ef­fi­cien­cies gained from the process above and the Codebots tech­nol­ogy, we were 2 weeks ahead of sched­ule near­ing the ini­tial end date. As a re­sult, we were able to in­clude some of the orig­i­nal ‘nice to have’ func­tion­al­ity as part of the first build.

I won’t re­it­er­ate the ben­e­fits of mov­ing from Excel to a web app. If you want an analy­sis on the busi­ness case for your or­gan­i­sa­tion, book a free con­sul­ta­tion with one of our con­sul­tants. The most im­por­tant take­away from this ar­ti­cle is the need for a process that is fluid enough to ac­co­mo­date each pro­jec­t’s re­quire­ments but de­fined enough to lever­age pre­vi­ous learn­ings.

Discover Software


Yianni Stergou

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

Your vi­sion,

our ex­per­tise

Book a con­sul­ta­tion