Excel-to-web migration with proof the numbers still match
Causal Labs migrates fragile, single-user Excel workbooks into fast, multi-user web applications — TypeScript, Vite, SheetJS, Vitest, IndexedDB — with tests proving the new system reproduces the spreadsheet's exact numbers. A prior migration was verified by 21 cell-for-cell golden tests proving exact parity with the original workbook.
Causal Labs migrates fragile, single-user Excel workbooks into fast, multi-user web applications — TypeScript, Vite, SheetJS, Vitest, IndexedDB — with tests proving the new system reproduces the spreadsheet's exact numbers. A prior migration was verified by 21 cell-for-cell golden tests proving exact parity with the original workbook.
Why 'just rebuild it as a web app' is the wrong first sentence
A business-critical spreadsheet usually encodes years of undocumented logic — edge-case handling, manual overrides, formulas nobody fully remembers the reasoning for. Rebuilding it as a web app without first proving parity means shipping a system that quietly produces different numbers than the spreadsheet it replaced, which is worse than not migrating at all.
The trigger to replace Excel with a web app is usually the same story: one workbook has become the system of record for something the whole team depends on, but only one person can safely edit it at a time, version conflicts overwrite each other's work, and 'which copy is the real one' is a recurring Slack question. A spreadsheet was never built for concurrent, multi-user access — a web application is.
Excel to web application development also means moving off a flat file and onto an online database — real query performance as the dataset grows, permissioned access instead of a shared file, and an audit trail of who changed what, none of which a `.xlsx` file sitting in a shared drive can give you.
This often runs alongside deployment and hosting for the new application.
How we approach an Excel-to-web migration
Requirements gathering
We reverse-engineer the spreadsheet's actual logic, including undocumented edge cases, before writing any web application code.
Scoping & proposal
We map which tabs and workflows become which application modules, define the multi-user permission model, and confirm whether offline access is a real requirement.
Design
The spreadsheet's implicit structure becomes a real database schema, with the workbook's views mapped to application screens rather than replicated cell-for-cell.
Build
A multi-user web application (TypeScript/Vite) that reproduces the spreadsheet's calculation logic exactly.
QA & review
Cell-for-cell golden tests compare the new system's output against the original spreadsheet across representative scenarios.
Handover & support
Your team gets the application, documentation of the logic that was extracted from the spreadsheet, and a support window for the first weeks of real multi-user use.
What's included
Logic reverse-engineering
Full extraction of the spreadsheet's calculation logic, including undocumented edge cases and manual overrides.
Cell-for-cell parity testing
Golden tests proving the new system reproduces the spreadsheet's exact numbers across real scenarios.
Multi-user access
Concurrent, permissioned access replacing the single-file, single-user spreadsheet bottleneck.
Structured online database
The workbook's data moves into a real, queryable database instead of a flat file — the foundation an Excel-to-online-database migration actually needs.
Offline-capable data layer
IndexedDB-backed local storage where the workflow needs to function without a constant connection.
Spreadsheet import/export
SheetJS-based compatibility so data can still move in and out of Excel format where a workflow genuinely needs it.
- Production web application
- Cell-for-cell golden test suite
- Logic documentation extracted from the spreadsheet
- Multi-user access controls
- Spreadsheet import/export compatibility
- Handover documentation and support window
Type-safe reimplementation of the spreadsheet's calculation logic.
Fast build tooling for the migrated application.
Used for spreadsheet import/export compatibility during and after migration.
Runs the cell-for-cell golden test suite that proves parity.
Local data persistence where offline capability is required.
Replaced an Excel workbook with a web app verified by 21 cell-for-cell golden tests proving exact parity.
cell-for-cell golden tests proving exact parity in a past migration
typical delivery window
Questions about this service
How do you prove the new system matches the old spreadsheet exactly?
Golden tests: the same input scenarios are run through both the original spreadsheet and the new application, and the outputs are compared cell-for-cell. The migration isn't considered complete until they match.
Do we lose the ability to use Excel entirely once we migrate?
No — SheetJS-based import/export means data can still move in and out of spreadsheet format where a workflow genuinely calls for it. The difference is the spreadsheet stops being the system of record.
How long does a typical Excel-to-web application migration take?
Most engagements run 4–8 weeks, depending on how much undocumented logic the spreadsheet contains and how many concurrent users the application needs to support from day one.
Our spreadsheet has grown organically for years with inconsistent logic — is that a problem?
It's the norm, not the exception, and it's exactly what the requirements-gathering stage exists to untangle. We reverse-engineer the logic as it actually behaves today, edge cases included, rather than as anyone remembers designing it.
Free tools
By industry
Still running critical logic through a spreadsheet only one person understands?
Tell us what the spreadsheet does and who relies on it. We'll scope a migration with proof, not just promises, of parity.
Start a conversation