This is a transparent worked scenario, not a reported customer success story. “Northstar Services” is fictional, and its volumes and events are teaching assumptions. The scenario shows how a 60-person service company could replace interdependent spreadsheets with a shared workflow while preserving local knowledge, reconciling data and retaining a workable rollback.
The central lesson is that files are not the real migration unit. Ownership, definitions, exceptions and controls are. Moving rows into a database without resolving those elements creates a cleaner interface over the same disagreement.
The target system becomes trustworthy only after workflow ownership and reconciliation rules move with the data.
The starting point: four files, three definitions of “complete”
Northstar coordinates recurring customer work across sales, operations and finance. Sales maintains customer commitments in one workbook. Operations copies accepted work into a scheduling file. Finance keeps a third list for invoicing. Approval changes arrive through email and chat.
The spreadsheets are not inherently the problem. Each one is a reasonable response to a local need. The problem is that the organisation has no authoritative record for status, owner or exception. A sales manager calls a job complete when the customer agrees the scope. Operations uses complete when delivery is confirmed. Finance uses complete only after all billable items are reconciled. Weekly reporting merges three meanings into one column.
The team initially proposes buying a system and importing all rows. The programme owner pauses that plan. If the target merely reproduces the columns, it will preserve the conflict and add new configuration around it.
Control 1: inventory the workflow estate, not just the files
The team creates an inventory with one row for every workbook, shared folder, form, macro, email rule and recurring manual report. It records the owner, users, purpose, update frequency, inputs, outputs, sensitive data, formulas, dependencies and what breaks if the artifact is unavailable.
Three findings change the migration scope:
- an operations macro silently creates the weekly capacity view;
- finance uses a hidden lookup table to normalise customer names;
- two coordinators keep personal copies because the shared file is locked during peak planning.
Those are not minor technical details. They explain why totals differ and which capabilities the shared system must replace. The inventory also identifies stale sheets that need not move. Where personal data is involved, the team asks whether every field is still needed for the stated purpose; the ICO's data-minimisation guidance describes the principle as keeping data adequate, relevant and limited to what is necessary.
Decision: migrate active customer and open-work records plus the history needed for service and financial obligations. Archive other retained records under an agreed policy rather than loading every historical column into the new workflow.
Control 2: reconstruct the process from events and exceptions
Instead of asking stakeholders what the future screen should contain, the analyst traces ten recent jobs from initial commitment to invoice. For each event, the team records who changed what, why, which information was available and how an exception was resolved.
The normal flow contains seven states, but four exceptions drive most rework: scope changes after scheduling, work split across dates, customer-requested holds and disputed billable items. The target workflow therefore needs explicit exception states and ownership, not one generic notes field.
The state definition becomes a controlled artifact:
| State | Entry condition | Owner | Exit evidence |
|---|---|---|---|
| Accepted | Scope and commercial terms approved | Sales | Accepted proposal reference |
| Ready to schedule | Required customer inputs received | Coordinator | Readiness checklist complete |
| Scheduled | Capacity and date assigned | Operations | Named resource and date |
| Delivered | Operational completion recorded | Delivery lead | Delivery evidence |
| Ready to invoice | Billable items reconciled | Finance | Control total passed |
The disputed and held paths are documented separately. “Complete” is removed because it collapses several accountable events.
Control 3: design ownership before configuration
The team assigns one role to own each state transition and one role to resolve each exception. Permission design follows those responsibilities. Sales may propose a scope change, but operations accepts its scheduling impact and finance accepts its billing effect. The system records those decisions rather than allowing any editor to overwrite a shared status.
Reports are redesigned at the same time. Every metric receives a definition, source state, owner and refresh rule. “Open work” now means records accepted but not yet delivered; “unbilled delivered work” means delivered records that have not passed the invoice-readiness control. The definitions are visible beside the dashboard rather than living in one analyst's formula.
The programme chooses a phased changeover. The GOV.UK guidance on moving away from legacy systems recommends understanding dependencies and constraints before planning the changeover and using manageable techniques to reduce dependency progressively. Northstar starts with new accepted work while older active jobs remain controlled in the existing files until their treatment is proven.
Control 4: rehearse migration and reconcile meaning
The first migration rehearsal uses a copy of representative data. Nothing is loaded merely because a column maps technically. Each source field is classified as direct, transformed, derived, archived or rejected. Every transformation has an owner and test.
The team defines control totals before running the import:
- record counts by active state;
- sum of unbilled value by customer and currency;
- count of jobs with future scheduled dates;
- count of unresolved holds and disputes;
- sample-level checks of attachments, owners and history.
The rehearsal reveals 47 customer-name variants and 19 records with dates stored as text. These are not “cleaned” through undocumented manual edits. The team records the resolution rule, applies it reproducibly and preserves the source-to-target reconciliation.
A migration exception register holds the source identifier, problem, treatment, owner and approval. The cutover gate requires totals to match within explicitly approved tolerances and every material exception to be resolved or accepted.
Control 5: use parallel operation as a controlled comparison
Running two systems indefinitely creates double entry and ambiguity. Northstar limits parallel operation to two weekly cycles and specifies which record is authoritative during each stage. New jobs enter the shared system. The legacy workbooks remain read-only references except for a named coordinator who records required comparison data.
The team compares operational outputs, not screen appearance:
- are all accepted jobs represented once?
- do scheduled dates and owners match approved commitments?
- are holds and disputes visible to the right roles?
- does the invoice-ready total reconcile?
- can a user trace a dashboard number to its records?
One failure matters more than the others: a split delivery creates two operational events but only one billing line. Because the exception is found before cutover, the team changes the target relationship and repeats the reconciliation. The scenario does not claim a percentage improvement; it demonstrates how a failed rehearsal prevents an untested model from becoming production truth.
Control 6: cut over only when rollback is executable
The cutover decision is made against written conditions, not momentum. Northstar requires:
- named owners for every target state and exception;
- passed workflow tests for normal, held, changed and disputed work;
- approved data mapping and matching control totals;
- trained users able to complete role-specific tasks without coaching;
- support coverage and an issue triage route;
- a tested export and rollback procedure.
The rollback is more than “keep the spreadsheet.” It names the decision authority, trigger, time window, source of transactions during recovery, method for reversing integrations and reconciliation required before service resumes. Once the cutover is accepted, write access to the old workbooks is removed. Read-only retention follows the organisation's records and data obligations.
What Northstar does not migrate
The project deliberately leaves several things behind: personal spreadsheet layouts, duplicate customer-name columns, hidden color-based status, obsolete free-text notes and local reports whose decisions are now served by controlled definitions. It preserves the necessary business history and source archive without forcing every workaround into the new system.
This is an important distinction. A migration can be technically complete and operationally unsuccessful if it preserves every field but loses why people used it. Conversely, a shared system can simplify the data model when the team has consciously preserved the purpose, ownership and required evidence.
A reusable decision log for spreadsheet replacement
| Decision | Evidence required | Stop condition |
|---|---|---|
| Include a dataset | Active purpose, owner, retention need and target use | No owner or justified target purpose |
| Replace a local calculation | Formula meaning, inputs, output user and test examples | Result cannot be reproduced |
| Accept a target state | Entry, owner, exit and exception behavior | Different roles interpret it differently |
| Approve migration | Control totals, samples and exception sign-off | Material unexplained variance |
| Approve cutover | Workflow, people, support and rollback evidence | Rollback cannot be executed in the available window |
| Retire a spreadsheet | Replacement control proven and retention decision made | Critical dependency remains |
The lesson from the scenario
Replacing spreadsheets succeeds when the organisation creates one accountable workflow, not merely one database. The hardest work is making implicit definitions and local exceptions explicit, agreeing who owns them, and proving that migrated records reconcile to the decisions the business must make.
A team can apply the scenario at smaller or larger scale by changing the depth of evidence. The controls remain useful: inventory dependencies, reconstruct real work, design ownership, rehearse with control totals, constrain parallel operation and keep rollback executable. Those practices turn a software change into an auditable operating change.