If you are upgrading from Oracle GoldenGate Classic Architecture to Microservices Architecture and rely on complex filtering or transformation logic in your Classic data pumps, you may have to reposition that logic within components that are fully supported in the Microservices Architecture.

While Microservices does not implement every legacy pump side filtering capability in exactly the same way, you can typically achieve the same functional outcome by adjusting where that logic is applied within the replication flow. In Microservices, some basic filtering and routing capabilities are still available within Distribution Paths, but more advanced transformation logic is typically implemented elsewhere in the pipeline.

The most common and recommended approaches include:

1) Move the filtering to the source Extract (preferred when possible)

If the filter is row-based (e.g., WHERE, FILTER, TABLEEXCLUDE, COLSEXCEPT, COLS, TOKENS, etc.), push it upstream into the Extract so only the desired operations ever leave the source trail.

Why it’s best: less network + less downstream work + simplest operationally.

Tradeoff: if you used the pump to create multiple “views” of the same source trail for different targets, you may need multiple extracts or a different splitting strategy (e.g. multiple trails from same extract, Option #3).

2) Keep the Extract “wide,” and do filtering in Replicat (very common)

If the goal is “only apply subset X to target Y”, do it in Replicat using Replicat-side mapping/filtering.

Best when:

• Same captured trail needs to feed multiple targets
• You want to keep capture simple and decide “what applies” per target

Tradeoff: you ship more data than you apply, pressuring network capacity and additional storage.

3) Split/route by using multiple trails + Distribution Paths (Microservices-style “pump”)

If the Classic pump was effectively being used to:

• Split one trail into multiple trails
• Route specific tables/ops to different destinations
• Fan-out to multiple targets

…then do that with multiple trails and Distribution Paths, and attach the right Replicats to the right incoming trail(s).

Important nuance: Distribution Paths are mainly transport/routing; don’t expect them to replicate every Classic pump’s transformation features. But as a “pump replacement” for movement + fan-out, they’re the right tool.

My Field Guidance:

When you begin planning a Classic to Microservices upgrade, take time to inventory exactly what your data pumps are doing today.

In many environments, pumps have gradually accumulated years of filtering, routing, and transformation logic. While this worked well in Classic, Microservices encourages a cleaner separation of responsibilities across Extract, Distribution, and Replicat.

You may find that some of this logic must be repositioned either upstream in Extract to reduce data movement, downstream in Replicat for target-specific behavior, or implemented through multiple trails and Distribution Paths for routing.

Treat the migration as an opportunity to simplify the architecture. Designs that minimize transformation in the transport layer are typically easier to operate, scale, secure, and troubleshoot over time.