Change a Live Workflow Without Losing the Cases Inside It

A workflow change can appear small in a diagram and still affect many live cases. Renaming a status, changing an approval threshold, or replacing a system connection can alter routing, reporting, permissions, and the meaning of old records.

The safe approach begins by separating the new definition from the cases already using the old one. Decide when the new version starts, which cases move, which stay, and how both versions remain understandable.

State the reason and success test

Write the problem before the solution. Identify the observed failure, affected users, and evidence. Then define what must improve and which quality measures must not decline.

For example, a change can aim to reduce median intake delay while keeping rework and incorrect routing below agreed limits. This is stronger than “simplify the process” because the team can test it.

Name the policy owner, workflow owner, technical owner, and release decision maker. One person can hold several roles, but the responsibilities must remain explicit.

Version the definition

Give the new workflow definition an effective time or version. Keep the earlier rule set and supporting documentation. A historical case must be explainable by the rules that applied when its decisions occurred.

Avoid editing past events to match new terminology. If a reporting model needs normalized categories, preserve the original event and add the mapping. This keeps the record accurate while allowing useful analysis.

Decide what happens to open cases

There are three common choices: finish cases under the old version, migrate them to the new version, or split them at a safe milestone. Choose by consequence, volume, and the difference between definitions.

If cases migrate, define a mapping for every state and required field. Test missing and invalid values. State who resolves cases that cannot map automatically. Do not put them into a generic error queue without a return path.

If old and new versions run together, make them visible to operators. Instructions, dashboards, and escalation paths must show which version governs a case.

Test the difficult paths

Use normal, rejected, duplicate, overdue, delegated, and integration-failure cases. Verify permissions, notifications, timers, reports, and audit events. Check what happens during retry and recovery, not only during a clean run.

Review accessibility and language changes when the workflow has forms or public messages. Check links, attachments, and downstream exports. The GOV.UK Service Manual is one useful public reference for service design and operating a live service, although each organization must apply its own requirements.

Release in an observable way

Choose a small initial scope when the risk supports it. Monitor arrival volume, routing, wait time, error rate, rework, and user reports. Compare the results with a recent baseline and inspect individual cases behind unusual numbers.

Define stop and rollback conditions before release. A rollback must address both software and data. Restoring code does not automatically restore cases that moved under the new rules.

Keep a decision log during the release. Record when the version started, checks performed, incidents found, actions taken, and the person who approved continuation.

Close the change

After a stable period, resolve temporary compatibility paths, update operating guidance, and archive the release evidence. Confirm that dashboards and service-level reports use the correct version boundaries.

Ask operators and requesters what changed in practice. Technical success does not prove that the new process is easier to use. Compare the result with the original success test and record what remains open.

A workflow is a living operating agreement. Changing it safely means preserving the meaning of prior decisions, protecting cases already in motion, and making the new behavior observable. That discipline supports faster change because the team knows where the risks are and how it will respond.