Published Sep 14, 2026
When spreadsheets become an operating system
Find the business inside the files
Spreadsheets often begin as a practical answer and grow into a connected system. Formulas, tabs and manual steps can carry rules that are not written down anywhere else.
Follow a real example
Trace a customer, order or report through the files and people involved. Identify repeated entry, version conflicts and decisions that depend on someone knowing the workaround.
Separate the rule from its current format
Do not assume every sheet should become a screen. Work out what the information means, which record owns it and what should happen when it changes.
Plan the transition
Define cleanup, mapping, import and reconciliation. Test representative records and important exceptions. Agree when the new system becomes the source of truth and how the team will learn the workflow.
Use a relevant example
Our published ZMatic case describes replacing an interconnected spreadsheet setup with a custom ERP. The interesting part is the translation of rules and dependencies into a database and usable operational flows.
Start with a useful scope
A focused workflow can provide a sensible first boundary if it can operate clearly alongside the remaining tools. Include migration, permissions and support in that boundary.
Find the rules inside the workbook
Start by following the work that the spreadsheet supports. Identify who enters information, which formulas or lookups affect a decision and where a result is copied into another tool. Include hidden columns, manual corrections and the files people use alongside the main workbook.
Keep a copy of the original material and choose representative examples. A formula may encode an important exception, while a manual override may reflect a rule that has never been documented. Confirm the intended behavior with the people who perform the work.
Turn exceptions into explicit behavior
Consider an illustrative order workflow: an order is approved, one item becomes unavailable, and the customer agrees to a partial delivery. The replacement system needs a defined response for the order status, the remaining quantity, related documents and the information sent to finance.
Writing down these cases helps distinguish a simple data table from an operational application. Define the relevant roles and permissions, and agree which changes need a record of who made them and why.
Move the data with a reconciliation plan
Decide which records will move and how their identifiers map to the new system. List incomplete or conflicting entries and assign responsibility for resolving them. Keep unresolved exceptions visible rather than silently filling gaps with guessed values.
Rehearse the migration and compare business totals and relationships as well as record counts. Test a selection of complete scenarios using the imported data. Agree the checks, the release sequence and the conditions for returning to the previous setup if needed.
Plan the first period of use
The people doing the work need clear guidance on which system to use, how to report a problem and where to find support. If both systems remain active temporarily, specify which one owns each record and how differences will be handled.
Our work with ZMatic illustrates a move from interconnected spreadsheets to a custom ERP. The useful starting point for a similar project is understanding the rules and handoffs before designing their replacement.
