IT Change Checklist: Before You Go Live

A technically successful update can still interrupt business activity. Preparing a change means assessing its consequences, organising the decision and knowing what to do if the expected result is not achieved.

1. Describe what will change

Explain the business objective, the items being modified and what may be indirectly affected. Identify dependencies such as service accounts, interfaces, backups, equipment and procedures. “Technical update” is not a sufficient description on its own.

2. Review risks and authorisation

Describe the consequences of failure, the implementation window and who is authorised to decide. For a system subject to quality or regulatory requirements, involve the appropriate owners and follow your organisation’s change process.

3. Define tests and recovery

Before starting, decide which checks allow the team to continue, stop or roll back. Verify recovery prerequisites, including usable backups, version compatibility and the ability to restore data. Some operations cannot be reversed; they need an appropriate recovery strategy rather than a routinely ticked rollback box.

Pre-implementation checklist

• Objective and scope understood by the relevant owners.
• Dependencies and critical activities identified.
• Tests completed and results retained.
• Authorisation obtained under internal rules.
• Implementer, decision-maker and support contacts identified.
• Window and communication agreed with affected people.
• Success, stop and rollback criteria defined.
• Recovery prerequisites checked.
• Post-change checks and monitoring planned.

Example: changing an access rule

A security rule can protect accounts while also preventing legitimate work. Identify the users and applications affected, test on an appropriate scope and prepare an authorised recovery route. Validate the business activity, not just whether the configuration was saved.

After implementation

Record timings, deviations from the plan, test results and any incidents. Update useful documentation and obtain confirmation that the intervention is complete. If an incident occurs, link the records to support investigation.

Common mistakes

Approving after implementation, treating a backup as proven recovery, overlooking a dependency or assuming that no alert means success all weaken change control.