Move a live workflow with a rehearsed cutover: define record ownership, clean and map the data, validate a trial import, account for changes during the move, and agree when to stop or roll back.
Define which system owns the work
Moving rows is only part of replacing a spreadsheet. Someone must decide where a new request is created, where its status is updated, and which record the team trusts during the transition.
Our recommendation is to name one authoritative location for each stage. A temporary period with two systems can help validation, but two uncontrolled places to edit the same work create a reconciliation problem. Write down exactly who can change what.
Clean decisions before cleaning cells
A blank status might mean not started, unknown, or no longer relevant. Duplicate customers might be separate branches rather than accidental copies. Ask the people running the process to resolve those meanings before choosing automated transformations.
Create a small mapping document with source column, destination field, transformation rule, and exception owner. Keep the original reference so the team can trace a new record back to its source without relying on names alone.
Rehearse with realistic data
Use a controlled trial import with representative records, including awkward ones. Check counts, relationships, important totals where relevant, and whether the people using the system can perform their actual tasks. A matching row count does not prove every field means the same thing.
Microsoft’s cutover guidance includes migration validation, clear responsibilities, rehearsal, and rollback planning. Those principles also provide a useful framework for a smaller workflow move, though the specific implementation will differ. Source: Microsoft cutover planning guidance.
Account for work that arrives during the move
If the business keeps accepting requests while the import runs, define how those new records reach the destination. Options include a short agreed pause, a final incremental import, or a controlled intake queue. Choose based on operational needs rather than convenience for the import script.
The cutover plan should identify the final edit point in the old sheet, the owner of the last import, the person validating it, and the signal that tells staff where to work next.
Write a stop rule before launch day
Define a small set of conditions that block the switch, such as missing assignments or records that cannot be traced. Decide who can call a pause and what staff should do while the issue is resolved.
Rollback is not simply restoring a copy if people have already created new work in the new system. The plan needs to account for those actions. A staged move of one team or workflow may reduce the amount of work that needs reconciliation.
The first week is part of the move
Assign a person to collect exceptions and questions after cutover. Look for duplicate entry, staff returning to private sheets, and statuses that do not match the way the team works.
Treat those observations as operational feedback. A completed import is a technical milestone; the workflow is established when people can use the new system without recreating the old process beside it.
Technical references
The business checklists above reflect our proposed approach. The following primary sources support the technical points cited in the guide.