The most important application in most large organizations is not the ERP. It is the workbook that sits on a shared drive, opened every morning by three people, that decides what the ERP is told. Someone built it years ago, probably in an afternoon, probably to work around a system that could not do the one thing the business actually needed. It grew. It acquired macros, then a second sheet of lookup tables nobody dares sort, then a VBA module that writes a file the finance team collects at month end. Nobody signed it off, nobody owns it, and nobody can turn it off. That is spreadsheet sprawl, and calling it a productivity problem understates it badly. It is an unofficial ERP, running critical processes with no access control, no audit trail, no test environment, and no documentation beyond whatever the original author still remembers.
The case here is narrow and specific: spreadsheet-based processes should be migrated with the same discipline applied to a COBOL or Oracle Forms estate, because they carry the same risk profile and, in most organizations, a worse one. Oracle Forms at least has a published end-of-support date. The mainframe at least has a vendor contract behind it. The workbook on the shared drive has neither, and nobody is accountable for either.
The workbook that became a system
What makes a spreadsheet dangerous is not complexity. It is the point at which other people start depending on its output without understanding its logic. A pricing model becomes the pricing system. A capacity tracker becomes the scheduling system. An inventory reconciliation becomes the thing procurement trusts over the actual stock record. The transition happens without a decision being made, which is precisely why it never triggers a governance review.
By the time someone notices, the workbook has three properties that make it hard to remove. It encodes business rules that exist nowhere else, often rules that were never formally agreed but have been operating as policy for years. It has an interface people are fast at, because a spreadsheet grid is genuinely a good interface for dense data entry and everyone already knows it. And it produces output that a dozen downstream processes are shaped around, including manual ones, including a person who copies a column into an email every Friday.
The governance failure is easy to describe and hard to fix. There is no reliable record of who changed a formula and when. There is no separation between the person who writes the logic and the person who runs it. There is no rollback. Macros execute with the full permissions of whoever opens the file, which means an attachment-borne macro and your month-end close process are, from the operating system’s point of view, the same category of thing. Microsoft’s own response to that has been to block macros in files from the internet by default, which tells you how the risk is regarded by the vendor. Since 2022, Office blocks VBA macros in files downloaded from the internet unless an administrator explicitly allows them, a change Microsoft made specifically because macro-laden Office documents had become a common way for attackers to deliver malware (Microsoft Learn, “Macros from the internet are blocked by default in Office”).
And then there is error rate. The uncomfortable part of spreadsheet error rates is not that workbooks contain mistakes but that the people who build them are confident they do not. The research on this is old, consistent, and rarely read by the people it is actually about. Ray Panko’s long-running review of studies on operational spreadsheets, compiled through the European Spreadsheet Risks Interest Group, puts the share of real-world spreadsheets containing at least one error above 90% (EuSpRIG, “Research and Best Practice”). The individual studies disagree on the per-cell error rate, estimates range from under 1% to over 5% depending on methodology, but they agree on the number that matters more: in a spreadsheet with enough cells and enough dependent formulas, at least one wrong bottom-line figure is close to certain.
Japan’s particular version of this problem
Japan deserves separate treatment here, because the dependency runs deeper and has a longer history. Excel in Japanese enterprises is not only a calculation tool. It is a document format, a form designer, a reporting layer, and, through decades of accumulated macro development, an application platform. The practice of building layouts cell by cell for printed forms is common enough to have its own name: Excel方眼紙 (Excel houganshi, literally “Excel graph paper”), squaring off every cell into a uniform grid so the sheet functions as a layout canvas rather than a data table, sometimes distinguished from the more derisive slang term 神Excel (“god Excel”) reserved for the worst offenders (Japanese Wikipedia, “Excel方眼紙”). Whole departments run on workbooks that were written in the nineties, maintained by a succession of staff, and are now understood by nobody currently employed.
Structurally, this is the COBOL problem again, demographic clock included. The difference is visibility. COBOL skills at least came with a job title, which is how anyone was able to count them. The VBA equivalent never did. The knowledge sits with a small number of people, often not developers at all, who built these workbooks alongside their actual jobs, are now close to retirement, and have never been asked to write any of it down.
Migrating logic without losing the knowledge inside it
The standard failure mode of spreadsheet modernization is that someone writes a requirements document, a development team builds a clean new application against it, and the business quietly keeps using the workbook because the new system does not handle the seventeen exceptions that were never in the document. The exceptions are the system. A formula with a nested condition for one customer, a manual override column with a comment explaining why, a macro that skips a validation step at quarter end. Every one of those is an institutional decision, and none of them will be recalled in a workshop.
This is why the source artifact matters more than the interview. GalaxyONE, Sovablu’s AI engine, accepts legacy source code as a migration input, and that includes Access and VBA alongside COBOL, RPG, AS/400, Visual Basic, Oracle Forms, and Lotus Notes. The point of reading the code rather than the requirements is that the code is the only honest record of what the process actually does. Four Copilots handle the split, Solution, Data, Logic, and Layout, and what they produce is not a generated application you accept or reject wholesale. It lands as editable objects inside three visual designers, UI, Data, and Logic, which means the business analyst who understands why that override column exists can open the migrated rule and correct it directly. Nothing is compiled away into code nobody can inspect. That distinction is the whole reason no-code is the right shape for this problem and generated-code tooling is not: the people with the institutional knowledge have to be able to read the result.
The governance gain arrives as a side effect of the platform rather than as a separate project. Role-based access instead of file permissions. A logged change history instead of a filename ending in _v4_final_FINAL. A data model instead of a lookup range. Running on AWS serverless infrastructure, priced on usage and consumption rather than per seat or per application, which matters when you are migrating two hundred workflows rather than one flagship system and cannot justify a license for every small thing.
Parallel run is not optional
The only migration validation method that holds up for this category is a parallel run. Both systems live, the same inputs, every day, for a full business cycle, with the outputs compared field by field and every divergence investigated until it is explained.
It will feel like wasted effort for the first week and then it will start earning its keep. The divergences fall into three kinds. The migration got something wrong, which you fix. The spreadsheet was wrong, which happens more often than anyone expects and is usually the moment the project justifies itself. Or the two are both defensible and the business has to make a decision it has been avoiding for years, typically about rounding, cutoff dates, or which version of a customer record counts. A full cycle matters because the exceptions cluster at month end and quarter end. A two-week parallel run that ends on the fifteenth validates nothing.
Set the exit criteria before you start. Zero unexplained divergences over a complete cycle, not a tolerance band, because a tolerance band is how you ship a rounding error into a financial report. When you hit it, decommission the workbook properly: revoke access, archive the file read-only, and remove the shortcut from every desktop. A spreadsheet left running alongside its replacement will be used, and then you have two systems of record and no system of truth.
Start with the ones that scare you
The instinct is to migrate the simplest workbook first, prove the approach, and build confidence. Resist it. The simple ones are simple because nobody depends on them, which means success there proves nothing and exposes the program to the accusation that it only works on toys. Pick the workbook that the finance controller would not go on vacation without, the one with the macro nobody has modified since the author left, the one where the honest answer to “what happens if this file corrupts” is a long silence. Migrate that one, parallel run it through a full close, and you will have both a governed replacement for your highest-risk process and an argument that the rest of the estate cannot be dismissed as spreadsheets.
