Language: EN


12 reasons why you should delete Excel from your company

Surely the title of this post will surprise more than one. Delete the Excel sheet? If we did, probably 80% of companies would be paralyzed. They simply couldn’t function.

If this in itself doesn’t seem like a reason to consider that something is wrong, let me clarify. You should delete Excel right now. Delete it, gone forever.

Before the hordes of Excel fanatics come after me, brandishing banners with slogans like “LOOKUP() RULES” or “I ❤ DESREF()”, I invite you to read the rest of the post and reflect on the use (and abuse) of Excel sheets.

What’s wrong with Excel?

In my professional experience, I have often had the opportunity to collaborate as a consultant to integrate systems and automate processes. As rewarding as this work may be, as a result I have had to grapple with Excel sheets on more occasions than I could count, as well as the ardent (and sometimes irrational) defense of its users.

Every time a user asks me for help, starting with a phrase like “I have a shared Excel sheet that…” or “I have an Excel with a macro that…”, personally, I start to tremble.

Perhaps it’s professional deformation, but when faced with these queries, the first thing that comes to mind is “You’re not using the right tool”. You need something, something that you may not even know you need (probably a database or software) that should cover that function for you.


Computing, or more accurately, information technology, is called that for a reason. It’s called that because it’s meant to manage vast amounts of information, process it, and deliver it to the user when and how they need it.

Computing is not (or should not be) a user looking at an Excel sheet with thousands of rows, dozens of columns, a mishmash of tabs, some of them hidden with “sinister” calculations, and data “chaotically organized.”

I’ve seen ships burning beyond the Orion belt things you wouldn’t believe:

  • I’ve seen companies perform their calculations (structures, installations, infrastructures…) in Excel.
  • I’ve seen companies create budgets, manage orders, issue delivery notes with Excel.
  • I’ve seen companies create, share, and store reports and reports in Excel.
  • I’ve seen project management with Excel, Kanban in Excel, Gantt in Excel.
  • I’ve seen the control of personnel, absenteeism, time tracking, and vacations in Excel.
  • I’ve seen storing customer and supplier information in Excel.
  • I’ve even seen companies base their accounting and strategic plan on Excel.

If you’ve read this far and I still haven’t managed to make you shudder, or at least consider that maybe Excel isn’t as good an idea as it seemed, let’s cite the 12 reasons why you should delete Excel from your company.

12 reasons to stop using Excel


Creating an Excel sheet is simple, you just write according to your needs and configure a tool that is useful and to your liking.

But have the entities that make up your model and the relationships between them been properly analyzed? Is a delivery note associated with a single order in a 1-1 relationship? Can an article belong to a product range or to several?

With an Excel sheet, you bypass the analysis of the entities that make up your data model, their properties, and relationships between them, essential to understand the operation of your business.


An Excel sheet is a simple table. Nothing prevents the user from writing in the wrong cell by mistake, or from crossing data when moving or copying data.

When you develop software, an entity is unique and its encapsulation and integrity are guaranteed. An order has its properties, and there is no possibility of it being crossed with the cost or rate of another order by mistake.


The speed of an Excel sheet is nowhere near the efficiency you can achieve with development. Operations like searching through several thousand rows, which are prohibitive in Excel, are executed effortlessly in software.

It is worth mentioning SQL queries (which I recommend avoiding at all costs). I’ve seen users who, out of ignorance and even with the best intentions, comment that a query in Excel takes 3 minutes to execute. Because it takes so long, it must be a great query, and I’m so proud. Believe me, there’s nothing to brag about in leaving a database hanging for 3 minutes. When you make the same query in 0.3 seconds, then you have a reason to boast.

Data management

Excel sheets can become huge, even more so with the latest expansions they have received. They can hold vast amounts of data. However, it’s nothing compared to what can be stored in a database.

Much more importantly, Excel sheets can hold large amounts of data, but are not capable of managing it properly. Searches are slow and are always critical because it’s easy to make a mistake and provide incorrect results.

