Database change management comprises methods and practices needed to move a system from one database to another. Databases are common in many modern businesses; they contain all the relevant information about the business’s products, employees and customers. The cornerstone of effective database change management is proactive thinking. It is as important to get systems set up in advance of the change as to anticipate the user's response and activities on the new system.
The first step in any database change management decision involves the database itself. Many companies are moving away from standard databases to virtual systems and off-site locations. These have several advantages over traditional databases systems. In most cases, they are accessible anywhere with little effort on the employee’s part. In addition, they are fully backed up regularly, and the offsite company will typically handle future migrations, changes and updates.
The biggest drawback to these systems is security. While in most cases these newer database forms are just as secure as a standard database, there is no way of knowing for sure. When the database is kept in-house, any problems with the system are reported immediately.
The next phase of database change management is preparation. During this period, the information from the old database is moved into the new one. Plans are set up for copying and migrating information that is added to the database after this point. Workers may use a temporary database to keep new information separate from old, or a script is set up to automatically copy new information into both systems. This is considered a dangerous time, as information generated during this period is easy to lose or delete by mistake.
One of the key points at this time is usability. It is important that people actually try and use the new database to work out any problems or kinks it might have. It is typically significantly easier for a few workers to test the system than it is to make a few hundred employees work on an untested database.
The last part of database change management is the actual change over. At some point, the entire workforce needs to move over to the new system. This will immediately generate more problems and feedback. Regardless of how well a system is tested, actually letting users operate it will lead to the discovery of more problems and bugs.
If the transition generates so many problems that productivity goes way down, it is always possible to move users back to the old database. This will give time to fix the problems in the new system. This is a less-than-optimal choice because it prolongs the period of two databases, but it's an option.
