Fine. Use Excel as a Database. Just Please, Do These Things.

Your entire business runs on a spreadsheet that Nathan built three years ago. Nathan left. Nobody knows how it works. But everyone knows that if it breaks during month end, the entire operation grinds to a halt.

Sound familiar?

I get it. You have a problem. You have Excel. You know how to use Excel. Why would you listen to the data guy ramble about something called "SQL" or "normalization"?

Here's the go: we can skip the lecture about what you "should" be using. But please, just take a few tips on how to make your Excel files more robust. You'll be happy because your spreadsheet lasts the test of time, and I'll be... less grumpy, I guess.

The situation we're trying to avoid

Let me walk you through the lifecycle of every operational spreadsheet ever created.

Month 1: Nathan builds spreadsheet to track operations and workflows. It's elegant. It's functional. It has exactly the right tabs. Nathan’s a real beauty.

Month 6: Nathan leaves. The spreadsheet stays behind and is left to James to maintain.

Month 12: The business grows. Management wants to see new types of information. The spreadsheet has evolved. It now features:

• 47 tabs (32 of which are labelled "temp" or "old" but nobody dares delete them)

• Formulas referencing other workbooks that lived on Mo's laptop (Mo left in August)

• Manual copy-paste steps that must be done in exactly the right order or everything breaks

• Three different definitions of "revenue" depending on which tab you're looking at

• That one cell in column AF that has the comment “For those that witness what I’ve done here, I’m so sorry.”

• A tab called "DO NOT USE" that turns out to be the only tab the invoicing process actually needs

• Three copies of the sheet made every day in case it crashes and the entire site loses the information it relies on

Month 18: Worst case scenario. Nathan's once-beautiful spreadsheet crashes during month end. Panic ensues.

This is not Nathan's fault. Nathan built a tool for a specific moment in time. The business grew past that moment, but the spreadsheet stayed frozen in it, being held together by increasingly desperate workarounds and tribal knowledge.

What databases actually do (that your spreadsheet doesn't)

Real databases enforce structure. They don't let you:

• Accidentally delete a column the entire business depends on

• Store text in a date field because "it makes sense this time"

• Have five different versions of the same data

• Change structure every time someone has a "better idea"

Databases also separate data (the raw numbers) from logic (how you calculate and present those numbers). In Excel, these live together, which means changing one breaks the other.

How to make Excel act more like a database

If you're going to keep using Excel (and you are), here's how to make it less fragile:

1. Use tables

Convert your data ranges to Excel Tables. This does three things:

• Gives your data a structured name you can reference in formulas (minimises #REF! errors)

• Auto-expands when you add rows (so formulas don't break)

• Makes it possible for data tools like Power BI to connect and extract data for automated reporting

2. Lock your structure

Once your table structure is right, protect it:

• Lock the header row so column names can't change

• Protect the sheet structure so tabs can't be accidentally deleted

• Use data validation to stop people spelling the same word 6 different ways

Think of this as the database structure. Once it's set, changing it should require deliberate effort, not an accidental keystroke.

3. Separate data from presentation

Stop building calculations directly into your data tables. Instead:

• Keep raw data in one tab

• Build calculations and summaries in separate tabs that reference the data

• If someone breaks a formula, they break the pretty visual in a report, not the underlying data

This is what databases do. The data stays clean. The logic sits on top.

4. No merged cells. Ever.

Look at me on this hill. I will die here if I must.

Merged cells are the Excel equivalent of building a house on a beautiful, sloped block and then wondering why everything slides downhill when it rains. They look pretty. They make your headers visually appealing. They also make your data completely unreadable to any system trying to extract it.

If you need the visual effect, look up "Center Across Selection". It's in the alignment tab (Ctrl + 1 or Cmd + 1). Your future self (or the poor data person trying to help you) will be grateful.

5. One data type per column

If your "Date" column contains actual dates, text that looks like dates, and occasionally "TBC", you have a problem. Pick one data type per column and stick to it. Use data validation to enforce this.

6. Name your workbook and structure deliberately

If your file is called Final_v3_ACTUAL_USE_THIS_NEW.xlsx sitting in a folder next to Final_v2.xlsx, Final_FINAL.xlsx, and Final_v3_OLD_DONT_USE.xlsx, you've lost control of the situation.

This is the spreadsheet version of having 47 tabs you're afraid to delete. Future you has no idea which file is actually current, and present you is just hoping the most recent one happens to be the right one.

Use clear, consistent naming:

• Workbook: OperationalData_2024.xlsx (revolutionary, I know)

• Tables: Jobs, Costs, Inventory (not Table1, Table2, Table47)

• Sheets: Logical grouping with clear purpose (not Sheet1, OLD, NEW, NEWEST, USE_THIS_ONE)

When someone (or some ETL process) needs to find your data in six months, they should know where to look without archaeological excavation.

7. Document your logic

Add a "README" sheet that explains:

• What each table contains

• Where data comes from

• What the key calculations mean (explain your metrics and write down the formula)

• Who to ask if something breaks

Future you (and anyone inheriting this) will thank you.

You've done it!

You've embedded 7 best practices into your Excel document that has made it even more beautiful than it was before. Better yet, when Nathan leaves, Mo and James can pick it up and use it without having to go through and re-invent the wheel every time.

Now for the reality check.

When Excel stops being enough

These fixes will get you surprisingly far. But there's a point where Excel becomes the bottleneck:

• When reporting takes days because you're manually rebuilding numbers

• When different teams have different versions of "the truth" (good practices will still break down to inter-team differences in naming conventions etc.)

• When you can't trace where a number actually came from

• When the business has outgrown the structure but you're afraid to change it

That's when the underlying data needs proper clean up, and the reporting needs to be rebuilt on stable foundations.

The reality

Excel isn't evil. It's a brilliant tool that's being asked to do a job it wasn't designed for, like using a Swiss Army knife to build a house. Sure, it has a saw, but at some point you should probably buy an impact driver... and some other tools.

Most operational businesses run on Excel because it's flexible, familiar, and frankly, it works. Until it doesn't. Usually at 4pm on month end when the GM is asking for the numbers and the spreadsheet is showing #REF! errors across half the page.

The goal isn't to eliminate Excel tomorrow. It's to make sure your Excel-based systems are structured enough that:

• They don't randomly explode when someone adds a row

• Someone can understand them six months from now (including you)

• When you're ready to build something more robust, the data underneath is in good enough shape to actually use (instead of spending three months cleaning it first)

If your current Excel setup is starting to feel fragile, brittle, or like it's held together with hope and increasingly desperate workarounds, that's normal. That's what happens when businesses grow. The spreadsheet that worked perfectly at $10M revenue starts sweating at $50M and actively breaks at $100M.

Get in touch

We help operational businesses fix the data foundations underneath their reporting without demanding they rip out their entire tech stack. If you want someone to look at your current setup and tell you what's actually fixable (and what's not), we can do that.

No vendor sales pitches. No demands that you buy new software. Just practical fixes for the systems you're actually using.