Move a spreadsheet into a database when more than one or two people update it at the same time, when it holds records the business runs on (jobs, customers, stock, assets, compliance items) rather than analysis, and when a mistake in it would reach a customer, an invoice or the accounts before anyone noticed. The move itself has four parts: work out what the spreadsheet really does, clean the data, build the database with simple screens for entering and finding records, and run both side by side until you trust the new one. The spreadsheet often stays, for analysis and what-ifs, reading from the database instead of being the database.
This post is for owners and managers who have a spreadsheet that has quietly become a system. Our earlier post on when the spreadsheet is the system covers the risks. This one covers the decision and the move.
Excel vs database: the difference in plain English
A spreadsheet is a grid. Anything can go in any cell, and nothing stops two rows describing the same customer in slightly different ways. That freedom is why spreadsheets are so useful for working things out.
A database stores records with rules. Each customer exists once. A job must belong to a customer that exists. A date field only takes dates. When a job's status changes, the database can record who changed it and when.
In practice the differences that matter are:
- Many users at once. A database is built for several people adding and changing records at the same time without overwriting each other. A shared spreadsheet copes with this only up to a point.
- One copy. There's no "final v3" emailed around. Everyone works from the same records, which is what people mean by a single source of truth: one place everyone takes the number from.
- Rules on the data. Required fields, drop-down lists and links between records stop many errors from getting in.
- History. A database can keep a record of every change, so you can see who changed what.
- Permissions. Some people can view, some can edit, and some can't see pay rates at all.
- Connections. A database can pass records to and from your accounting software, job system or website without someone copying and pasting.
Spreadsheet risk: signs it's time to move
Spreadsheet risk isn't about spreadsheets being bad. It's about a spreadsheet doing a job it wasn't built for. These are the signs:
- Several people edit it, and you've had changes overwritten or lost.
- There are copies. People keep their own version because the shared one is slow or locked.
- It's the only record of something important: jobs, assets, licences, customer pricing, stock on hand.
- One person understands it. When they're away, nobody touches it.
- It feeds other systems by hand. Figures are copied from it into invoices, payroll or the accounts. That's double data entry, and every copy is a chance for an error.
- It's slow, because it now holds years of rows and lookups across several tabs.
- You can't answer simple questions like "which jobs changed status last week?" without someone spending an afternoon on it.
If two or three of these are true, it's worth planning the move. If none are, protect the spreadsheet (lock formulas, keep one master copy) and leave it alone.
What moving a spreadsheet into a database involves
Most of the work isn't the database. It's understanding what the spreadsheet has been doing.
- Map what it does. List every tab, who uses it, what they put in, what they take out, and where it goes next. Spreadsheets often hide rules in formulas and colour codes that nobody has written down.
- Decide what's a record and what's a report. Customers, jobs and items are records and belong in the database. Totals, pivots and charts are reports and can be rebuilt from the records.
- Clean the data. Merge duplicate customers, fix inconsistent codes, fill required fields and decide what to do with old rows. This is often the biggest single step. Clean master data (the core lists of customers, suppliers, items and jobs) makes everything after it easier.
- Build the database and the screens. Simple forms for entering and finding records, lists people can filter, and the reports they used to get from the spreadsheet.
- Connect it. If figures went from the spreadsheet into the accounting software or another system by hand, connect them so they go across once.
- Run in parallel, then switch. Use both for a short period, compare results, then lock the spreadsheet as read-only and keep it as an archive.
When it's done, it looks like this: the operations manager opens a screen, filters to this week's open jobs, and sees the same list the accounts team sees, with the latest status and who changed it. Nobody asks which file is current.
Options for replacing the spreadsheet
There's no single best answer. The right choice depends on what the spreadsheet does.
- A system you already own. Often the job, stock or CRM system you already pay for can hold these records, and the spreadsheet only exists because nobody set that part up.
- An off-the-shelf product. If the spreadsheet does something common (asset register, contract register, rostering), a product may already do it well.
- A low-code app on a database. Good for straightforward forms and lists with a modest number of users.
- A custom web app on a proper database. Best when the spreadsheet holds your own way of working, connects to several systems, or has rules that products don't handle. Our spreadsheet replacement service covers this.
What is the best replacement for Microsoft Access?
Access sits between a spreadsheet and a full database, and many businesses have Access databases that have run for years. Microsoft has ended support for Access 2021 (see our post on Access 2021 end of support), which has many businesses asking what to move to.
The usual answer is to move the data into a server database, such as SQL Server or PostgreSQL, and replace the Access forms with a web app people open in a browser. That keeps the parts that work (your tables and rules) and removes the parts that cause trouble (file sharing, corruption, one person who knows the macros). Our Access database replacement page explains how we do it.
Frequently asked questions
Can Excel be used as a database?
For a small list that one or two people maintain, yes. Once several people update it at once, or other systems depend on it, it starts to fail in ways that are hard to see, such as overwritten changes, duplicate records and broken lookups.
How do I convert an Excel spreadsheet to a database?
Map what the spreadsheet does, separate records from reports, clean the data, build the database with simple entry screens, then run both side by side before switching over. The cleaning and mapping usually take longer than the build.
Will we lose our historical data?
No, if it's planned properly. Historical rows are cleaned and loaded into the database, and the original spreadsheet is kept read-only as an archive.
Can we still use Excel after moving to a database?
Yes. Many teams keep Excel for analysis, connected to the database so it reads current figures rather than holding its own copy.
How long does moving a spreadsheet into a database take?
It depends on how many tabs, users and connections it has, and how clean the data is. We scope each one and give you a fixed quote after a free initial chat.
Next step
If one spreadsheet is holding up a whole process, our First Workflow Sprint is a good place to start: one workflow, moved off the spreadsheet and done properly. Not sure which spreadsheet costs you most? Try the free Admin Time Count. Or book a free initial chat and tell us about the file everyone is afraid to touch.