Replacing Excel: when the spreadsheet is already a risk
Identify critical Excel files, build a usable substitute, and migrate without paralyzing the business — step by step, not a big bang.
The problem
Excel is brilliant. That's why the entire company relies on 'the sales Excel', 'the stock one', and 'the one only Luis understands'. When Luis is on vacation, a formula breaks, or two people edit the Friday version, the business suffers.
Symptoms of critical Excel: versions circulating via email, macros no one maintains, data without permissions, copy-paste errors, and reporting that no one fully trusts.
Replacing Excel is not about banning spreadsheets. It's about taking the processes that are already part of the production system and moving them into software with users, history, and rules.
If this sounds familiar, you're not alone: most SMEs reach the same point before considering building. The question is not 'Can we afford custom software?' but 'How much does it cost to continue as we are for another year?'. That cost — hours, errors, lost opportunities — is often greater than that of a well-defined first milestone.
Critical Excel tends to grow until a macro takes minutes to recalculate or someone accidentally deletes a row. That moment is the natural trigger for a first web module.
In practice, ROI is measured in weeks: hours saved from copying data, errors that no longer occur, and decisions made with same-day information. If you can't estimate that saving, it's worth doing before asking for a quote — we help with diagnosis to put conservative numbers.
If you've made it this far, you've probably already discussed internally that 'we need a system'. The next step is not to ask for three generic quotes: it's to write a paragraph about what the system should do on Monday when it goes live and who will validate it. That defines the MVP better than any list of features copied from a competitor.
What it means to replace Excel with software
It is to build a web application (or extend an existing one) that does what the spreadsheet currently does: capture data, apply rules, display listings, and generate reports — with a database, permissions, and backups.
The migration is usually gradual: first the most painful flow, temporary coexistence with exports to Excel if necessary, and extension to related processes.
The goal is not a giant ERP. It's to eliminate the risk of the file that supports a critical process.
At RUMAZA, we approach it with verifiable deliverables: something in production that the team uses, adoption metrics, and a roadmap for later phases only if the previous phase adds measurable value. No infinite roadmap or paying for fluff.
We maintain Excel export if needed for specific cases or management. The difference is that the source of truth is no longer the spreadsheet shared via email.
The relief is palpable when you stop asking 'Which is the correct version?' and there are URLs, permissions, and backups.
The migration is not a big bang: controlled coexistence with exports for a few weeks reduces team panic and allows for number comparisons between old and new.
When it makes sense
- More than 3 people regularly edit the same Excel
- An error in the sheet has economic or legal impact
- You need to connect that data to another system
- The file exceeds manageable performance or size
- Management does not trust the numbers until they are reviewed manually
- You've been saying for years 'this should be systematized'
- Management asks for visibility and the data takes days to be ready
- An error in the current process has a direct impact on the client or margin
- You've tried patches (macros, Zapier, templates) and they no longer handle the volume
- You want to document the decision criteria before investing — this guide to replacing excel helps you compare options
- You're looking for a partner who speaks in deliverables, not in undefined hours of 'analysis'
- You want to compare build vs buy with numbers before signing
What can be built
1:1 Replacement Panel
Same columns and logic, but multi-user and with history. Designed for real adoption: simple screens, validated data, and fewer fields than a generic SaaS.
Forms and validation
Less human error than unrestricted free cells. Designed for real adoption: simple screens, validated data, and fewer fields than a generic SaaS.
Automatic reporting
Dashboards that update themselves, without manual pivoting. Designed for real adoption: simple screens, validated data, and fewer fields than a generic SaaS.
Integration with ERP/CRM
End of weekly export-import. Designed for real adoption: simple screens, validated data, and fewer fields than a generic SaaS.
Import from legacy Excel
Initial load and reconciliation tools. Designed for real adoption: simple screens, validated data, and fewer fields than a generic SaaS.
Subsequent evolutionary phase
Expansion of the initial module with new integrations, roles, or reporting — only after validating adoption and ROI of the previous phase. Avoid building features that no one requested in the urgency of day one.
How RUMAZA would build it
Possible technologies
- Django
- PostgreSQL
- Next.js
- Import CSV/XLSX
- APIs
- Pandas (migrations)
- Dashboards
Application scenarios
Excel that only one person understands
Fragile formulas and fear of touching the sheet. System with explicit rules, permissions, and change history.
Multiple versions of the same file in email
'Final_v2_definitivo.xlsx'. Shared database with a single source of truth and validations upon data entry.
Excel as the basis of a critical process
Orders, stock, or weekly planning. First milestone: digitize that flow before addressing the rest of the company.
Common mistakes
- Trying to digitize all Excels at once
- Not replicating the exceptions that the team handles in the sheet
- Forcing a change in habits without a transition period
- Ignoring Excel export for specific cases
- Not naming an internal owner for the new system
- Postponing the decision another year 'until we grow a bit more' — chaos also scales
- Not measuring before/after: without a baseline, you don't know if the project worked
- Requesting a quote without defining MVP or a person to validate deliverables on behalf of the business
Frequently asked questions
Do we need to eliminate Excel completely?
No. Just take the processes that are already critical operations out of Excel. For ad hoc analysis, it may still be useful.
How long does it take to replace an Excel?
A medium-sized well-defined Excel: 4–8 weeks until MVP in production.
What if the Excel has complex macros?
We document them and replicate the logic in the backend where appropriate. Sometimes we simplify obsolete rules.
How much does it cost?
Between €3,000 and €12,000 depending on complexity. Well below the cost of a serious operational error.
Can I export back to Excel?
Yes, if you need it for specific cases or management. The difference is that the source of truth is no longer the sheet.
How do I know if we are ready to take the step?
If you can name a specific process that hurts every week, there is an internal owner willing to validate, and the cost of the status quo is greater than €5,000–10,000 annually in time or errors, it deserves a diagnostic conversation. If not, sometimes it’s enough to organize data and use what you already have better.
What about the formulas that only one person understands?
We document them in the diagnosis and decide what to automate in the backend and what to simplify. Often there are historical rules that no longer apply.
What concrete deliverables do I receive at each phase?
At each milestone: code in your repository, staging environment for testing, deployment and usage documentation, and acceptance criteria signed before going into production. We don’t just deliver a ZIP or an 80-page PDF that no one reads. The deliverable must be usable by someone other than the developer.
Do you work with internal teams or only external?
Both. If you have a technical person, we integrate into your workflow (Git, tickets, reviews). If not, we take on the complete operation but leave documentation so you are not held hostage. We recommend at least one business representative to validate each sprint.
What happens if our process changes in six months?
A custom system should evolve with you. That's why we avoid shortcuts that prevent changing rules: readable code, documentation, and improvement phases. Small changes go to maintenance; model changes are budgeted as a new phase with clear impact.
How are permissions and security managed?
Roles defined from the MVP: who sees, who edits, who approves. Authentication with email/password or SSO if you already use it. Sensitive data encrypted in transit, automatic backups, and logs of critical actions. It's not paranoia: it's to prevent an intern from exporting the entire customer database unintentionally.
Do you offer training to the team?
Yes, a practical session of 1–2 hours on the delivered workflow, plus brief documentation with screenshots. We prefer training on the real MVP, not on 50 features that will come in phase 2. If support is needed in the first weeks, it is agreed as post-launch support.
What is the first concrete step if I want to move forward?
A message with the process that hurts the most, who suffers from it, and what tools you currently use (even if it's Excel). In 48–72 hours, we respond with a recommendation for the first milestone, order of phases, and rough estimation — without commitment to a closed project if it doesn't fit.
Related guides
Do you have this problem in your company?
Tell me and I will tell you what system I would build.