If you're using Excel spreadsheets for storing and manipulating data, and you're capable of programming in a full-featured language, it's important that you ask yourself the question "is Excel appropriate for this application?".
For example, I've seen an Excel spreadsheet used to track defects ("scrap") on the factory floor of a complex manufacturing plant...the spreadsheet was kept in a shared folder, and could be edited by anyone on the factory floor or in factory offices. Read/write conflicts (data lost due to multiple edits being made simultaneously, with the last to be saved overwriting all previous edits) were likely commonplace (and went undetected), and, as the spreadsheet was used to assign blame for ruining products to specific departements (at values sometimes over $200,000 for a single item), there were likely also edit wars...with no tracking of who edited the document and when.
The sad thing is that if they'd hired someone to develop their application in .net or Java, using a relational database, they'd have been logging who made what edits, preventing read/write conflicts, and keeping better track of what was scrapped..and it would have cost much less to develop the application. Instead, they hired a full-time consultant for over two years writing (uncommented) VBA code to maintain their scrap tracking excel file...despite the fact it was obvious from day one that Excel cannot be made suitable to the task being requested of it.
If your application manipulates data for a single user, then Excel is an OK choice, perhaps even an excellent choice. While I've never done it myself, I believe it's also possible (but difficult) to add another spreadsheet to an Excel document and implement a GUI on that spreadsheet which feeds data to and retrieves data from other tabs, providing an alternative, potentially more user-friendly UI to your existing spreadsheets, using the built-in VBA programming language, which may be all you'd need.
That said, if multiple users need to interact with the same data, it's usually time to switch to a relational database, and move your business logic from the spreadsheet into a full-featured programming language that can actually protect the integrity of the data. Exporting data to a format that Excel can read, so it can be plugged in to an existing data analysis spreadsheet is sometimes worthwhile if you find it difficult to re-implement some of the graphs or other analysis tools in the spreadsheet, but with appropriate libraries, it should be possible to re-implement everything that was actually useful in the spreadsheet.