Change is high-risk behavior. Nevertheless, it must be done

Change is arguably one of the riskiest behaviors within IT. Whenever we make a change, things tend to break. It is in no way coincidental that one of the foci of change management is post-change incidents, i.e. the errors introduced by the changes we make. I would go so far as to say that the only thing associated with higher risk than change is not changing.

As I have written before, what lies at the heart of change management is not merely managing the change in and of itself, but managing the risks involved with the change. Crucially, the change manager should spend time talking to those responsible for carrying out the change, evaluating the impact on customers, and involving the customers as needed.

What involvement you need depends on the impact of the change. If the change is to a fully redundant system, you will likely not need to involve the customer at all, while a change that involves outages will at the very least involve notifying them. In more extreme cases (such as full OS upgrades), the change might involve hands-on training with the customer, a show of force at the customer location and so on.

At the end of the day, there is no credible alternative to change. Not performing changes results in increased technical debt, unresolved security issues, and higher operational risks than those introduced by executing changes in the first place.