In contrast, databases are specifically designed to be efficient in performing searches and crossing data, and are extraordinarily more powerful in data management.


Usually, in modern development, you want actions to be generated. For example, the system should alert you if the stock of a material is below the reorder point, or even automatically place the replenishment order with one or more suppliers.

In Excel, you can’t perform any actions. The system is passive, it doesn’t inform you or perform actions, you can only enter and fill/consult the data.

Conversely, software development can consider any number of workflows regardless of complexity. This has a double advantage in that, on one hand, it forces you to define your processes, and on the other, it allows you to automate tasks. All of this is not possible in a spreadsheet.


Although there have been multiple attempts to improve the way to work in the same Excel sheet, and it is possible to share a sheet so that several users write simultaneously, none of these solutions work properly.

Sharing an Excel sheet, both in a network folder and in online applications, forces us to eliminate many features that we have in an unshared sheet.

In contrast, once again, databases are specifically designed to allow multiple users to access simultaneously, this being their main function.

A separate mention deserves public access, that is, providing limited web access to your clients to consult certain data. All of this is impossible with an Excel sheet.

User interface

Again, an Excel sheet is nothing more than a table. No matter how many colors you put on it, change the font types, combine cells (please do not combine cells), or paste images (another bad idea, by the way), add charts or pivot tables, it can never compare to the interface you can achieve with an App or a Web.

On the other hand, users are increasingly connecting through mobile devices. No matter how many clients there are to view Excel on these devices, they cannot match the visualization and user experience on a responsive Web.


Understanding as protection systems against the misuse of contained information. This includes both accidental manipulation and inappropriate use.

What are the consequences of someone mistakenly modifying the calculation formula of the concrete pillar section of a structure? And those of an angry worker saving the Excel sheet with which you make electrical calculations on a USB drive? And the one where you keep your customer information? Are you aware of the risk this poses to your company?

In software development, you define which users or user groups access what information, and what actions each of them can perform. This security is not possible with an Excel sheet.


Maintaining Excel sheets is often difficult to do. Frequently, these sheets are made by people with high Excel knowledge and who, probably, at the time, put in a lot of effort to make them. It is also common for the same person, months later, to be unable to modify their own tool, or even for it to be used years after the person leaves the company.

Who is responsible for maintaining that Excel sheet? I, for one, don’t if I can avoid it. I’ve found Excel sheets that, honestly, I haven’t dared to touch because they were “held together by pins”. In the end, I always end up replacing them with a well-made development.

Conversely, a properly developed software is designed so that any other developer can support and expand the code.


When addressing an Excel sheet, a sustainability horizon beyond a few months is rarely considered. What will happen to your huge Excel sheet in 2, 3, 5 years, functioning? How much will it have grown? Will it be manageable, or will it be too large? Will you have many files, or all in one? How will you maintain the data, will duplications be created? What if you have to make changes, will you have to go to all the sheets to maintain them?

On the other hand, how will your Excel sheet behave when Microsoft changes the version? And when your workflow changes? Will you at least be able to easily retrieve the information to migrate it to another system?

Similar to maintainability, when approaching a development, it is considered that it is extendable, modifiable, and can be functioning for a long time.


We could say that in a way it is the origin of all of the above. However commendable (even endearing) it may be that a person with concerns makes an effort to train and tries to cover their own needs, IT professionals exist for a reason.

The user does not have specific training in abstraction and encapsulation, is not used to managing data and workflows, does not take into account design factors such as efficiency or maintainability. Concepts that are everyday in an IT professional.


It may seem that creating an Excel sheet is quick. In contrast, developing takes longer and, therefore, has higher costs. Nothing could be further from the truth.

It may indeed initially seem faster to create a spreadsheet and be done with it. But what about the additional benefits of defining your work model and its associated processes? And the advantage of automating tasks? And the loss of time using a tool that is not efficient, and that makes the user waste time every day? And the time for maintenance, expansion, and sustainability?

