# Change Management

Use a proportional process: small reversible changes need less ceremony than migrations or compatibility changes, but every production-affecting change needs an understood verification and rollback path.

## Before a change

Identify the affected product/service, expected behaviour, dependencies, data/config migrations, compatibility impact, validation method and rollback method. For high-risk changes, record an explicit maintenance window and recovery owner outside the wiki if required.

## During a change

Capture the deployed version/commit and avoid mixing unrelated changes into the same recovery boundary. Stop when validation fails rather than stacking further speculative changes over an unknown state.

## After a change

Verify the intended behaviour, record any operator-facing differences, update affected wiki reference pages, and close temporary migration instructions once they are no longer needed.

For releases, start from [[Templates/Release-Checklist]].