IT change management makes a software or configuration change deliberate: someone understands the affected service, approves the impact, checks the result, and owns recovery when the change fails. The practical unit is a business workflow that must continue to work.
Describe the change and its dependencies
Write the reason for the change, affected systems and locations, current and target versions, business owner, technical owner, and proposed window. Identify dependencies such as authentication, databases, printers, integrations, and client versions. Establish how urgent the change is and what happens if it is delayed.
NIST SP 800-128 describes security-focused configuration management, including baselines, controlled changes, and monitoring. Use the relevant controls to protect the system's intended configuration. The workflow below is an illustrative planning aid; implementation steps must come from documentation for your actual systems.
Before testing, record the known working state and how it was established. A baseline includes important settings and dependencies as well as a version number. Keep sensitive configuration and access details in controlled systems.
Test a representative workflow before a broad rollout
Choose a test environment or controlled pilot that represents the relevant operating conditions. Include a typical device and any unusual but supported combination that matters, such as a branch printer or an older client. Use approved test data and prevent test notifications or transactions from reaching real customers.
For each check, write the action, expected result, evidence to retain, and person who accepts it. “The installer finished” confirms only one part of the change. Check sign-in, the main business task, dependent systems, access boundaries, and the route back to service.
On a small screen, scroll the table sideways to read all columns.
| Check | Expected evidence | Action if it fails |
|---|---|---|
| Create and retrieve a test service order | Same order and amount visible after reopening | Stop expansion; inspect storage and version compatibility. |
| Print through the branch printer | Complete, legible document with the correct order reference | Hold the affected configuration; compare driver and layout. |
| Use an ordinary staff account | Only authorized records and actions available | Stop expansion and investigate the permission change. |
| Exercise the supported recovery procedure | Service restored and test transactions reconciled | Revise the plan before authorizing more devices. |
Use rollout gates that allow time to learn
Define the observation period around real usage: a nightly job or weekly export may reveal a problem later than an interactive check. Record excluded and offline devices. Give those devices an explicit update plan so a partly deployed estate is visible.
Plan recovery around both software and data
Establish the documented recovery method, required access, expected service interruption, and the point at which recovery becomes harder. A database migration, an external message, or a completed customer transaction can make simply reinstalling an earlier version insufficient.
Test the supported recovery route in a suitable environment. Identify what state must be restored, how new transactions will be handled, and who reconciles any gap. If the change is irreversible, document the forward-repair and continuity route before authorizing it. A backup becomes useful evidence only after its relevant restore behavior has been checked.
Set a latest decision point within the maintenance window, leaving time for the tested recovery route. Define the conditions that stop expansion immediately and the people who can make that call.
Communicate and verify the final state
Tell affected staff what will change, when service may be interrupted, how to report a problem, and what temporary procedure is approved. Keep a short event log during deployment with timestamps, versions, test results, decisions, and exceptions.
Afterward, reconcile intended and actual device state, review error reports and support contacts, and ask the business owner to confirm the workflow. Record unresolved issues with owners and dates. Emergency changes still need a documented impact decision and a later review of what was done.
The change-plan template captures scope, evidence, rollout gates, and recovery responsibilities. See Adaptive Data Integration for changing data formats and Business Automation for exception handling.