Change Management Procedures – CompTIA Network+ N10-006 – 5.8


There will always be changes to the network, and the management of these changes is critical. In this video, you’ll learn about the change management process.
<< Previous: Labeling and DocumentationNext: Common TCP and UDP Ports >>


There are always going to be changes happening in your network. You’re going to be upgrading software and modifying switch configurations and updating a firewall and changing a routing setting. And all of these changes need to have a formal process behind them so that you can avoid any of the problems that can happen. These can create significant risks to the enterprise if the network, for some reason, doesn’t operate the way you would expect.

There need to be very clear, very well-documented policies for how you handle these changes. How often do the changes occur and what time of the day do these changes take place? How much time is applied towards a change window? What is the process for performing the change, and how do you back this change out?

There are so many questions that need to be answered relating to this change control process, and that’s why it can often be very difficult to implement. So you can’t just flip a switch and have a change control process. Everyone has to get on board with understanding the process. Everything has to be documented, and everyone in the organization has to agree that this is the best way to handle changes.

The change control process usually starts with the request itself. What do you want to change? There’s usually a documentation that you would write up that explains here’s the change that we would like to make and why we’re doing that. And the why you’re doing that usually ties back to something relating to your organization’s business or tasks. That way you can apply this change to something that’s really going to help the overall organization.

The change control process will usually have what the configuration procedures might be for the change that you’re doing, what the rollback process might be if things don’t work the way you would expect, what impact this change might have and to what parts of the organization, and how you’re going to notify the people who may be impacted by this change.

Most organizations will do a formal change control process meeting every week. So on Thursdays at 11 o’clock everyone meets in a particular room and you all discuss what the plans are for changes that are going to occur over the weekend or two weeks from now or next month. The exact process varies from place to place and the time frames, of course, are different depending on your organization. But the important part is that everyone attends.

Just because you’re making a change to the network doesn’t mean that it will have zero impact on the server team, on the security team, on the networking team, on the voice over IP team, and so on. Everyone has to be on board with the change control process, so it’s important that everyone attend these meetings.

In most organizations is going to be a formal change control window, a maintenance window that has already been set aside that whenever something happens it will always happen in this time frame. It might be Friday night between 8:00 and midnight. It might be Sunday morning between 1:00 AM and 5:00 AM. But there will always be a window where you’re authorized to make these changes as long as these changes have been approved.

It’s important that the notification of this change be made to everyone who’s impacted. You want to contact the end users, you want to contact the support teams, contact the help desk and let them know that this change is going into effect and here’s the applications and other devices that may be impacted by this change.

The change control process almost always includes an extensive amount of documentation. Just because you know what the change is going to be doesn’t mean that anyone else will understand. So you have to completely document, with detailed information, perhaps some network diagrams and some documentation over what versions might be updated or things might be changed in a configuration so that everyone understands the impact and scope of this change that you’re making.