Contact Discuss an opportunity
Proof Engine cover card reading 'The backup became the default' over diagonal retro stripes in red, orange, mustard and cream on a dark navy background

The Old Workflow Needs An Exit Date

A team launches a new workflow and keeps the old one “just in case.”

Some customer calls enter the managed system. Others stay on personal phones. A portion of the follow-up is written into the CRM, while the rest survives in private notes or a spreadsheet. The new process reports incomplete usage. The old process reports incomplete reality. After a month, no one can tell whether adoption failed or whether the company never made a migration decision.

The problem looks like data hygiene. It is usually governance.

A new workflow does not become the operating workflow merely because the feature is live, the users were trained, or the integration was connected. It becomes real when the organization decides which work must enter it, which record is authoritative, how exceptions are handled, and when the previous path stops being the default.

The old workflow needs an exit date.

Running in parallel can be responsible

Parallel operation is not automatically a mistake. Early in a migration, it can protect customer work, compare outputs, reveal missing cases, and give the team time to test reliability under real conditions. For consequential workflows, an immediate cutover may create more risk than learning.

The important distinction is between a time-boxed parallel run, a controlled fallback, and indefinite duplication.

A time-boxed parallel run has a purpose and a review date. A controlled fallback is invoked by a defined failure and ends when a return condition is met. Indefinite duplication allows every person to choose the path they prefer without producing a decision about the new system.

Only the third state makes adoption impossible to interpret. Users may appear inactive because the legacy path remains easier. The new workflow may appear reliable because difficult cases are quietly handled elsewhere. The organization pays for two processes and learns from neither.

Software modernization offers a useful analogy. AWS describes the strangler fig pattern as an incremental replacement approach in which old and new capabilities coexist while functionality moves gradually, until the legacy system can be decommissioned. The lesson for operating workflows is not to copy a software architecture pattern literally. It is to make coexistence directional. The new system should be replacing named functions, not merely accumulating beside them.

Define the old workflow by function

Teams often describe the old process by its tool: spreadsheet, WhatsApp, personal phone, shared inbox, legacy CRM. That is not enough. The workflow is the function the tool performs and the behavior around it.

Where does work begin? Who captures the information? How is it routed? Who reviews it? Where are exceptions stored? How does a person know that the next action happened? Which record is considered true when two records conflict?

Until those questions are answered, the team cannot state what the new workflow is replacing. A new capture system may not replace review. A new summary may not replace the decision. A new CRM write may not replace the private conversation where the owner actually commits.

The replacement unit must therefore be narrow enough to observe. It may be call capture, qualification, routing, review, follow-up, reporting, or approval. Overstating the scope creates a premature cutover and hides which dependency remains outside the system.

Duplication has a cost

Parallel work is often treated as free because no new software line item appears. The cost shows up elsewhere: double entry, reconciliation, missing context, repeated reviews, conflicting records, extra support, and uncertainty about ownership.

That cost belongs in the migration decision. If a salesperson records the call in one place and reconstructs the next step in another, the team should count both actions. If a manager checks the CRM and then asks the seller for the “real” status, that second step is evidence that the official record has not earned authority.

The cost is not only time. Duplicate systems increase the chance that a customer receives the wrong follow-up, that an exception disappears, or that management makes a decision using partial data. A controlled parallel run accepts some of that cost for a bounded learning period. Indefinite duplication normalizes it.

Three timelines. A time-boxed parallel run ends at a decision gate. A controlled fallback moves work to the old path on a trigger and returns on a defined condition. Indefinite duplication scatters work between the old and new paths with no gate. The first two have a purpose, an owner and an exit condition; the third has none.

Give the transition an owner

Migration ownership does not mean one person performs every task. It means one role is accountable for interpreting the evidence and calling the decision.

That owner watches capture completeness, unresolved exceptions, user behavior, support volume, data reconciliation, and fallback events. They coordinate communication and decide whether the migration is ready to advance, needs a bounded extension, should narrow in scope, or must roll back.

Without that role, each team optimizes locally. Product looks at system runs. Operations looks at continuity. Sales looks at customer satisfaction. Users look at workload. All of those views matter, but none of them alone can declare the new workflow authoritative.

The NIST AI Risk Management Framework treats ongoing monitoring, periodic review, clear responsibilities, and safe decommissioning as governance work. That is especially relevant when an AI-enabled workflow changes who can act, what becomes a record, or how decisions are made. The migration is not finished at launch. It needs an owner through cutover and stabilization.

An exit date needs evidence

A calendar date creates urgency, but a date alone can force a decision before the system is ready. The strongest exit plan combines time with evidence thresholds.

Useful thresholds may include:

  • a defined percentage of eligible work captured through the new path;
  • accepted output for the chosen workflow and user group;
  • no unresolved high-severity failure during the comparison window;
  • named ownership for review, exceptions, and support;
  • a tested fallback for critical work;
  • user behavior showing that the new path is becoming the default;
  • complete data and history rules for the records that matter.

