Migrating from Excel to custom software: when, how and what to avoid

The conversation happens every few weeks. A call or an email arrives, and the pattern is almost identical: we have a central Excel file that runs the whole business and nobody dares touch it anymore. Sometimes it’s the annual budget. Sometimes inventory control. Sometimes the install planning for the coming quarter. The symptoms are always the same: the file is over 80 MB, there are 14 tabs with formulas only one person understands, and the last time someone copied it to another folder three calculations broke without anyone noticing for two weeks.

Excel is a brilliant tool. We mean that. We use it daily for tasks that wouldn’t justify a custom application. But there’s a point where it stops being a spreadsheet and turns into a hidden application, with business logic, informal permissions, and improvised integrations. After that, maintaining it costs more than replacing it. This post is about that: how to spot the moment, what to avoid in the transition, and how we approach a serious migration when a client asks us to help them leave Excel without losing what Excel was actually giving them.

The 7 signs your Excel has outgrown its job

Every time we audit a process anchored in Excel, we look for these signs. Three or more together usually means the monthly cost of the Excel already exceeds the cost of migrating. The first five are technical. The last two are organisational and, in our experience, the ones that hurt the most when they blow up.

1. Only one person understands the formulas. The classic bus factor. The file started seven years ago, has gone through three Office versions, and the person who designed it is now part-time. When someone asks how a field is calculated, the answer is “Mary knows”. If Mary leaves, the Excel becomes a black box that operational decisions depend on.

2. There are three versions of the file and no one knows which is the right one. The master is on the server, but there are copies on desktops, in inboxes and in a Dropbox folder someone shared with an external sales rep back in 2023. Every so often discrepancies appear between versions and the only way to resolve them is by file timestamp or because “the last one Mary changed was on Tuesday”.

3. Constant locks from concurrent editing. Two people need to touch the file at the same time and one of them has to wait. Or worse: Excel warns them that “the file is being edited” and they decide to work on a local copy, promising to consolidate later. Spoiler: it doesn’t consolidate well.

4. Copy-paste errors discovered late. A shifted row, a formula that used to point to another sheet but now references a static value, a column that was sorted alphabetically without extending the selection to adjacent columns. By the time the error is caught, three monthly reports with incorrect data are already circulating.

5. It’s impossible to audit who changed what. Excel records who opened the file last, not who modified each cell. When a critical figure shifts between Monday and Tuesday, there’s no way to know if it was human error, an approved change, or an automatic recalculation after a quote refresh.

6. The Excel drives operational decisions but doesn’t connect to anything. Real stock lives in the Excel. Invoices are generated from the ERP. Orders come in through the website. Every morning, someone spends 40 minutes manually updating the Excel with data pulled from the ERP and the web. That invisible work is the first real indicator that the process no longer scales.

7. It takes a while to open, and we’ve normalised that. When the file sits around 70-100 MB, opening it takes 30-50 seconds. Filtering, another 10. Any change recalculates half the workbook. People accept it as part of the job, but you’re paying several minutes per person every day for the friction.

If you recognise three or more in your case, you’re not obliged to migrate yet. But the cost of not doing it is considerably higher than it looks at first glance.

When Excel is still the right answer

Sometimes the pain we feel when we see a process backed by Excel is disproportionate to the real problem. These are the scenarios where we don’t migrate, and we tell the client even when they come to hire us:

• One-off or low-frequency processes. If the file is touched once a month and run by a single person, it’s fine where it is. Friction is minimal.
• Ad-hoc analysis. Excel is the best tool on the market for exploring data freely before you know what question you want to answer. Any custom application will limit you to what the application anticipates.
• Prototyping a new process. If you’re still defining how something will be done, don’t build an application. Iterate in Excel until the process is stable. Only then does it make sense to invest in systematising it.
• Teams of fewer than 5 people with a single analyst who masters the file. Here the bus factor exists, but the cost of migrating is usually higher than the risk for several years.
• Periodic reporting connected to a single, stable data source. If the Excel is a viewing window for data that comes from elsewhere and the format doesn’t change much, it doesn’t need to be an application.

Migrating out of modernity, aesthetics, or because “Excel is a thing of the past” is a bad reason. Migrating because the monthly cost of the Excel is now weighing on you, that’s the good reason.

The 3 traps when migrating (and how we avoid them)

When a migration fails, it almost always fails for one of these three reasons. Not because of the technology chosen.

1. Wanting to replicate the Excel 1:1 in the new app

The temptation is enormous: since the Excel “already works”, the development team is asked to reproduce exactly what it does, but on a nice web screen. The result is an Excel disguised as an application, with all the limitations of the original and none of the real advantages. Flows that made sense in a spreadsheet (filling 40 columns in a single row, for example) are anti-ergonomic in a web interface.

What we do instead: redesign the process taking advantage of the tool change. If the Excel needed 40 columns because it couldn’t be split into related entities, now it can. If the validation list was a separate tab updated by hand, now it’s a master table editable by permissions. Migrating is the only chance in years to rethink the flow, not the opportunity to fossilise it.

2. Moving everything at once (big bang)

