A family of Microsoft spreadsheet software with tools for analyzing, charting, and communicating data.
Hi, George,
I am an independent consultor, and as such, I have come across this type of question/scenario very often. With so many lines of code already written in VBA (Excel, mostly) VBA is not going anywhere anytime soon, so you can be at ease in that regard, at least. That does not mean, however, that people/companies should see that as an encouragement to keep developing 'solutions' of that type, and personally, I think they should not, at least most of the time. Instead, and especially regarding companies, more centralized solutions should be opted for, meaning that some sort of back-end/front-end/database combination should be provided. This is not only much more secure (VBA macros are not!) but also easier to develop and maintain over time. Moreover, and more importantly, whichever 'solutions' are being organically created by company staff should not remain in an obscure VBA macro that only its developer knows about, but should be normalized, generalized, and eventually incorporated as part of the growing set of resources and knowledge that the company acquires over time. The way I see it, at least, there are no 'cons' to developing, [as it seems to be in your case] a .NET application instead of using VBA macros. The only possible exception to this may be cases in which very simple manipulations need to be added to a spreadsheet (color-coding values, ad hoc calculations, etc.), but normally a company should steer away from VBA macros as a tool.
Lastly, there is a deeper, and ultimately much more significant reason not to opt for VBA macros as a way to solve some problems:
Every company [within the same domain of commoditized business] does things in a slightly different manner to its competition, for example, although coffee shop A sells the same type of coffee as coffee shop B, including using the very same coffee machines as, the quality of the services they provide around their coffees may be very different, and I have always believed that any decent information [processing] system (ERPs, SAPs, etc.) should learn to incorporate into their most internal components the variables, precepts, concepts, and the set of axioms that a company uses to do business in the specific and precise way that it does as opposed to those of its competition. This is something that should never remain in the hands of any particular employee but should be captured and nurtured by IT professionals with a vision towards the future of the company.
I hope this helps.