The spreadsheet your team built is the best spec you have

The file nobody admits to

Almost every operation we walk into has one. A spreadsheet, sometimes several, sitting beside the real system, holding the information the real system could not accommodate. Gate codes. Which crews can handle which buildings. Which client hates being called before ten. The exceptions that make the business work.

Nobody is proud of it. It usually gets introduced apologetically, as the thing they know they should have moved into the platform by now. That apology is the reason it gets discarded during projects, and discarding it is how you end up rebuilding it.

Because the spreadsheet is not a workaround. It is a specification, written in the only language available to the person who wrote it, refined against reality every single day for years.

What a mature spreadsheet actually encodes

Look at the columns. Each one exists because somebody needed that information often enough to make a place for it. Nobody adds a column speculatively; they add it after the third time they had to go and find that fact.

Look at the conditional formatting and the ad hoc colour coding. Those are business rules. Red means something specific to the person maintaining it, and that meaning is a rule your new system will need to encode or consciously discard.

Look at what is missing too. A field the platform offers that nobody bothered to duplicate is a field that does not matter to the actual work, whatever the vendor documentation says.

Why projects throw it away anyway

Partly embarrassment. The spreadsheet feels like evidence of disorganisation, so it gets minimised in requirements conversations rather than examined.

Partly because it is unglamorous. Reading someone else spreadsheet carefully is tedious work that produces no visible progress, and it competes with the much more satisfying activity of designing something new.

And partly because requirements gathering usually happens with managers rather than with the person maintaining the file. Managers describe the process as designed. The spreadsheet describes it as it runs.

How to read one properly

Sit with the person who owns it and go column by column. Ask why each one exists and what happens when it is wrong. You will get a story for most of them, and the story is the requirement.

Pay attention to anything maintained manually that could have been a formula. That is usually a place where the rule is too subtle to express mechanically, which means it needs a human decision point in whatever you build.

Check the edit history if you can. Columns added recently are live problems. Columns nobody has touched in a year are candidates for deletion, and deleting a requirement is worth as much as discovering one.

Migrate the logic, not just the data

Most migrations move the rows and lose the reasoning. The new system holds the same information and none of the rules, so within a quarter someone opens a fresh spreadsheet beside it and the cycle restarts.

The test of a successful replacement is not whether the data arrived. It is whether the shadow file stayed closed. If it reopens, you did not replace the spreadsheet, you added a system next to it.