The denominator matters. If some cases are officially allowed to remain in the old workflow, remove them from the adoption calculation. Otherwise the team may diagnose poor adoption when it is actually measuring its own exception policy.

The threshold should be strong enough to support the decision and narrow enough to measure. “The team feels comfortable” is not sufficient. Neither is “100 percent migration” if the workflow includes rare cases that have not yet occurred. The evidence standard should match the consequence of the cutover.

Move the memory, not only the work

Legacy workflows hold history. Some of it is structured data. Some of it is context embedded in notes, folder conventions, private messages, or one experienced operator’s memory.

The exit plan must decide what is migrated, what remains read-only, what is archived, and where people search for past context. Otherwise the new workflow starts with a blank memory while the old workflow remains necessary for every real case.

This is where The Data Layer Is Becoming A Trust Layer becomes more than a data article. Users trust the new process when records have source, date, ownership, and a clear relationship to the prior system. A migration that copies fields without preserving provenance can create a technically complete but operationally untrustworthy record.

Permissions and informal authority also have to move. The old process may depend on a manager who knows which exception can be approved, which customer requires a special route, or which correction is safe. Cutover should turn those private rules into roles, controls, and escalation paths.

A fallback needs its own exit condition

A fallback is useful when the new workflow cannot safely continue. It becomes harmful when “temporary” means anyone can return to the old process whenever the new one creates friction.

Define the trigger, owner, duration, and return condition. Is fallback activated by a system outage, missing data, high-severity error, unavailable reviewer, or a specific customer condition? Who records the event? Who decides when the new path resumes? What happens to work created during fallback?

This is also where rollback differs from abandonment. A rollback is a planned response to evidence. It protects continuity while preserving the decision process. Indefinite fallback silently removes the new workflow’s authority and makes every metric ambiguous.

Tell users which path is real

People return to the old process for rational reasons. They may not know the new workflow is the default. They may fear losing information. They may not know where support lives or which cases are excluded. If the organization communicates only that a new tool is available, optional behavior is the predictable result.

Users need to know the effective date, the covered work, the exceptions, the source of truth, the support route, and the consequence of using an unapproved path. This is not change-management theater. It is part of the operating design.

After cutover, observe the shadows: private notes, manual exports, missing cases, personal messages, and customer delays. These are often better indicators of incomplete migration than a login metric. The transition ends when continuity and authority have been demonstrated, not when the old interface is hidden.

Workflow exit scoreboard with six evidence rows: eligible-work capture, accepted output, severity threshold, owner coverage, fallback readiness and user default behavior, each with a current value, threshold, owner and review date. An exit gate leads to four decisions: cut over, extend with bounds, narrow scope or roll back. The values are illustrative.

Write a Workflow Exit Plan

For one new workflow, create a one-page plan containing:

  • the legacy function, not only the legacy tool;
  • the exact unit the new process replaces;
  • the purpose and cost of the parallel run;
  • the migration owner;
  • evidence thresholds;
  • the authoritative record;
  • data migration and archive rules;
  • permission and exception ownership;
  • fallback trigger and return condition;
  • exit date and review date.

If the workflow is a pilot, connect this plan to the commercial decision. A Pilot Needs A Conversion Contract argues that success should lead to an agreed stop, extension, paid deployment, or expansion decision. Adoption evidence is weak when the customer was never required to move work into the pilot’s operating path.

For phone-heavy revenue work, the contrast may be especially visible: a managed business number and CRM flow on one side, personal devices and manual notes on the other. The Business Number Is A Revenue Control Surface explains why capture, consent, ownership, follow-up, and continuity begin before the CRM. The migration plan must state when that managed surface becomes authoritative and which exceptions remain legitimate.

Proof Engine’s AI Workflow / Internal Product Build work treats implementation as part of the product decision. That includes the unglamorous question many teams postpone: what old behavior has to stop for the new system to produce honest evidence?

Launch creates possibility. Migration creates reality.

Give the old workflow an explicit exit decision before two half-systems become the permanent operating model.

FAQ

Is running the old and new workflow in parallel always a mistake?

No. A time-boxed parallel run with a purpose and a review date, or a controlled fallback invoked by a defined failure, can protect customer work, compare outputs and reveal missing cases. Indefinite duplication is the problem: every person chooses a path and nothing produces a decision about the new system.

What makes an exit date credible?

Time combined with evidence thresholds, such as the share of eligible work captured through the new path, accepted output, no unresolved high-severity failure in the comparison window, named ownership, a tested fallback and user behavior showing that the new path is the default. “The team feels comfortable” is not sufficient.

Why does the denominator matter when measuring adoption?

Cases that the plan officially allows to stay in the old workflow have to be removed from the adoption calculation. Otherwise the team may diagnose poor adoption when it is actually measuring its own exception policy.

What does a fallback need?

Its own trigger, owner, duration and return condition. A rollback is a planned response to evidence that protects continuity while preserving the decision process. An indefinite fallback silently removes the new workflow’s authority and makes every metric ambiguous.

Sources