GrayBeck
All insights

Architecture5 min read

Excel Isn’t the Problem. Your Architecture Is.

April 2026 · Jake McFadden


When Excel starts to break, the instinct is to replace it. That's usually a mistake.

Excel isn't the problem. Packing too much logic into it is. It works until the rules get hard to maintain and a few people become the only ones who understand how it works. At that point, buying SaaS feels safer than fixing the real issue.

But SaaS hides logic rather than clarifying it. The bad assumptions survive the migration and get locked into a more expensive box.

We keep meeting the same spreadsheet at institutional lenders, asset managers, and mid-market enterprises: it started as a quick tool and became the system of record. Formulas reference other formulas across tabs and workbooks. VBA macros automate steps that no one fully documents. The file gets emailed around, versioned by filename, and eventually becomes so fragile that no one wants to touch it.

The fix is to pull the complexity out of the workbook, not to throw the workbook away.

Keep Excel for what it's good at: analysis, ad-hoc modeling, and presentation. Move the business rules — the validation logic, the calculations that drive decisions, the reference data — into code, services, or controlled models that don't depend on manual edits.

The work usually lands in three stages.

Extraction comes first. Before you can move anything, you have to understand what the spreadsheet actually does, which means reading every formula, tracing every macro, and mapping every dependency. It is tedious. Skipping it is how modernization projects fail: you rebuild something that doesn't match what the business actually needs.

Then the data gets a real home. The reference data, lookup tables, and source inputs that feed the spreadsheet move into a governed database instead of hidden tabs and named ranges. A SQL backend with clear schemas, canonical keys, and validation rules is what makes every later step cheap.

And the interface stays familiar. The fastest way to kill a modernization project is to force a new workflow on a team that's been using Excel for a decade. The best implementations we've seen keep Excel as the front end — connected to the database backend via add-ins or APIs — so the team gets reliability without losing the interface they know.

The goal isn't to eliminate Excel. It's to make it safe to use again.

Have a similar challenge?

Book a call

Keep reading

All insights →