On the other hand, Excel technology, particularly the integrated VBA (I’m serious, I don’t know how anyone can still program in that) makes development times longer when macros or SQL queries are involved.

The tools available to develop an application, for example, in C# or HTML5, are light-years ahead. Trivial tasks in modern programming, addressed in VBA, force you to develop with 20-year-old technology, which extends the deadlines (in addition to being unbearable).

Even assuming that the time required to create a quick Excel sheet, compared to an equivalent software development, is lower, the truth is that in the second case, you have a much superior product in terms of features, power, and versatility.

When you take into account all the associated costs, in balance, it is cheaper to develop. Believe me, the Excel sheet is costing you money.

Reflection and self-criticism

The Excel sheet is a difficult rival to beat. First, because its use is deeply rooted in the user. They feel like they can customize it, configure it to their liking. It’s simple, familiar, and comfortable for them to use.

The problem is not with the Excel sheet which, on the other hand, is a powerful and really great program (in the end, I’ve recognized it, deep down I love it too). The problem is the use and abuse of Excel sheets. As the saying goes, when you only have a hammer, suddenly everything looks like nails.

On the other hand, as a developer, you’re hardly going to get the user to stop using it if you intend to give them a program whose user interface is basically a table (a grid) as a substitute. Excel will always beat you there because as a table, you won’t be able to surpass the functions that Excel allows.

Recently, user interfaces have undergone a great improvement, largely due to the development of mobile Apps and the Web. As a result, users have become intolerant of poor UI. If you intend for your users to stop using Excel and start using a program with a Windows 98 aesthetic, it will never work. You have to provide them with a much superior aesthetic and functions that they won’t be able to get in a simple spreadsheet.


But, oh friend!… That takes effort! And I’m not just talking about development time, it requires an analysis of the user’s needs, understanding their work model and workflows, and proposing creative and modern solutions. In short, it requires you to do your job well and with “care”.

However, even recognizing that the spreadsheet is a powerful application, a tough rival, and, in certain cases, a useful tool, if we analyze it deeply, spreadsheets do not have a reason for being (or should not have one in a “perfect” world).

Spreadsheets are, in short, programs that allow us to configure “small utilities” quickly. Every time someone uses an Excel sheet, it’s because a program (equivalently, a developer) hasn’t provided what they need.

The Excel sheet is the resource you resort to when you don’t have “anything better.” Therefore, in a framework of continuous improvement, the Excel sheet will always be one of the weak links and, inevitably, it will end up being eliminated.


Beyond quick calculations or making a couple of charts, we shouldn’t have the need to use Excel sheets. It can also be useful as a sketch, or first solution, of what will later become a specific development. In this way, the user is participating in the analysis and abstraction of the problem, and participating in the solution.

But a spreadsheet should never be seen as a permanent solution. Much less as an optimal or desirable one. Certainly, in no case should you base fundamental processes of your business system on Excel sheets.

If you do, sooner or later a competitor will emerge who does things properly. You will find a competitor with superior software to yours, and then you will be in serious trouble because you will be less competitive.

At this point, it is worth mentioning a quote from the Barcelona Forum of 2014, by Jan Muehlfeit, president of Microsoft Europe.

“In three years, all companies will be software companies, education must prepare for that” - Jan Muelhfeit (2014)

I totally agree with this statement. So much so that I allow myself to expand on it. Not only should education prepare, but companies should also do so.

Your competitor has machines similar to yours, has personnel similar to yours, has an economic and financial framework similar to yours. Your software and your workflow may be the only thing that gives you a competitive advantage.

If you don’t invest in development and let fundamental processes of your business model be based on spreadsheets, not only are you at risk, but it’s inevitable that you will be surpassed.

So you know. Start considering the real virtue of spreadsheets and learn to always see them as a non-optimal option, 12 small demons that make you less competitive, and a clear goal to eliminate from your workflows.