T 2.110 Inadequate organisation of release changes and migration of databases

All organisational steps to take before and while changing the version of the database management system (DBMS) or while migrating a database are recorded in migration and version concepts. The lack of such concepts can significantly impair the ability of the organisation to fulfil its duties if problems arise during a database migration or a DBMS upgrade and the DBMS or individual databases unexpectedly become unavailable.

If no secure rollback positions are set when planning the physical and semantic data migration, then the ability of users and applications to use the database or the DBMS may be threatened.

When upgrading to a new version of a DBMS, the databases stored in the DBMS remain unchanged. Security problems are less likely to arise in this case in the database itself, but may arise due to the interaction of the databases with the new DBMS.

Examples:

• Due to a database upgrade, the basic type definitions were changed.
• Access authorizations for the default user groups provided by the DBMS are changed and therefore affect the rights of the user groups based on the default groups.

When migrating the data, the data is copied from one database to another database. When this is done, the data is converted in many ways and transferred to new database structures, possibly even to a completely different DBMS. In this case, it must be ensured that databases are able to use different constructions (triggers, constraints, etc.) to ensure the consistency of the data. The order of the data and the dependencies between the data are implemented using such constructions, and these constructions must be taken into account and correspondingly implemented on the other system when migrating data. The analysis and reimplementation of all constraints to be fulfilled can become very complex and extensive. This increases the risk of introducing errors that endanger the consistency of the data and the functionality of the system after the migration.

Examples:

• When migrating a database from Microsoft Access to the Microsoft SQL Server, special attention must be given to all columns of type AutoNumber in Access since this type is implemented in different ways in different DBMSs.
• In the database to be migrated, there are two tables named EMPLOYEES and COMPANY. To ensure that new employees can only be assigned to existing companies, the EMPLOYEES table is assigned an UPDATE/INSERT trigger that checks whenever new entries are added and/or changes are made to the EMPLOYEES table if there is an entry for the corresponding company in the COMPANY table.

If there is no corresponding entry in the COMPANY table, then the UPDATE or INSERT statement is cancelled. The order of implementation of the tables in this DB (colloquially: "The company first, then the employees") must be taken into account when migrating the database. If the EMPLOYEES table is transferred before the COMPANY table in the course of the migration, then the insertion will be rejected because there are no corresponding entries in the COMPANY table yet.