Replace one approval route, not the whole workbook. Keep the spreadsheet as an explicit reference while the new process is tested, reconcile every in-flight request, and name the moment when the source of truth changes.
That approach reduces disruption. It cannot promise zero disruption.
If you are still deciding whether the spreadsheet needs an app, use the spreadsheet workflow readiness assessment first. This guide begins after the team has found a specific approval process worth migrating.
If the approval policy, states, actors, or exceptions are not yet settled, use the approval workflow build guide first. This guide focuses on migration after the route is understood.
Do not treat the spreadsheet as the enemy
Modern Excel supports co-authoring, a changes view, version history, and restoration when the documented requirements are met. Google Sheets supports protected ranges, while explicitly warning that protection should not be treated as a security measure because trusted users may still copy or export content. Microsoft Excel co-authoring, Google protected sheets and ranges.
The case for an app is not “spreadsheets are bad.” It is that an approval requires states, role-specific actions, evidence, and recovery that a shared grid no longer represents safely or clearly.
Use a seven-step migration
1. Freeze the policy definition
Agree what the approval currently means: who can request, what evidence is required, who can decide, how rejection works, and what follows approval. Do not redesign the policy during data migration unless the owner explicitly approves the change.
2. Inventory the real system
List columns, formulas, macros, validation, protected areas, linked files, email instructions, chat reminders, and reports. Follow one ordinary request and one exception. The workbook is rarely the whole process.
3. Map columns to workflow
| Sheet item | Business meaning | App representation | Validation/actor | Historic treatment |
|---|---|---|---|---|
| Request row | One purchase request | Request record | Created by requester | Import only required open/history records |
| Status | Current stage | Controlled state | Changed only by allowed action | Preserve original value for audit/reference |
| Approver | Decision owner | Role/assignment | Must be authorised | Resolve leavers and missing owners |
| Comment | Reason/evidence note | Decision or activity record | Required on return/rejection | Do not overwrite earlier decisions |
| Formula result | Routing input | Explicit calculated/entered field | Validate assumptions | Test against representative cases |
Microsoft documents an approval pattern where status is stored in a table and the flow operates over that persistent state. That is a useful design principle even if you choose another platform. Microsoft approval loop.
4. Choose one low-risk route
Pick a recurring approval with a named owner and representative exceptions. Avoid starting with the most regulated or financially consequential workflow merely because its pain is visible.
5. Build and test privately
In KasiLabs, describe the request, evidence, states, roles, routing, rejection, resubmission, and completion action in plain language. KasiLabs creates a plan and private working version. Test synthetic cases first, then a controlled set of representative cases with authorised users.
6. Reconcile before cutover
For every open request, decide:
- finish it in the sheet;
- recreate it in the app with a reference to its history; or
- cancel and resubmit under the new process.
Record the choice. Prevent the same request from being approved in both systems.
Use a reconciliation log during the parallel run. It needs only the request identifier, current system, owner, state in each system, discrepancy, resolution, and date checked. Review it daily for the bounded pilot. A growing discrepancy list means the team is running two processes rather than validating one replacement.
Set a stop condition before the pilot begins. Examples include an unauthorised decision, a lost in-flight request, a duplicate downstream action, or a material mismatch that cannot be resolved from the recorded history. The exact condition belongs to the process owner; the point is to agree it before enthusiasm for the new interface changes the standard.
7. Cut over with rollback rules
State the last time new requests may enter the sheet, who owns in-flight work, where the sheet is archived, which access is removed, who supports the app, and what condition triggers rollback. Keep the previous app version and a read-only reference until the agreed retention and reconciliation work is complete.
GOV.UK migration guidance recommends involving users, planning testing and training, communicating change, and evaluating migration risks. Its deployment guidance recommends small, auditable releases, smoke tests, and rollback-ready discipline. Managing legacy technology, deploying software regularly.
A purchase-request cutover
Suppose the sheet contains requester, supplier, evidence, amount, cost centre, approver, decision, reason, and timestamps. The new app should not simply recreate those columns.
It should prevent submission without required evidence, assign the correct approver, restrict Finance-only information, preserve each decision, return a request with a reason, and show the requester what happens next.
Train people on the difference in work, not the location of buttons. Explain where a new request begins, which spreadsheet behaviours no longer apply, how to return an incomplete request, where to see ownership, and whom to contact when the route is wrong. Keep the cutover message short enough that staff will use it during the first live day.
At cutover, the owner might finish requests already under review in the sheet and direct all new drafts to the app. Or the team might migrate open cases if they can reconcile each one. The correct choice depends on volume, risk, and the quality of the historical data. Do not invent a universal migration rule.
Why KasiLabs fits this migration
KasiLabs lets the people who understand the workbook describe the work directly. They see the plan before build, use a private working copy, choose access and spending limits, and approve the exact release. Earlier versions remain available.
This keeps the migration grounded in observable work instead of a long technical specification. It also prevents a file upload from being mistaken for workflow redesign. KasiLabs does not promise automatic formula, macro, or data conversion; the operating team decides what each element means and what should move.
Keep the sheet when the approval is occasional, low-risk, and well controlled. Stop if critical macros or connections are not understood, the policy has no owner, or the team cannot support a cutover.
Archive is not the same as deletion. Decide whether the old workbook remains read-only, how long it is retained, who can access it, and how future audits or corrections will connect an old row to the new request record. Apply the organisation’s actual retention obligations; this guide does not supply a universal period.
When one spreadsheet approval is ready for a private pilot, bring that route to KasiLabs. Keep daily work running, test the replacement against real exceptions, and choose the cutover only after reconciliation.