We have seen this story play out in too many organizations, and it points to a truth that is often avoided until it is too late: trust in the output is everything, and you cannot build it after the code is written. In both migrations described, one to Oracle, one to SAP, the technical work was not the real problem. The first team actually managed to code the logic into the new system. The second team found the mapping too complex and abandoned the effort. But in both cases, the root cause was the same: the spreadsheet itself was a black box. Hundreds of formulas, layers of dependencies, and no clear documentation of what the major flows were supposed to do. The business could not verify the results, so they refused to use the system.
What this means for you is straightforward. If you are planning to migrate a critical spreadsheet to an ERP, your single most important task is not hiring the best programmers or buying the most expensive consultancy. It is documenting the logic inside your spreadsheet before anyone writes a line of new code. That means mapping every formula, every dependency, every conditional branch, and every manual override that a user has baked in over years of use. It means testing those documented flows against real business outcomes, not just against the numbers the spreadsheet currently produces. Because the spreadsheet may itself contain errors or assumptions that have never been challenged. If you cannot explain to a colleague why a certain cell produces a certain value, you will never be able to explain it to an auditor, or to the business team that has to trust the new system.
The practical consequence is painful but simple. Without that documentation, you will either spend months in expensive rework when the business rejects the output, or you will cancel the project entirely because the scope becomes too uncertain to justify. The first company in the story delivered a working system that sat unused. The second company stopped after four weeks and wrote off the investment. Both outcomes are avoidable if you treat the spreadsheet as a source of truth that needs to be understood, not just translated. So before you hire the consultants or start the migration project, invest the time to open your spreadsheets, trace every dependency, and write down what each part is supposed to do. That documentation is the only way to earn the trust that makes a migration succeed.