When is it worth replacing Excel with a custom web app?

Replacing Excel with a custom web app is worth it when a spreadsheet has quietly become a shared business system: several people edit it, other processes depend on it, and mistakes in it cost real money or create compliance risk. If one person uses a workbook for analysis, Excel is almost always the right tool and you should keep it.

The decision is not "Excel or software". It is about where your data, rules and permissions should live. This article explains when spreadsheets are fine, when to move, the three realistic options, what a migration actually involves, what drives the cost, and how to phase the change so the business never stops.

When Excel is the right tool

Spreadsheets are excellent at what they were designed for. We regularly advise clients to leave a workbook alone when:

• One person or a small team owns it, and nobody else edits it.
• It is exploratory: modelling scenarios, one-off analysis, ad hoc reporting.
• The structure changes often, and the flexibility of adding a column in seconds matters more than control.
• Errors are cheap: a wrong number is caught before it affects a customer, a payment or a regulator.
• Nothing downstream depends on it: no other system imports it, no one emails it on as "the latest version".

Modern Excel also handles more than people assume. Microsoft 365 supports co-authoring, so several people can edit a workbook stored in OneDrive or SharePoint at the same time. If simultaneous editing is your only pain, try that first.

When it is time to move

The signals are usually operational rather than technical. Move when several of these are true:

1. The workbook is a system of record. Orders, client positions, stock, pricing or approvals live there and nowhere else.
2. Multiple people edit it and versions conflict. Files called final_v3_JM.xlsx circulate by email.
3. Time goes into reconciliation, not analysis: people compare copies, chase changes and fix formulas.
4. You need to know who changed what and when, for an auditor, a regulator or simply to resolve disputes.
5. Different people should see different data, and hiding sheets or password-protecting cells is the current answer.
6. Data is copied in and out of other systems by hand: exports from the ERP, pastes into the CRM.
7. One person understands the formulas, and their holiday is a business risk.

For a deeper checklist with ways to test each signal, see signs your business has outgrown spreadsheets.

A worked example

Example: a team of 6 people each spends 5 hours a week merging copies, checking formulas and re-entering data. That is 30 hours a week, or roughly 1,300 hours a year allowing for holidays. Multiply those hours by your loaded hourly cost, then add a realistic estimate for the cost of errors that slip through. Compare that annual figure with the cost of building and running an application over three years. The numbers here are hypothetical; the method is what matters. We cover it in more detail in how to calculate automation ROI.

Your three options

Low-code and no-code tools

Platforms such as Airtable, Microsoft Power Apps or similar database-backed app builders let you replace a spreadsheet with forms, views and basic permissions quickly. They are a good fit when the logic is simple, the user count is modest and you accept the vendor's limits on data model, integrations and pricing as you grow. Pricing is usually tied to users or usage: Airtable bills per seat with edit access, and Power Apps offers per-user and pay-as-you-go plans. Model the cost at your expected size in two or three years, not today's.

Off-the-shelf SaaS

If your spreadsheet is reproducing a standard process (CRM, inventory, project tracking, invoicing), a mature SaaS product probably does it better than anything you would build. The trade-off is that you adapt your process to the product. That is fine when your process is not a competitive advantage.

A custom web application

Custom software makes sense when the workflow is specific to your business, involves real-time data or integrations, needs fine-grained permissions or an audit trail, or when the alternatives would force awkward workarounds. You own the code and the data model, and it can grow with the process. The cost is a larger upfront investment and the need for someone to maintain it.

A simple rule: use SaaS for standard processes, low-code for simple internal tools, and custom software for the processes that make your business different or carry the most risk.

What a migration actually involves

Replacing a spreadsheet is less about building screens and more about making implicit rules explicit.

1. A real data model

Spreadsheets mix data, calculations and presentation on one grid. The first job is to separate them: which entities exist (clients, positions, orders), how they relate, which fields are required and which values are allowed. This is where most hidden inconsistencies surface, such as the same client spelled three ways.

