Spreadsheet to Database: When to Make the Move

A spreadsheet to database move is a decision, not a default. A workbook is often the right place to start: flexible, visible, and changeable this afternoon. The useful question is narrower. Is this file still a workspace, or has it become the record other people act on?

If a critical file has already become a liability, the failure modes are in when a spreadsheet has already become a liability. This guide is the prior question: should it move at all, and how far. Not every reader should leave Excel. Most files should stay.

When a spreadsheet is still the right tool

The Institute of Chartered Accountants in England and Wales says to determine whether a spreadsheet is a suitable tool before you rely on it. A table of text may belong in a document. Large quantities of similar items may belong in a database. A settled process, such as bookkeeping, may belong in software built for that job. They also ask whether the people who maintain the file can still understand the data and the logic.

Keep the workbook when the work is analysis, a model, or a draft, and one accountable person, or a small group, can see the whole file. A wrong cell should be visible, not a customer or payment problem. If several teams each keep a version, you have no agreement about which is current. If the process is still changing, leave it in the grid. Software freezes steps that are not yet real.

Co-authoring does not change the test. Microsoft 365 Excel can let several people edit the same cloud workbook, with a supported version and the file on OneDrive or SharePoint Online. Microsoft’s guidance says that, in general, the last change saved is the one that wins. That is not the same as roles, required fields, or a rule for which status may follow which.

The row limit is the wrong trigger. Microsoft’s current specifications list a worksheet maximum of 1,048,576 rows by 16,384 columns. A slow file is a symptom. The decision is whether people can still trust a single current record.

Signals you have outgrown it

Move the conversation on when several of these are true of a file other people rely on. One of them, on a personal tracker, is not a reason to rebuild.

People cannot say which copy is current without asking. The same fact is typed more than once, and the copies drift. That is a data quality problem: no single home for the fact.

A wrong cell would affect a customer, a payment, stock, or a record you would have to explain. Access is whoever has the link, so you cannot say who may change a status and who may only read. The logic lives in one person’s head. A new tool will not fix that unless the steps are written down first, as an SOP.

Reporting means exporting and hoping the tidy version still matches. Or the workbook is being asked to approve and assign, as well as calculate.

Tab count and macros are weak signals on their own. A large file that one analyst maintains, and that nobody else treats as the live record, can stay where it is.

What a system means

A system, here, is not a product name, and not a custom build by default. It is a place where four things hold.

Shared data. A customer, a job, an invoice: each has one home. Related facts point at it. They are not retyped into the next tab.

Permissions. Roles decide who can create, change, approve, or only view. A shared link set to “can edit” is not that.

An audit trail. You can see who changed a field that matters, and when, without comparing two emailed files. Not every thought. The edits you would need if a number were challenged.

One source of truth. If the workbook and the tool disagree, you already know which one wins. Until that is written down, you have two records and a reconciliation job.

That home is often a product you can buy. A CRM for the pipeline. Accounting software for the books. A stock system for quantities. Do not rebuild a settled process if a package already does the job.

A scoped system is the smaller set: statuses, approvals, or exceptions the packages you have tested cannot hold. Read when an off-the-shelf product is not enough before you assume a build. Many files never get there.

If the workbook is a process rather than a list, you may also need workflow automation: a status that moves, a person asked to approve, a note required before the next step. Automating a process you cannot describe only carries the confusion into the new place.

Keep what the spreadsheet did well: visible numbers, a cell you can fix, a cut of the data without a request. If the new place hides the figures, people will go back to the file, and the workbook becomes the real system again.

A spreadsheet to database move, one file at a time

Do not set a date for moving everything off Excel. Pick the one file where a wrong version already produces a correction you can name. Then stop.

Write what it does: inputs, outputs, who edits, who only reads, and what a wrong number would affect, including exceptions the owner keeps in their head. If you cannot write this, you are not ready to move the data. Choose the smallest change that restores a single current record: tighter controls on the workbook, an existing product, or a scoped build for the part the products cannot hold. Not all three at once.

Name the source of truth before you move a row. During any overlap, say which side wins if they differ. Run both until a sample you defined in advance agrees. There is no standard number of weeks. Stop if the new place cannot hold an exception you still need.

Keep a way back. Archive the workbook, and agree who may still open it. Analysis is a fair reason. Treating the archive as the live record is not. A spreadsheet fed by a checked export can still hold a forecast. Saving that cut back as the master is the failure.

A data pipeline between the new record and the reports people still want in a grid is a later step. If you automate the copy before the fields are stable, you automate the argument.

Fernside does not sell a spreadsheet product, and we do not arrive with a migration date. If you want a second opinion on which file to leave alone, that is an advisory conversation: map the job, then recommend the smallest change, including keeping the workbook. Get in touch with the inputs, the outputs, and who relies on the file.