Striim Migration Service for Google Cloud Documentation

Understanding database migration and replication

At a high level, the three approaches to moving a database to the cloud are lift-and-shift migration, online migration, and continuous replication.

In a lift-and-shift migration, you typically export or back up a source database, move the exported or backup file to the cloud, and then import and restore the file to a target database instance running in the cloud. When the new target database is ready, business applications run in the cloud and access data.

A downside to the lift-and-shift approach is that it requires downtime for both the business applications and database. This approach requires careful planning to migrate during low-activity periods. This approach also assumes that you can stop the business applications during the migration and restart them after the database is restored in the cloud. Any testing of the applications after the database is restored adds to the downtime. Furthermore, the lift-and-shift approach creates an intermediate copy of the database that needs to be secured, moved, stored, and eventually deleted. This aspect adds cost and management complexity. While the lift-and-shift approach might work for certain applications, the requirements of most business-critical applications do not tolerate these costs. For these reasons, an online database migration is a far better approach.

The online migration approach aims for minimal impact on database performance and users of the business applications. The online approach lets you continuously migrate your databases to the cloud, keeping both the source and target databases fully synchronized for months, or even years, while you optimize and test the business applications for the new cloud-based database.

In a database migration to the cloud, the source database is retired when the migration is complete because the cloud database is now the production instance.

In some use cases, the original database instance might continue to run while downstream processing occurs on Google Cloud. In this case, the source database is replicated in Google Cloud. For example, you might have an application that accesses a database that depends on technology that cannot be moved to Google Cloud. At the same time, Google Cloud technology is used for functionality like analysis—for example, replicating to BigQuery. Another example is where a database that contains personally identifiable information (PII) must reside in an on-premises environment while downstream processing that uses obfuscated PII occurs in Google Cloud.

In these use cases, the original database must be continuously replicated to the operational or analytical target, such as Spanner or BigQuery. The source database is not shut down as it is with a database migration.

Online database migration and replications for heterogeneous databases are typically complex, involving months or even years of hand coding and integrating various services. A more modern and efficient approach to online database migrations is the use of database migration and integration systems such as Striim.

For a more detailed overview, see Architecting database migration and replication using Striim.

Portions of this introduction are licensed from Google under the Creative Commons Attribution 4.0 License. Minor changes have been made from the original.