2. Permissions

Decide who can view, create, edit and approve each type of record. Role-based access, enforced on the server and ideally in the database, replaces hidden sheets and locked cells.

3. An audit trail

Every change should record who made it, when, and the before and after values. In regulated industries this is often the main reason to move, and it is far easier to build in from the start than to add later.

4. Imports and integrations

Map every place data enters the spreadsheet today. Replace manual pastes with API integrations where possible, and keep a validated file import for sources that only offer exports. Imports should reject bad rows with a clear message instead of silently accepting them.

5. Keep an Excel export

People will still want to analyse data in Excel, and that is healthy. Provide exports of filtered views so analysis stays flexible while the system of record stays controlled. This one feature removes a lot of resistance to change.

6. Data migration and validation

Clean the historical data, load it, and reconcile totals against the original workbook before go-live. Agree in advance which history needs to move and which can stay archived as a read-only file.

What drives the cost

We do not quote amounts in articles, because the range is wide and depends on specifics. These are the factors that move the cost most:

• Number of distinct workflows and screens, not the number of rows of data.
• Integrations: each external system adds work, especially without a good API.
• Real-time requirements, such as live price feeds or instant updates for many users.
• Permissions and audit depth, especially for regulated data.
• Data quality of the existing spreadsheets, which determines migration effort.
• Hosting, security and compliance expectations, including backups and uptime.
• Ongoing changes: budget for maintenance and small improvements after launch, not just the first release.

Risks and how to phase it

In our experience the main risk is not technical. It is replacing a flexible tool with a rigid one that misses rules nobody wrote down. These practices reduce that risk:

1. Start with discovery. Sit with the people who use the workbook, and list every formula, macro, manual step and downstream consumer.
2. Pick one workflow first. Migrate the highest-pain, best-understood process end to end before expanding.
3. Run in parallel. Keep the spreadsheet running alongside the app for a defined period and compare outputs until they match.
4. Freeze the old file. Once you switch, make the spreadsheet read-only so two sources of truth never coexist.
5. Train and listen. Short onboarding, then a quick feedback loop for the first weeks.

A European asset management firm we worked with had 30 analysts managing portfolios through spreadsheets and email. Version mismatches and manual reconciliation were costing roughly 12 hours per analyst per week. Over 14 weeks we built a multi-user platform with live price updates, role-based permissions and a full audit trail. The analysts saved around 12 hours a week each, and all 30 were onboarded in under 2 days with no data migration issues. Read the full case study.

Decision checklist

Score one point for each statement that is true:

• More than three people edit the workbook regularly.
• It is the only place a critical type of record exists.
• Someone spends hours each week reconciling versions or re-entering data.
• You need an audit trail or role-based access.
• Data moves by hand between the workbook and other systems.
• A formula error has already caused a real problem.
• Only one person fully understands how it works.

With 0 to 2 points, keep Excel and tidy it up. With 3 to 4, try co-authoring, a low-code tool or a SaaS product first. With 5 or more, a custom application is likely worth a proper assessment.

Frequently asked questions

Will we lose the flexibility of Excel?

Not if the system is designed well. The controlled data lives in the application, and users can still export filtered data to Excel for their own analysis. You lose the ability to change the structure of shared data without review, which is usually the point.

How long does a migration take?

It depends on the number of workflows, integrations and the state of the data. A single well-defined workflow can often go live in weeks, while a platform with live data and compliance needs takes a few months. Phasing lets you see value before the whole system is finished.

Can we start with low-code and move to custom later?

Yes, and it is often sensible. The work of defining the data model and permissions carries over. Just keep your data exportable so you are not locked in if you outgrow the platform.

Do we need to migrate all our historical data?

Not always. Many teams migrate active records and recent history, and archive older files as read-only. Decide this early, because it affects both effort and validation.

If a spreadsheet has become critical to how your team works, see how our custom software development service approaches these projects. When you're ready, book a call to walk through your workbook with us, or request a quote.