Database Migration

Engage Our Team

Database migration is the process of migrating data from one or more source databases to one or more target databases. When a migration is finished, the dataset in the source databases resides fully, though possibly restructured, in the target databases. Applications and clients that access the source databases are then switched over to the target databases, and the source databases are turned down.

Extensive Database Migration Experience

There are numerous types of database migrations and just as many methods to accomplish the goal. Each database migration needs to work within the limits of the application, limits of the databases involved, client budget and timeline.

Heterogeneous Database Migrations
Heterogeneous database migration is a migration between source and target databases of different database technologies, for example, from an Oracle database to Spanner. Heterogeneous database migration can be between the same data models (for example, from relational to relational), or between different data models (for example, from relational to key-value). As organizations are moving to the cloud, there is a large demand to migrate from proprietary database systems which require high license fees and a technical team to manage them. To cloud managed database services, which often run open source data systems and have many database tasks managed by the cloud platform. Heterogeneous database migrations are the most common type of migration we see today.

Oracle® to MySQL/PostgreSQL
Oracle® to MySQL/PostgreSQL
Oracle® /MySQL/PostgreSQL to BigTable/DynamoDB
DB2 to MySQL/PostgreSQL
MS SQL to MySQL/PostgreSQL
DB2 Warehouse to Redshift/BigQuery
OLTP DB to Cassandra/MongoDB

Homogenous Database Migrations
A homogenous database migration is a migration between the source and target databases of the same database technology, for example, migrating from a MySQL database to a MySQL database, or from an Oracle® database to an Oracle® database. Homogenous migrations also include migrations between a self-hosted database system such as PostgreSQL to a managed version of it such as Cloud SQL PostgreSQL or Aurora PostgreSQL. In a homogenous database migration, the schemas for the source and target databases are likely identical. If the schemas are different, the data from the source databases must be transformed during migration.

Online Migration vs Offline Migration The migration strategy is largely determined by application downtime. In a migration, achieving truly zero downtime for clients is impossible. There are times when clients cannot process requests. However, you can minimize the duration that clients are unable to process requests in several ways.

You can start your test clients in read-only mode against the target databases long before you switch the clients over. With this approach, testing is concurrent with the migration.
You can configure the amount of data being migrated (that is, in flight between the source and target databases) to be as small as possible when the switch over period approaches. This step reduces the time for draining because there are fewer differences between the source databases and the target databases.
If new clients operating on the target databases can be started concurrently with existing clients operating on the source databases, you can shorten the switch over time because the new clients are ready to execute as soon as all data is drained.

In some database migration scenarios, significant downtime is acceptable. Typically, this allowance is a result of business requirements. In such cases, you can simplify your approach. For example, with a homogenous database migration, you might not require data modification; export/import or backup/restore are perfect approaches. With heterogeneous migrations, the database migration system does not have to deal with updates of source database systems during the migration. However, you need to establish that the acceptable downtime is long enough for the database migration and follow-up testing to occur. If this downtime cannot be clearly established or is unacceptably long, you need to plan a migration that involves minimal downtime.