Database Migration Downtime

After database migration is succeeded, you then switch client access over to the target database and delete the source. Transitioning users from the source databases to the target databases includes the following steps:

Once the connections to the source databases are closed, it is essential to migrate any remaining changes from the source databases to the target. This ensures that all modifications and updates are captured and replicated in the target databases. Change Data Capture techniques may be used for this purpose.

In order to proceed with the data flow, clients need to terminate their existing connections to the source databases and establish new connections to the target databases. It is preferable to close these connections, ensuring that ongoing transactions are not rolled back.

Testing the target databases is necessary to verify their functionality and to ensure that clients can operate within their defined service level objectives. This testing phase helps confirm that both the target databases and the clients are operating as expected and meeting their performance and availability requirements.

Truly zero downtime is not possible for real database migration projects. However, there are few best practices to aim near-zero downtime of the source database.

As the switch-over period approaches, it is possible to minimize the volume of migrated data between the source and target DBMS by split into multiple sessions or simultaneous threads. By configuring the volume of single "chunk" to be as small as possible, the time required for draining is reduced. This approach is effective because it decreases the differences between the source and target databases, allowing for a more efficient and streamlined migration process.

Another effective strategy to minimize downtime during the database migration process is to initiate test clients in read-only mode against the target databases well in advance of the actual client switch-over. By adopting this approach, testing can be conducted concurrently with the database migration. This allows for thorough evaluation and validation of the target databases' performance, ensuring their readiness before the clients are transitioned.

Some database migration projects are tolerant to significant downtime. In such cases, there is no need to spend more efforts in reducing downtime of the source database. Thus, in homogeneous database migrations without data modification, export/import or backup/restore techniques can be used effectively. Similarly, when heterogeneous database migration does not need to handle updates of the source database, this allows simplified and efficient migration, considering the specific characteristics of the databases involved.

It is extremely important to ensure that the acceptable downtime is long enough for the database migration and required testing. If the required downtime cannot be established, database migration must be re-designed to involve minimal downtime.

Have questions? Contact us