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 (lift and shift with ongoing replication) approach aims for minimal impact on database performance and users of the business applications. This approach continuously replicates inserts, updates, and deletes from the source to the target for months, or even years, while you optimize and test the business applications for the new cloud-based database.
In an online 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, you might need the original database instance to continue to run while downstream processing occurs in the cloud. In this case, the source database is replicated in the cloud indefinitely. For example, you might have an application that accesses a database that depends on technology that cannot be moved to the cloud. 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 the cloud.
In these use cases, the original database must be continuously replicated to the target indefinitely. The source database is not shut down as it is with a database migration.
Online database migration and replication 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 StreamShift (for lift-and-shift or online migration) or Striim (for continuous replication).
Portions of this introduction are licensed from Google under the Creative Commons Attribution 4.0 License. Minor changes have been made from the original.