Most business owners think of their spreadsheet as "just a file." A container for numbers. Something Excel happens to open.
It isn't that. In a very real sense, it's unlicensed, undocumented software, running your business every single day, and almost nobody treats it with the seriousness that description deserves.
Here's a concrete example I ran into with a client in distribution. Buried in a pricing sheet was a formula that looked, at a glance, like a simple percentage discount. Look closer, and it had a nested condition: if the customer's region was one of three specific codes, and the order total crossed a threshold, and the order fell within the first ten days of the month, a different discount applied. Nobody currently at the company could tell me why the first-ten-days condition existed. Best guess, from someone who'd been there a while, was that it matched an old promotion tied to a supplier payment cycle that had ended years earlier, but the formula outlived the reason for it and kept quietly applying a real discount to real invoices anyway. That's not a quirky Excel trick. That's a business rule, still running, that nobody could fully explain and nobody had written down anywhere except inside that one cell.
Why this matters more than it sounds like it should
A spreadsheet formula is code. It takes inputs, applies logic, and produces an output that affects a real decision, in this case, how much a real customer gets charged. The fact that it's written in a formula bar instead of a programming language doesn't make it less real. It just makes it less visible, less reviewed, and far less documented than code anyone would call "code" out loud.
That gap between how real it is and how seriously it gets treated is exactly where things go wrong during a migration.
What happens when you skip this step
Here's the failure mode I see most often, and it's rarely dramatic in the moment. Someone decides to "just copy the spreadsheet into a database," meaning they look at the columns, map them to database fields, and move the data over. The columns move. The rows move. The totals, on the day of the move, look fine.
What doesn't move is the formula. A database field can hold a discount percentage, but it can't hold the conditional logic that decided which discount applied to which order under which circumstances, unless someone deliberately writes that logic into the new system. If nobody read the formula closely enough to notice the first-ten-days condition in the first place, nobody writes it into the new system either. The new system goes live, looks correct for weeks, and then a regional sales rep asks why a customer who always gets the special rate suddenly isn't getting it. By then, the person who could have explained the original formula may not even remember it exists, and reconstructing a rule from a help-desk ticket months later is a far more expensive and uncertain exercise than reading the formula once, up front, before anything changed.
What it actually looks like to extract these rules properly
The fix isn't complicated, but it does require actually doing it rather than assuming the columns speak for themselves. It means going formula by formula, pivot table by pivot table, macro by macro, and writing down, in plain language, what each one actually does and under what conditions. Not "applies a discount." Specifically: this discount, for these regions, above this total, within this window, and here's our best understanding of why, even when that "why" is a guess at a promotion that ended years ago.
This document, once it exists, becomes the actual specification for the new system. Not the spreadsheet's column headers. Not a verbal description from whoever remembers the system best. The rules, written down, checked against the formulas that currently enforce them, and confirmed with whoever in the business actually relies on the outcome.
It also surfaces the rules worth questioning rather than blindly carrying forward. Once that first-ten-days condition was written down in plain language and shown to the client, the answer wasn't "keep it exactly as is." It was "that promotion ended years ago, let's not carry a dead rule into a new system on purpose." That's a conversation you can only have once the rule is visible. You can't decide to retire a rule you never knew existed.
Why this single step is the difference
A migration that skips this and one that does it look identical on launch day. Both show the same totals, matched against last month's numbers, both demo cleanly to whoever's watching. The difference shows up later, in the edge case that only happens for a handful of orders a month, the one regional exception, the one customer whose invoice suddenly looks wrong for a reason nobody can immediately place.
That gap, between launch day and six weeks later when a quiet rule finally gets missed in a live transaction, is exactly what this step exists to close. It's slower up front, by design, and it's the reason the system that replaces the spreadsheet actually behaves like the business expects instead of like a close approximation of it.
Treat the spreadsheet like what it is
Your spreadsheet isn't just a file sitting between you and your data. It's the place your business rules have been quietly living, possibly for years, without a license, a changelog, or a single line of documentation anywhere else. Reading it that way, carefully and on purpose, before building anything new on top of it, is what keeps those rules alive instead of losing them the moment nobody's looking.