Database change management is the process used to manage the changes that occur after a system is implemented. A change management process has the following benefits:

1. It helps you understand when it is acceptable to make changes and when it is not.
2. It provides a log of all changes that have been made to assist with troubleshooting when problems occur.
3. It can manage versions of software components so that a defective version can be smoothly backed out.

Change is inevitable. Not only do business requirements change, but new versions of database and operating system software must be incorporated. Technologists should devise a change control method suitable to the organization, and management should approve it as a standard. Anything less leads to chaos when changes are made without the proper coordination and communication.

Although terminology varies among standard methods, they all have common features:

1. Version numbering: Components of an application system are assigned version numbers, usually starting with 1 and advancing sequentially every time the component is changed. Usually a revision date and the identifier of the person making the change are carried with the version number.
2. Release (build) numbering: A release is a point in time at which all components of an application system (including database components) are promoted to the next environment (for example, from development to system test) as a bundle that can be tested and deployed together. Some organizations use the term build instead.
   As releases are formed, it is important to label each component included with the release (or build) number. This allows you to tell which version of each component was included in a particular release.
3. Prioritization: Changes may be assigned priorities to allow them to be scheduled accordingly.
4. Change request tracking: Change requests can be placed into the change control system, routed through channels for approval, and marked with the applicable release number when the change is completed.
5. Check-out and check-in: When a developer or DBA is ready to apply changes to a component, he should be able to check it out (reserve it), which prevents others from making potentially conflicting changes to the same component at the same time. When work is complete, the developer or DBA checks the component back in, which essentially releases the reservation.

A number of commercial and freeware software products can be deployed to assist with database change management. However, it is important that you establish the process before choosing tools. In this way, the organization can establish the best process for their needs and find the tool that best fits that process rather than trying to retrofit a tool to their existing process. From the database perspective, the DBA should develop DDL statements to implement all the database components of an application system and a script that can be used to invoke all the changes, including any required conversions. This deployment script and all the DDL should be checked into the change control system and managed just like all the other software components of the system.