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.