Custom management system or Excel? When the spreadsheet becomes a risk, and how to migrate without stopping

Excel is an extraordinary tool, and most of the custom management systems I have built replaced a spreadsheet that had done its job admirably for years. The point is not that Excel is wrong: beyond a certain threshold, the sheet stops being a tool and becomes the most fragile part of the business. Recognising that threshold, and crossing it without stopping work, is what this article is about.

The signs, read by a developer

Data integrity

A sheet without data validation and proper protections lets errors through: a date written as text, a customer code with an extra space, a formula overwritten by a value. Every error spreads silently. A database can enforce types, constraints and relationships, if designed explicitly. Application validation and business-rule checks remain necessary.

Concurrency and versions

Two people work on the same file, or on two copies. Out come "final_v3_corrected.xlsx" and the question "which one is the right one?". Sharing the file in the cloud reduces copies and conflicts, but does not replace transactions and concurrency rules designed for the process.

Permissions

People who should see only their own data see everyone else's, or cannot get in at all. A shared sheet has permissions per file, not per row or per role.

Traceability

Who changed that price, when, and what was there before? The file's history can help, but it must be kept distinct from an application audit log that records business operations and the values changed.

Dependence on one person

Only whoever built "the file" understands it. Nested formulas, macros, hidden sheets. When that person is away, the business slows down.

Features the sheet lacks

Mobile access in the field, notifications and deadlines, payments, generated documents, integrations with other systems. At that point people build chains of files, macros and manual copies.

Before deciding: ready-made or custom

Is there ready-made software that covers the indispensable requirements without bending the process? Then it deserves serious evaluation, along with its APIs and its cost over time. Custom makes sense when the process is specific and central to the business, and ready-made products force you to work worse than before.

How it is designed

The data model before the screens

Entities, relationships, constraints: clients, cases, resources, bookings, payments, and how they connect. It is the part that lasts longest and the most expensive to change later. The screens follow from it.

Roles and permissions

Who sees what and who can do what, defined by role and enforced on the server, not by hiding buttons in the interface.

Change log

Every important operation leaves a trace: who, when, values before and after. It is an application-level trace, separate from the version history of a file.

Integrations

Payments, invoicing, email, calendar, website. Each as a separate module, with error handling.

How to migrate without stopping

1. Analyse the existing sheets: columns, formulas, exceptions, misuse. The sheet often holds business rules written down nowhere else.
2. Repeatable import script: mapping to the new model, normalisation, deduplication, a report of rejected rows.
3. Repeated migration rehearsals on real data, until the rejection report is empty or explained.
4. Release by module: the most painful feature first, then the others. For a few weeks the sheet stays read-only as a reference.
5. Short training on real workflows, not on the manual.

The most common mistakes in custom projects

• Reproducing the spreadsheet as it is: same columns, same habits, including workarounds born of Excel's limits. The process should be rethought, not copied.
• Starting from screens: without a solid data model, every new feature becomes an exception.
• Everything at once: a single, complete release instead of successive modules increases risk and delays value.
• Permissions postponed: adding roles and restrictions to a finished system costs far more than designing them upfront.
• No export: data must always be able to leave in open formats.
• Users left out of the analysis: whoever works on the sheet every day knows the exceptions no document records.

A good project starts with a few features that solve the most expensive problem, gets used for real, and grows from what that use reveals.

A real case: Altura Vela

When I met Altura Vela, their management lived in huge, unmanageable Excel sheets. Yet for them those sheets were a lifeline: they had kept the business going for years and could not be removed overnight. So I did not propose replacing them: we built the management system together, with careful and meticulous development, step by step, checking every result against the sheets. Boats, skippers and members ended up in one place, with Stripe payments and some AI features that take repetitive work off whoever organises courses and outings.

Today only the management system is used, and we remember the old sheets with a smile. The most tangible result is operational: the school manages more boats than before without its organisation getting heavier. This is the path I consider right: the spreadsheet is not an enemy to knock down, it is the document that tells you what the new system must do.

Example: preventing a silent overwrite

In a PostgreSQL example, a booking has an integer version column. The client sends the version it read; the server applies the update only if it matches:

UPDATE bookings
SET status = $1, version = version + 1
WHERE id = $2 AND version = $3
RETURNING id, status, version;

The query uses parameters, not concatenated strings. Authorisation checks remain mandatory on the server. If no row is updated, the application distinguishes an inaccessible record, a missing record and a conflict without exposing information to unauthorised users. A conflict requires a re-read and an explicit choice, not a second blind submission.

In the migration I also compare totals and relationships, not only the number of rows. I log the rejected records and set when writes to the old sheets stop, so the switch does not create two sources of truth.

My take

The Altura Vela case is the project I have in mind as I write this: the management system is an application I designed and built from scratch in Nuxt.js.

For this kind of tool I choose a web application: one codebase, usable on computer and phone, updated with a deploy. And I build with the data model at the centre, because that is where a management system lives or dies.

One practical piece of advice: do not throw the spreadsheet away too early. In the first weeks it is the reference used to check the new system produces the same results, and it often reveals rules nobody had mentioned. Archive it when the numbers match, not before.

Why work with me

I have been programming since 1999: more than 300 projects delivered and more than 30 agencies I have worked with, from Rome and remotely. I design custom management systems starting from the data model, with role-based permissions, a change log and migration of existing spreadsheets.

If your work depends on a file only one person understands, get in touch: in a call of about 20 minutes we look at the process and work out whether a ready-made or custom product makes more sense. The service is in Custom apps and management systems.