Signs Excel is no longer enough
Excel is an excellent tool, and there's nothing wrong with a company running on spreadsheets. The problem starts when the spreadsheet stops keeping up with the business. These are the signs I see most often:
- There are several versions of the same file ("stock_final_v3_really_final.xlsx") and nobody knows which is the right one.
- Only one person understands the formulas. If they get sick or leave, nobody dares touch anything.
- The same data is entered in several places: the sales sheet, the inventory sheet and the invoicing system.
- Two people can't work at once, or they overwrite each other's changes.
- Everyone sees everything. There's no way to let each person see only what's relevant to them.
- There's no history: you can't tell who changed a price or when.
- The file is slow to open or freezes with every new row.
The core idea: it isn't about abandoning Excel, but about no longer using it as a database. For analysis and exports it's still ideal; for storing business information that several people use at once, it isn't.
What to keep from your spreadsheets
Your spreadsheets are your best specification. Every column, every formula and every "helper" tab is a business rule that someone worked out over the years: how a price is calculated, which discount applies to whom, when an order counts as ready. A system that ignores all that forces your team to work differently overnight.
That's why the first thing I do is sit down with the people who use the spreadsheets. I note what data they handle, what calculations they run, which columns nobody touches and which are used every day. I also look for the workarounds: the cell painted red that means "don't ship", the comment that says "careful with this customer". All of that is hidden business logic the new system has to respect.
Migrate in stages, not all at once
The most common mistake is trying to replace everything at once: months go by with nothing to see, something unexpected goes wrong on switch-over day and the team goes back to spreadsheets. I prefer going in stages, so each one is useful on its own:
- Pick the biggest pain. For example, quotes or inventory. That's what gets built first.
- Build that part and get it running. The rest of the business stays on spreadsheets for now.
- Adjust with real use. The first weeks surface details no prior meeting can anticipate.
- Add the next stage and repeat, until the spreadsheets are no longer needed.
That way operations don't stop, the team gets used to it gradually, and if something doesn't work it's fixed before moving on. With a custom web application this comes naturally, because the system is built in modules that can be added over time.
The data: cleanup and import
Spreadsheet data is almost never ready to import as is. It's normal to find customers spelled three different ways, dates stored as text, prices with currency symbols in the cell or duplicate rows. Before importing, you need to:
- Unify and deduplicate: each customer, product or supplier should exist only once.
- Normalize formats: dates, numbers, phone numbers, codes.
- Decide what to import: not all history is worth it; sometimes it's better to migrate the last few years and archive the rest.
- Test with a copy: import into a test environment first and compare the totals against the original spreadsheet.
The differences that show up in that comparison are usually old spreadsheet errors nobody had noticed. It's part of the value of the process, but it's worth knowing it happens and takes time.
Coexistence and training
For a while, the new system and the spreadsheets will coexist. Ideally you set a date from which the system is the source of truth: from that day on, data is entered there and the spreadsheet becomes read-only. Until then, if needed, you can run both in parallel for a few days to compare results and build confidence.
As for training: a good system doesn't need a hundred-page manual. I design it with your team, using their own terms and screens close to what they already know, and I'm around for the first days of use. It also helps that the system can export to Excel: anyone who needs a special view can keep building it with the tool they know.
The nursery case
The management system I build for a plant nursery is a good example of this approach. It didn't start as a complete system: it has grown in stages since 2021, as the business needed new features. Today it has quotes, price lists, a customer portal, inventory, barcodes and electronic invoicing, and it keeps evolving without ever being rewritten from scratch.
That's the underlying idea: you don't need to define everything up front. You start with what hurts most, you use it, and the system adapts to the business rather than the other way around.
How I approach it
I start by looking at your spreadsheets and understanding how your team works. From that I propose a focused first stage, with scope, timeline and price, and an idea of how the next ones would go. If you'd rather see the big picture first, I can also do a technical audit of what you have today.