Question

Difficulty: Very hardManaging Technology Debt and Legacy Cloud Migrations

A financial services firm is migrating a mission-critical legacy transactional backend to Google Cloud over a 6-month phased rollout. The on-premises environment consists of a 40 TB relational database with high transaction volume, where legacy monolithic services and modernized cloud-native microservices must run concurrently against the data layer. Business requirements mandate zero downtime during application cutovers and continuous backward compatibility as database schemas evolve. Which strategy should the Cloud Architect recommend to manage database technology debt while ensuring continuous availability during the migration?

  1. Implement continuous Change Data Capture (CDC) from the on-premises database to Cloud SQL for PostgreSQL, and mandate an expand-contract database schema modification strategy so schema changes remain backward-compatible across active application versions.Answer
  2. B
    Execute destructive DDL schema updates directly on the cloud database immediately before each application deployment, relying on blue-green traffic routing to isolate legacy application service failures.
  3. C
    Migrate the database directly to Cloud Spanner to automatically handle legacy database schema evolutionary debt through its global distributed transaction architecture.
  4. D
    Ship a Google Cloud Transfer Appliance monthly to bulk-import snapshot updates into Cloud SQL, decoupling database migration traffic from network bandwidth until final cutover.

Answer

Implement continuous Change Data Capture (CDC) from on-premises to Cloud SQL for PostgreSQL, paired with an expand-contract (decoupled) database schema migration strategy.
The correct strategy combines continuous online replication via Change Data Capture (CDC) with an expand-contract database migration design pattern. CDC maintains active data sync between on-premises and Cloud SQL environments during phased migration. The expand-contract pattern introduces non-breaking additive schema changes (expand) first, allowing legacy monolithic components and modernized cloud microservices to operate concurrently on shared data structures until legacy code is retired and old columns can be safely dropped (contract).

Step-by-Step Solution

1
Analyze continuous data replication requirements for phased migration.
Identify that live transaction synchronization requires an online Change Data Capture (CDC) engine to keep on-premises and Cloud SQL instances tightly synchronized.
Batch imports or offline transfers cannot support zero-downtime cutovers or concurrent multi-month parallel operations.
2
Evaluate database schema refactoring techniques for active migration environments.
Adopt the expand-contract (parallel change) pattern where database schema modifications are executed in additive phases (expand) before legacy code dependencies are decommissioned (contract).
This guarantees that both legacy monolithic components and modernized microservices can safely query the database simultaneously without breaking changes.

Key Concept

Legacy Database Modernization and Schema Evolution Management during Phased Migration
Rate this question