The other temptation: since we’ve decided to migrate, we’ll migrate it all at once and switch off the Excel on a Friday at 6 pm. This fails for several reasons. First, nobody fully trusts the new system on day 1, and they keep the Excel running in parallel “just in case”. Second, the secondary flows (the ones nobody documented because they were obvious to whoever used the Excel) show up in production as urgent bugs. Third, the team burns out for 9 months without delivering anything truly usable.

What we do instead: migrate by modules, with deliveries every 2-3 weeks. Start with the module that hurts the most, put it in production, let it coexist with the Excel for a period, validate that it works, and only then move to the next. The part of the Excel that hasn’t been migrated yet stays operational until its turn. We cover this in more detail in Modernising a legacy ERP: when to migrate and when not to, because the pattern is the same: gradual strangulation, not full replacement.

3. Not involving the people who use Excel every day

The political error, not the technical one, and the most expensive of all. If the person who’s been maintaining the Excel for years learns about the migration through an email, the project is doomed. They see it (with reason) as a vote of no confidence in their work. And since they know the corners of the process better than anyone, their reservations will have solid arguments.

What we do instead: bring that person into the discovery team from week 1. Their knowledge of the real process (not the documented one) is the project’s biggest asset. They usually end up as internal references for the new system, training the rest of the team. And above all, they’re the ones who catch the edge cases before they reach production.

How we approach a serious migration

The pattern we apply when a client asks us to help with a process backed by Excel is always the same, adjusting duration to case complexity.

Excel audit (2-3 weeks). Before we talk technology, we want to know what the file actually does. Not what the internal documentation says. Not what the team thinks. What it does. That means reviewing formulas, macros, hidden sheets, validations, external connections, and interviewing whoever uses it. We come out with a process map, a list of critical fields, and a classification between what’s business logic and what’s Excel ergonomics (filters, sorts, groupings).

Discovery with real users (1-2 weeks). Short sessions with the people who use the Excel every day. Not with managers who supervise it from afar. This is where undocumented flows, edge cases, and tacit decisions that the Excel “allows” but the documentation doesn’t capture come out.

Module roadmap. We break the process into independent modules and prioritise them by current pain and migration risk. The most painful module is usually the one that generates the most motivation in the team when it’s delivered. The riskiest one we leave for when there’s already trust in the new system.

MVP of the first module (4-6 weeks). Minimum version of the most painful module, in real production, with real data. Coexisting with the Excel for at least one full operational cycle (a month, a quarter, depending on the case) to detect inconsistencies.

Module iteration (variable). Every 2-3 weeks, a new module or an improvement to the previous one with feedback from real use. No long silent gaps. No “I’ll be back in six months with this finished”.

Excel shutdown (when appropriate). Only when all critical flows have been in production for at least a quarter without incidents does the Excel go into consultation mode. It’s kept as historical record for audit, but stops being the source of truth.

How much this actually costs

Talking about cost is what’s hardest to talk about honestly, so let’s get to it. For an SMB with a reasonably scoped operational process (5-20 users, 1,000-3,000 active records, integration with 1-2 existing systems), the usual range of total investment is:

Process size	Total investment	Delivery time	Payback
Small (1 module, up to 5 users)	15,000-25,000 EUR	2-3 months	8-14 months
Medium (3-4 modules, 10-20 users)	30,000-60,000 EUR	4-6 months	14-22 months
Large (5+ modules, ERP/CRM integration)	70,000-150,000 EUR	6-9 months	20-30 months

The payback period is calculated against the real cost of the current Excel: hours spent on manual consolidations, errors corrected after the fact, decisions made with outdated data, and, above all, the opportunity cost of not being able to attack new business lines because the process doesn’t scale.

Before investing in custom software, it’s worth checking whether a specific SaaS covers the case. Sometimes yes, sometimes no. We cover that decision in Custom software vs SaaS: when to choose each. Short version: if your process is standard for your sector and isn’t your differentiator, look for SaaS before custom. If your way of running that process is part of what differentiates you, custom pays.

A concrete example: Power Time

Power Time is our own case of migrating from Excel. Before we built it, several of the clients we worked with were running time tracking in Excel: one sheet per month, manual clock-ins every morning, formulas to calculate overtime, a hidden column for outstanding holidays. It worked while the headcount was small. From 15-20 employees on, the cost of maintaining the Excel already exceeded that of any dedicated solution, and there was a clear regulatory risk too: Spain’s RD-Ley 8/2019 demands record immutability, something Excel doesn’t guarantee out of the box. Other EU markets have analogous statutes (Germany’s BAG ruling, France’s Code du travail).

We built it as a product because the problem was standard (every company with employees has the same obligation). If it had been a differential process of a single company, we’d have built it custom. The line between both decisions, again, is how standard your process is.

If you’re at this point

If you recognise three or more signals in your Excel and you’ve started doing the maths on what it costs you not to migrate, let’s talk. Half an hour is enough to know whether your case justifies a serious migration or whether it’s not the time yet. We say the second one too, without pushing a proposal that won’t pay you back.

Resources

• Custom software vs SaaS: when to choose each: the parallel decision worth making before you start.
• Modernising a legacy ERP: when to migrate and when not to: the same pattern applies to legacy systems, not just Excel.
• VisibleSoft services: what kind of migration projects we take on.
• Book a free diagnostic