Solution Overview — For Architects

You are the person who has to decide where this component sits, what it touches, and what it is allowed to fail into. The questions below are the ones DBReplay is designed to make easy to answer.

Deployment model

Question	DBReplay answer
Does it connect to the live source system?	No. Everything derives from artefacts your team produces — a capture file and a catalog extract. There is no live credential and nothing to authorise beyond the capture step itself.
Where does capture sit?	Wherever the packets actually are — a network tap, or client-side where the traffic never reaches an external wire (data-sharing members over HiperSockets, for example). See Capture Topology.
Where does replay sit?	Next to the target — same VPC and availability zone as the RDS instance or self-managed target. Capture and replay are never the same location; the artefact moves between them.
What is the failure mode?	Capture is passive and never in the source's request path; if it stops, the source keeps working and the only consequence is a gap in the artefact. Replay runs against a disposable target environment, not production.
What is the security boundary?	The capture role needs raw-socket/BPF capability on the source side and no target credentials. The replay role needs target credentials and no source access. Same container image, different privileges and secrets per deployment — the capture role is never handed anything the replay role needs.
How does credential handling work?	Replay credentials come from a secret store, never from the capture artefact itself — even where the capture method can see an authentication exchange on the wire.

Coverage model

Engine coverage is gated by wire decoders, not by the comparison or reporting layer. Db2 LUW and Db2 z/OS DDF share the same wire protocol (DRDA), so the decoder work for one extends directly to the other. Other DRDA-speaking engines — Db2 for i, Informix's DRDA listener — follow the same pattern. Adding a new target is comparatively inexpensive: it needs a driver and an emitter, not a new decoder.

What DBReplay proves, and what it doesn't

In scope, computable, and asserted	Out of scope, stated as a customer decision
The captured workload replays on the target and produces the same result set, row for row.	Whether the captured window is representative of the workload that matters — that's a judgement about your traffic, not something derivable from the capture alone.
Zero unhandled SQL — every statement has a mapping or an explicit, justified disposition.	Whether the migrated stored procedures themselves are semantically equivalent — their migration is an input to this exercise.
Capture integrity — drop and desync counters, asserted as a precondition on the report, not buried in an appendix.	The physical design of the target database.
A statement-level performance comparison, with round-trip overhead separated from engine-side timing.	Whether the results constitute an acceptable migration — that verdict is yours.

Risk register impact

Risk	Before	With DBReplay
Live-source security review stalling the project	A migration tool wanting a live connection to the source mainframe or database is often the single hardest approval to get.	No live connection at all. The capture step is a standard, well-understood approval — a packet capture or a documented trace facility.
Cutover decided on an unrepresentative sample	Manual test scripts covering a fraction of production SQL.	The full captured workload, classified and compared statement by statement.
Performance regression discovered after go-live	No pre-cutover comparison at production scale and concurrency.	Replay reproduces captured order and concurrency; a target that falls behind is detected as schedule lag before cutover, not after.

Next step

A scoping call to map DBReplay onto the source and target topology in question, followed by a trial capture — a plain packet capture, no DBReplay software involved — to confirm the capture point can keep up. Email support.info@oninit.com.