Retire an old task when the process owner has evidence that the accepted workflow delivers its required result, the people who depend on it have switched, and unfinished work and required records are accounted for. Name the task that will stop, the controls that remain and the person who can authorize the change. Acceptance of an AI-assisted workflow does not settle all three decisions automatically.
This is a practical decision for an operational manager whose team is still maintaining a spreadsheet, copying a report or repeating a check after a new route has been introduced. The workflow redesign guide explains how to change the end-to-end process. Here, the question is when specific old work can end.
Separate duplicate work from controls and history
Start by asking what each old step still does for someone. A spreadsheet that looks redundant may be the only place a colleague can see unresolved cases. Conversely, a report may continue circulating even though nobody uses it to make a decision.
Suppose a property-management team uses AI to turn residents' maintenance emails into draft request records. A coordinator checks the building, unit, reported problem and missing details against the original message. A maintenance supervisor determines priority and assigns the work. The request system records progress and completion.
The coordinator also maintains an older status spreadsheet. Before retiring it, classify the work attached to it:
| What the old process contains | Decision for this example |
|---|---|
Duplicate status entry | Stop once the request system serves its users and open cases are reconciled |
A necessary control | Keep the supervisor's priority and assignment decisions |
Historical evidence | Retain required past records in an approved, accessible form |
A fallback route | Keep tested instructions for recording requests when AI is unavailable |
These decisions can have different dates. Stopping new entries in a spreadsheet does not require deleting its history. Keeping a manual fallback does not require manually entering every routine request twice forever. Use the tools and workflows guide to place this decision alongside ownership, access and support.
Require evidence about the finished work
An acceptance meeting should establish which work was tested, what counted as an acceptable result and which problems remain. A demonstration of good AI drafts is insufficient if the supervisor still receives incomplete requests or the coordinator must repair the records later.
For the maintenance team, review evidence across the complete route:
- Source accuracy. The accepted record preserves the reported location and problem; missing details remain visibly unresolved.
- Exceptions. Urgent, ambiguous and out-of-scope requests reach the appropriate person under the existing procedure.
- Handoff and completion. The supervisor can assign the work, and the coordinator can find its current status without the spreadsheet.
- Workload. Checks, corrections and follow-up fit the team's capacity, including busy periods and staff cover.
- Dependencies. Everyone who used the spreadsheet can obtain the information they need from the replacement or an agreed alternative.
Choose coverage around the workflow's variation and consequences. A quiet week may reveal little about a monthly reporting dependency. If a consequential case has not occurred, arrange a controlled test with approved examples instead of assuming it will work.
Meta's May 2026 account of migrating data-ingestion systems describes a staged approach. New jobs first ran in shadow mode for comparison, then became the production route while the old jobs supplied comparison outputs. Legacy jobs were removed after continued agreement; validation infrastructure remained useful afterward. This is Meta's account of a data migration, not an evaluation of AI-assisted office work. The transferable principle is to separate evidence collection, changing the active route and removing the old work.
For AI-generated prose, agreement need not mean identical wording. Define the facts, decisions and omissions that matter. In the maintenance example, preserving the correct unit and an unresolved access question matters more than whether two summaries use the same sentence.
Resolve differences before declaring the comparison complete
Parallel running means comparing old and new routes for a defined purpose. It needs time, an owner and a way to resolve differences. Merely producing two outputs creates no evidence that anyone has examined them.
A historical example makes the distinction concrete. Audit Scotland's 2012 review of East Ayrshire Council's payroll implementation describes parallel runs that identified differences and keying errors. Testing expanded beyond the payment total when other issues emerged. The council reported that keying errors reduced before go-live and that monitoring would continue. This was a payroll migration, not an AI trial; it illustrates why a comparison must lead to correction and a decision.
For each material difference, determine whether it is a defect in the new route, an old-process error, a deliberate approved change or an unresolved issue. Do not require the new workflow to reproduce a known mistake simply to match the old output. Equally, do not dismiss a mismatch because the AI version reads well.
Keep the tested configuration identifiable. In a September 2026 Reddit discussion, a user describing database and application experience worried about continuing code releases as a migration cutover approached. The post reports a concern, not a confirmed failed migration. It raises a useful question for an AI workflow: does the version being accepted still match the instructions, sources and connections that were tested?
If material changes occur, repeat the affected checks. Record any remaining restriction rather than treating the original acceptance as permanent permission.
Make the changeover visible to the team
Once the evidence supports retirement, choose a clear point after which new work uses the agreed route. Identify where each already-open case will finish. Avoid leaving colleagues to decide individually which record is current.
For the maintenance coordinator, that could mean reconciling outstanding spreadsheet rows against request IDs, resolving duplicates, and making the spreadsheet read-only after the owner approves the switch. The team still keeps access to past records as required by its retention policy. The actual setting changes need the system owner's authorization.
In a May 2026 X account, internal-tool builder Omar described moving applicant-tracking records to a new system, making the old tool read-only at a known point while retaining synchronization and reconciliation checks. His reported outcomes are unverified. The useful distinction is between ending routine work in an old tool and ending every check associated with the move.
A fallback also needs current information. AWS's cutover guidance warns that new transactions after a switch can leave the old database stale. For a business process, ask how requests received since the changeover would be accounted for before returning to a manual route. An archived spreadsheet is not automatically a usable fallback. The AI continuity guide explains how to rehearse the alternative.
Record what will stop and who accepts the decision
Use the existing operating record rather than creating another report that somebody must maintain. The retirement entry should let an absent colleague understand the decision and its limits.
Record:
- Scope and evidence. Name the exact old task, the replacement, the tested version and the acceptance evidence.
- Exceptions and dependencies. Identify unresolved cases, restrictions and anyone who still needs an old output.
- Cutover. State when new work changes route and where open work will finish.
- What remains. Name the retained controls, history, support owner and fallback instructions.
- Authority and follow-up. Record who approved retirement, what would trigger intervention and when the result will be reviewed.
If a dependency remains, narrow the retirement decision. A monthly report might still require an export while daily duplicate entry can end. Give that exception an owner and a review date so it does not silently become permanent.
Finally, check whether the work actually disappeared. Ask the coordinator to show how the next requests were handled. Include corrections, checking and any private copy that has reappeared. A stopped spreadsheet is useful evidence of removed work; it is not, by itself, proof of a financial saving. Compare the whole task using the net time savings guide.
Questions about retiring an old workflow
How long should a parallel run last?
A parallel run should last long enough to test the agreed business conditions and resolve material differences, with a named owner and an exit decision. There is no universal number of weeks for an AI-assisted workflow. Identify important cycles, exceptions and dependencies before choosing the comparison window. If keeping two routes running is unaffordable, narrow the scope or use approved historical cases for part of the testing; do not claim unperformed comparisons as evidence. Use the acceptance checks to define what the window must establish.
Does accepting an AI workflow mean we can delete the old records?
No. Accepting a replacement process and deciding how to retain historical records are separate decisions. Confirm the organization's retention and access requirements with the responsible owner, then choose an approved archive or read-only arrangement. Before stopping new entries, reconcile open work and tell users which record is authoritative. The changeover section explains how to keep those decisions separate.
What if the old and new outputs disagree?
Investigate the difference against the source information and agreed outcome. It may be a new defect, an old error or an intended change; an unexplained difference is not an acceptance result. For generated summaries, compare important facts and missing information rather than requiring identical wording. Fix or explicitly restrict the affected work, then repeat its checks before retiring the old task. Keep the difference-resolution decision with the evidence.
Who should approve retiring the old process?
The accountable process owner should authorize the operational change with the people who perform, receive and support the work. System, control and records owners must approve changes within their responsibilities. An AI tool's owner alone may not have that authority. Record the precise task ending, retained controls, open-work disposition and follow-up so approval is actionable. Start with the retirement decision record.
