The Change Lifecycle: Registration to Closure
The stages
Registration: capture the change as a record - description, justification, affected services and CIs, requester, proposed window, and initial categorization. Good records make later assessment possible; poor ones make it guesswork.
Scheduling: place the change in the change schedule, checking conflicts with other changes, blackout or embargo periods, business cycles (month-end, peak trading), resource availability and supplier dependencies.
Assessment: evaluate risk, impact, testing evidence, rollback, dependencies and readiness, and produce a recommendation for the change authority.
Authorization: the change authority decides - approve, reject, defer, or approve with conditions such as a phased rollout or additional testing. The decision and its rationale are recorded.
Implementation: execute per the plan, with the agreed controls. If the change starts to deviate, it may need re-assessment and re-authorization rather than improvised approval.
Closure: confirm the change achieved its intended outcome, update configuration and knowledge records, close related tasks, and feed results back - including failures, workarounds and lessons - into continual improvement and the review of standard change models.
Traps
The lifecycle is not strictly linear in every case: emergency changes may be registered and implemented first and documented afterwards, and a change can return to assessment at any point. Questions often imply closure means "technically deployed"; it means the outcome is verified and records are updated. Another trap is treating scheduling as a formality - conflict detection is where many change-related incidents are prevented.
Rule of thumb: a change is not closed until the configuration records, knowledge articles and the change record all agree with reality.