Database Migration

With over 400+ databases already migrated and moved to the cloud, we are your team to get the job done right.

Modernize your Databases

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.

Modernize Your Databases

Thanks! We'll contact you soon.


Database Migration Case Studies

Database Modernization to AWS
Case Study: Acoustic

Acoustic's Journey from IBM DB2 to AWS Redshift

Our customer's journey to an all-in adoption of cloud database computing.

Case Study: Canadian Financial Institution

Modernizing ETL business process from Informatica to AWS Glue

Our customer's journey out of expensvive Informatica ETL software and onto AWS Glue and other AWS Services.

Database Migration to AWS
Infra as Code Automation
Case Study: Acoustic

Automate the creation of a DB2 HADR Cluster in AWS

Hear how we tackled migrating over 300 DB2 servers to AWS with infrastructure as code automation scripts.

Case Study: Acoustic

Acoustic's DB2 Database Journey to AWS

Hear how we lift & shifted over 300 DB2 database systems to AWS in 8 months.

Database Modernization to AWS
Case Study: Acoustic

Acoustic's journey from DB2 DB to Aurora PostgreSQL

Hear our customer's database modernizastion journey to AWS Aurora PostgreSQL and other AWS Services.

"Data driven organizations are 19X more likely to be profitiable"

- McKinsey & Company

Modernization to GCP
Case Study: Canadian Financial Institution

Modernizing On-premise Hadoop to GCP

A technical guide on what GCP services to pick and why

Case Study: Travel Bidding Website

Oracle Migration to GCP CLoudSQL

Our strategy on how we moved Travel Bidding Website's Oracle data systems to GCP CloudSQL using Striim