Oracle to PostgreSQL Migration with Change Data Capture

An anonymized migration using Debezium, Kafka and a synchronization service to support staged application migration from Oracle to PostgreSQL.

[Overview] The migration decision

This anonymized Ampity engagement involved an insurance application moving from Oracle to PostgreSQL. The migration design used Debezium for change data capture, Kafka for streaming and a synchronization service to apply changes to the target database.

The objective was to stage the migration while the application remained in use. This case retains that technical scope without asserting measured downtime, data loss, licensing savings or regulatory approval.

[Context] Business logic was part of the migration

Stored procedures, triggers and Oracle-specific types carried application behavior. The work therefore involved more than moving tables. The target had to support the business logic and the application paths that depended on it.

An incremental approach separated smaller migration decisions instead of making the whole application depend on a single cutover. The case does not use the original narrative's scale, cost or project-duration figures as independently established facts.

[Design] Change propagation and application routing

Oracle changes passed through Debezium and Kafka before being applied to PostgreSQL. Reads shifted toward PostgreSQL progressively while writes initially continued to Oracle. The migration plan also included a later write cutover and reverse synchronization.

This design is not a guarantee of replication latency or lossless operation. The deployment-level connector configuration, supported object inventory, conflict rules and reverse-path validation are outside this case's scope. They must be established before reusing the approach as a failback procedure.

[Approach] Smaller migration waves

The work was organized around groups of application data and behavior: reference data, read-heavy transaction paths, write-heavy tables and remaining dependencies. The described sequence combined schema changes, synchronization, read routing, validation and write migration.

Validation needs to follow the application responsibility being moved. A target that can serve reference reads has not thereby been shown ready to accept transactional writes. Similarly, a successful change stream does not establish equivalent actuarial or policy-processing behavior.

[Boundaries] What a reversible cutover requires

For a similar implementation, record the authoritative writer, the replication position and the application's supported routing state at each transition. Define how missing events, unsupported changes and delayed consumers are detected and reconciled. Keep business-result comparisons separate from transport health.

Before offering failback, establish how writes accepted by PostgreSQL would be represented in Oracle, which application version can use that state, and what conditions require stopping rather than routing back. These are implementation review questions. This case does not assert that rollback was always available or instantaneous.

[Results] Technical scope, not a financial claim

The account describes CDC-based change propagation, compatibility work and staged application cutover. It does not include the contracts, infrastructure ledger or observation records needed for a licensing-savings or query-performance comparison. No numerical improvement or auditor endorsement is published here.

[Applicability] Conditions that change the decision

CDC can support staged migration when the required source changes can be captured and the target can apply them with the needed semantics. It is not sufficient on its own. Schema changes, log retention, type conversion, transaction ordering, application dependencies and the ability to reconcile discrepancies can change the migration design.

Choose the migration unit and cutover conditions from the workload. Do not infer zero downtime from the presence of CDC, Kafka or a parallel database.