# Change compensation rules while workflows remain active

Old sagas may have committed effects under an earlier contract. Version the recovery logic and decide how those records continue before deploying new rules.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Inventory active workflow versions

Count sagas by version, current step and age. Identify those with completed effects, uncertain operations or compensation in progress. Their needs differ from new workflows that have not yet started.

Record the service contracts and identifiers saved by each version. A new compensation command may require information older records did not capture.

Do not assume the latest code can interpret every historical state. A renamed field or changed business rule can make an old recovery path invalid even when the record still parses.

## Choose how old runs continue

Keep compatible old handlers, migrate state with reviewed transformations or route selected cases to a manual resolution path. The choice depends on whether the meaning of completed effects can be preserved.

Never manufacture evidence or approval during migration. If a new rule requires information unavailable in the old record, make that gap explicit.

Keep operation identifiers stable. Changing a compensation identifier during migration can cause the downstream service to treat recovery as a new independent action.

## Test paused and partially recovered fixtures

Save fixtures after each consequential forward step and during uncertain compensation. Deploy the candidate and resume them.

Inspect final business state, not only the coordinator's transition log. A migrated record can advance successfully while applying the wrong correction to an external service.

Test overlapping workers from old and new deployments if the platform permits them. Version-aware claiming or routing should prevent unsupported code from taking ownership of a run.

## Plan rollback and retirement

New code may write states that old code cannot understand. Define the rollback window and compatibility rules before activation, or use a controlled forward-recovery plan where restoration is not safe.

Monitor old-version backlogs and assign owners to long-lived cases. Retaining obsolete recovery code indefinitely creates maintenance and access obligations.

Retire a version only after its active effects have a known resolution or supported migration. The release succeeds when both new workflows and already committed work have a clear path to an acceptable business state.

## Sources

- [Microsoft Learn: compensating transactions](https://learn.microsoft.com/en-us/azure/architecture/patterns/compensating-transaction)
- [AWS: workflow redrive](https://docs.aws.amazon.com/step-functions/latest/dg/redrive-executions.html)