Why not just use Excel?

It's a fair question. Honestly, it's the right question. If you manage fund data for 50 share classes across 3 asset managers, Excel is probably the correct answer. The problems start when you're at 500 share classes across 30 managers, and the answer is still Excel.

I'm not here to bash Excel. Excel is genuinely brilliant software. It's the most successful end-user programming environment ever built. A competent operations analyst with Excel can build data pipelines, validation rules, reconciliation reports, and distribution files in an afternoon. No deployment. No infrastructure. No sprint planning.

The problem isn't Excel. The problem is what happens to Excel at scale.

The master sheet

Every fund data team has one. It starts as a simple tracker: ISINs, fund names, NAVs, maybe some AUM figures. Columns A through M. Clean. Manageable. Someone adds a VLOOKUP to pull in currency codes. Someone else adds conditional formatting to flag stale NAVs. A third person adds a macro that generates the monthly client report.

Six months later it's Fund_Master_v47_FINAL_JM_UPDATED_Mar2026.xlsx. It has 14 tabs, 200 columns, nested VLOOKUPs referencing three other workbooks, and a macro that takes 4 minutes to run. One person understands how it works. They're on holiday.

This isn't a hypothetical. I've seen it at firms managing billions in assets. The entire data operation running through a spreadsheet that crashes if you sort column F.

The five tipping points

Excel starts to hurt at very specific moments:

• Multiple people need to edit simultaneously. SharePoint co-authoring helps, but it doesn't solve merge conflicts in formulas. When two people edit the same VLOOKUP range, someone's work disappears.
• You need an audit trail. Who changed the NAV for IE00B4L5Y983 last Tuesday? In Excel, the answer is "we don't know." In a regulated environment, that's not acceptable.
• Data arrives faster than humans can paste it. If you're receiving daily NAV files from 20 sources, manually copying values into the master sheet takes half the morning. By the time you're done, the first file has already been superseded.
• Downstream consumers need structured output. When a distributor asks for data in EMT format, or a platform requires Openfunds XML, you can't just email them a spreadsheet. The transformation step becomes its own project.
• Errors compound silently. A misplaced decimal in cell G147 propagates through 30 formulas before anyone notices. Excel doesn't have validation rules. It has the honour system.

The migration nobody wants to do

Here's the uncomfortable truth: migrating away from Excel is painful. Not because the technology is hard, but because the spreadsheet contains years of institutional knowledge encoded in formulas, comments, and colour coding that nobody documented.

That yellow-highlighted row? It means the fund is soft-closed but we still report on it for one client. That formula in column R? It handles a special case for a Luxembourg fund that reports NAV in two currencies. Good luck finding that in a requirements document.

This is why "rip and replace" migrations fail. You can't extract the rules from the spreadsheet because half of them exist only in someone's head, expressed as "oh, I always check that one manually."

The pragmatic path

What actually works is running both systems in parallel. Keep the spreadsheet. But start feeding it from an automated source. Instead of pasting NAVs manually, have them flow into a database, then generate the spreadsheet from the database.

This sounds circular, but it's not. The spreadsheet becomes a view, not the source of truth. When something looks wrong, the analyst can still check it in their familiar environment. But the data is versioned, audited, and validated before it ever reaches the spreadsheet.

Over time, the spreadsheet gets thinner. The reconciliation formulas move into the platform. The conditional formatting becomes validation rules. The macro becomes an API call. The master sheet doesn't die — it retires gracefully.

When to stay in Excel

Seriously. If you have fewer than 100 share classes, a single data analyst, and no regulatory reporting requirements beyond basic factsheets, Excel is fine. It's more than fine. It's optimal. The overhead of a proper data platform isn't justified.

The moment to move is when you catch yourself building workarounds for problems that don't exist in a database. When you're writing VBA to do what a SQL query does in one line. When Fund_Master_v47 becomes Fund_Master_v48 and you can't remember what changed.

That's the tipping point. You'll know it when you're there. You probably already do.