There is a spreadsheet somewhere in your organization that nobody created on purpose.

Nobody sat down and decided to build the operational backbone of a department as a Microsoft Sharepoint List. It just grew. Someone made a tracking sheet. Someone else added a column. A manager asked for a summary tab. A new person joined and needed to understand "the system," so they were walked through the file instead of trained on a process. Eventually the spreadsheet stopped being a spreadsheet. It became the source of truth for product data, pricing, inventory, workflows, or all of the above.

We called ours the Master Sheet.

The Master Sheet was 4200+ rows and 104 columns of product data. It had been added to, reformatted, and patched over 5 years. It had data that referenced other data that referenced named ranges that nobody could trace back to their origin. It had a tab called "OLD DO NOT DELETE" and another called "OLD 2 DO NOT DELETE" and a third that was just "backup_FINAL."

The person who built it had long since moved on to another company shortly after. Their replacement had learned the sheet by sitting next to the original builder for a week. That person had since trained two more people the same way, each time losing a little institutional knowledge, like a photocopy of a photocopy — and one of those people was me.

This is not unusual. This is how most Master Sheets come to exist. Not through negligence — through resourcefulness. Someone needed a solution and first it was Excel and then it was a Sharepoint List. The sheet worked. It kept working and when it didn't work we tapped our machines and said some choice words and it went back to working. And then one day it was load-bearing.

A spreadsheet becomes load-bearing the moment you cannot operate without it.

The Master Sheet had crossed that line quietly. Product launches depended on data being formatted correctly inside it. Downstream systems read from exports that came out of it. Pricing for 15 markets was calculated inside its columns — columns that only one person fully understood. The sheet was not documentation of a process. The sheet was the process.

When the person who maintained it (me, for 4 years) was out sick, things slowed down. When they left for a two-week vacation, someone else had to be trained on which tabs to touch and which tabs not to touch under any circumstances. When we needed to migrate to a proper Product Information Management system, the first question we asked was: "Can we just export everything from the Master Sheet?"

The answer was yes, technically. The quality of what came out was a different conversation.

Before I get to what we did about it, here is the diagnostic I wish someone had handed me earlier.

Question one: If the person who maintains this took a month off tomorrow, what happens on day three?

Not what your backup plan is — what actually happens. In most organizations with a true Master Sheet, the honest answer is "we figure out who the second-most-knowledgeable person is and put them in a difficult position." That is not a system. That is a dependency.

Question two: Could a new hire be productive here in their first week, or does it take "sitting with someone" first?

If the only way to learn the file is to have someone walk you through it in person, then the knowledge lives in a person, not a process. The spreadsheet is the artifact. The person is the actual system.

Question three: What happens if you reformat a cell, rename a tab, or drop a row in the wrong place?

If the honest answer involves words like "cascade" or "break" or "we've actually lost data that way before" — you have found your Master Sheet.

If you got an uneasy laugh at two or more of those, you know what you're dealing with.

We replaced the Master Sheet with a Product Information Management platform called Pimberly. I am going to be direct about what that project was: it was not glamorous. It was months of data cleanup, field mapping, lifecycle configuration, and conversations about whether a particular attribute belonged in a schema or a channel. It was the kind of work that is genuinely hard to explain to someone who has never done it, because the details are so specific to the data that they sound trivial until they are blocking your go-live.

The go-live, by the way, was almost blocked by a pricing rounding rule.

We had 15 markets with VAT-inclusive pricing. The peg rate multipliers that calculated those prices had a rounding behavior in the old sheet — a behavior nobody had formally documented, because nobody had needed to. It was just how the sheet worked. When we moved the pricing logic into Pimberly, we had to decide: was this a front-end fix, or did we need a lookup table? The answer required a meeting between our finance team, our Pimberly implementation contact, and me, sitting in front of a screen comparing outputs cell by cell.

We caught it before launch. That is the only reason I can describe it here as an anecdote rather than a post-mortem.

That rounding rule — that one invisible behavior baked into a formula nobody had touched in three years — is what I mean when I say the boring details are the ones that matter. Not the platform choice. Not the vendor pitch. The cell. The formula. The assumption nobody wrote down.

Three things are worth carrying forward.

First: the spreadsheet was never the problem. The Master Sheet was a reasonable response to a real need. Someone needed to track product data. Excel was available. The problem was that the solution never graduated. It stayed in spreadsheet form long after the data it managed had grown past what a spreadsheet should reasonably hold. The lesson is not "stop using spreadsheets." The lesson is that every spreadsheet solution has a natural ceiling, and most organizations do not notice they've hit it until they are staring at [X] tabs and a file that crashes on open.

Second: the migration cost more than the platform. We paid for a new system. The real cost was the hours spent auditing data that had been entered inconsistently over years, mapping fields that had no equivalent in the new structure, and chasing down the owners of business rules that existed only in someone's memory. If you are evaluating a PIM, a CRM, or any system meant to replace a spreadsheet, budget for the archaeology. The data does not migrate itself, and the process of migrating it will surface assumptions you did not know your organization was making.

Third: the people who built the spreadsheet knew what they were doing. I want to be clear about this. The Master Sheet was not a failure of competence. It was a product of real capability operating under real constraints. The people who built and maintained it were resourceful, knowledgeable, and in many cases the only reason the organization could function. The migration was not a correction. It was a handoff. The goal was to move the knowledge out of the file and into a system that could hold it reliably.

That distinction matters for how you run the project. If the people who own the spreadsheet feel like the migration is a judgment on their work, you will lose them. If they understand that their knowledge is the asset and the spreadsheet is just the current container for it, they become the most valuable people in the room.

I have seen versions of this story in every organization I have worked in or with. The format changes — sometimes it is a spreadsheet, sometimes it is a shared inbox, sometimes it is a Slack channel that has become the de facto project management system — but the underlying dynamic is the same. A tool was used to solve a problem. The tool worked. The tool was never replaced. Eventually the tool became infrastructure.

The difference between organizations that handle this well and organizations that do not is not which tools they use. It is whether anyone is watching for the moment a solution becomes a liability. Whether someone is asking, periodically, "is this still the right container for what we are storing here?"

That is the boring detail. Not the migration. The watching.

If you want to audit the spreadsheet you are thinking about right now, the three questions above are the place to start. The 3-Question Diagnostic puts them into a one-page format you can work through in about ten minutes — it will tell you whether you have a Master Sheet problem and how serious it is. If you already know you have one and need a map for what comes next, Find Your Master Sheet is where I'd start.

Get the free diagnostic →

Find Your Master Sheet — $27 →

The Boring Detail covers the operational details that decide whether work ships — the approvals, the data, the one rounding rule nobody documented. Subscribe free below.

Subscribe →