Choose the workflow that needs a system
A spreadsheet can be a good place to explore a question, build a model or manage a small, stable process. Replacement becomes worth investigating when people must repeatedly reconstruct who owns a task, which version is authoritative or whether an exception was approved. File size alone does not settle that decision.
Choose one complete workflow, such as receiving, approving and assigning a service request. State the problem in observable terms: requests lack an owner, approvals are hard to trace, or staff re-enter the same information. Compare a better-configured existing tool, an integration and a custom application against that problem. A new system can take responsibility for live work while spreadsheets remain useful for analysis.
Read the workbook with the people who use it
Ask an operator to walk through a normal case and a recent exception. Inspect formulas, lookup sheets, hidden tabs, filters, macros and external links. Then ask what happens outside the file. A colored cell may mean “call the manager”; a blank may mean “not checked”, rather than zero; a pasted value may be an approved override. Those meanings need an owner who can explain and confirm them.
Keep a short rule register. For each rule, record the trigger, the action or calculation, exceptions, the person allowed to override it and one example with an expected result. Mark it as keep, change or retire. Do not reproduce an obsolete workaround merely because it appears in a formula.
Importing the data is a separate task. Microsoft documents, for example, that importing an Excel workbook into Access transfers calculated values, not the underlying formulas. That is a specific importer’s behavior, but it illustrates the question to ask any supplier: which logic will be rebuilt, which will remain in the workbook and how will equivalence be demonstrated?
A small rule register makes hidden work visible
| What you find | What to clarify | What to specify |
|---|---|---|
| A formula calculates a due date | Does it count calendar or working days? What pauses the clock? | Calendar, timezone, pause conditions and expected dates. |
| A row changes color | Is the color a warning, a status or evidence of approval? | An explicit status and the action permitted in that status. |
| Someone overwrites a result | Who may do that, and when? | Permission, reason, original value and a recorded change. |
| A lookup joins two sheets | What identifies the same customer or request? | Stable identifiers and a review path for unmatched records. |
Turn the rules into examples the team can test
For example, imagine a service team whose workbook sends a request to a manager when its estimated effort exceeds eight hours. Requests with no estimate must wait for clarification. This is a hypothetical rule, not a recommended approval threshold.
Agree the outcomes before implementation. A six-hour request may enter the assignment queue. An eight-hour request also enters it because the rule says “exceeds”. A nine-hour request waits for approval. A request with no estimate stays out of the assignment queue, with a visible reason and a named person responsible for obtaining the estimate. If an approved request changes from nine to twelve hours, decide whether approval expires; do not leave that decision to whoever writes the code.
Test the actions as well as the displayed result. Can an unauthorized person approve a request? Can the team find who changed the estimate? Does retrying a submission create a second request? Define the expected behavior, then run the examples through the proposed system with the people who will operate it. GOV.UK’s guidance describes acceptance criteria as outcomes that demonstrate a user need has been met. Your rule register supplies the specific cases.
Check what the records mean, then reconcile the import
Decide what one row represents before mapping columns. One customer with three requests is different from three customers. Keep stable identifiers, define required fields and distinguish zero, unknown and not applicable. Treat identifiers with leading zeros as identifiers. Confirm date interpretation, timezones and currency units. For Hebrew and English records, check names, punctuation and mixed-language references in the interface people will actually use.
Run a trial import from an agreed snapshot. Compare counts by status, important totals and selected records, including missing values, duplicates and linked records. Explain every mismatch that affects the work. Matching a grand total is not enough: two mistakes can cancel each other out. Keep the source snapshot and the mapping decisions so the team can investigate differences.
Agree how much history the new workflow needs. Active work may move first while older records remain in a controlled, searchable archive. Specify who can access that archive and how users find the history behind an active record. This is a scope decision, not permission to discard business records.
Make the handover a decision with an owner
During a trial, compare the new system with the agreed source without letting both independently send customer messages, assign work or create orders. Choose one authoritative place for each live action. If people must enter information in both places temporarily, define how conflicts are found and who resolves them.
Before launch, rehearse the switch: pause changes for the selected workflow if needed, take a final snapshot, transfer the remaining changes, reconcile the records and confirm that staff can complete their tasks. Name the person who decides whether to proceed. Set the conditions for stopping, the support owner and the recovery procedure.
Recovery needs special attention after the new system has accepted work. Reopening yesterday’s workbook could omit requests or updates created since the switch. AWS’s cloud migration guidance distinguishes rollback before and after new data arrives. Apply that distinction here: identify how new records and changes will be recovered and reconciled before the old process resumes. A backup alone does not answer that question.
Leave the first planning session with a handover sheet
A useful first deliverable is a shared description of one working process. It should be specific enough for an operator to correct and an engineer to test. Capture:
- The workflow boundary, its owner and the problem the change should solve.
- The rules to keep, change or retire, with approved examples and unresolved questions.
- The record identifiers, field meanings, history scope and reconciliation checks.
- The source of truth for live work during the trial and after the switch.
- The launch decision, support responsibility and recovery of new work if the switch fails.
Sources and further reading
Map the workflow before replacing the workbook.
Tell us which process depends on spreadsheets, who runs it and which exceptions are hardest to manage. We can discuss the scope of a system around that work.
Discuss your operational system
