Solution Overview — Summary
Every database migration eventually reaches the same question: how do you know the new system behaves the same as the old one? Most projects answer it with a manual test pass against a fraction of the real workload, and find out the answer was incomplete during cutover weekend, or worse, after it.
DBReplay answers it with evidence instead. It captures the real production workload, replays it against the migrated target, and compares the actual results and performance — statement by statement, row by row — producing a signed report the migration decision can rest on.
The business case
| Outcome | How DBReplay delivers it |
|---|---|
| A defensible go/no-go for cutover | A statement-level report of what matched, what didn't, and why — not a sample, the captured workload. |
| No live-source security review to pass | DBReplay works entirely from artefacts your team produces. There is no live credential and no live connection to the source system for a security review to stall on. |
| Performance risk surfaced before cutover, not after | The same replay produces a statement-by-statement timing comparison, ranked by the total time that actually matters in production — not by which single query looks worst. |
| A clean split of responsibility | DBReplay asserts technical soundness and reports it in full. Acceptance stays a business decision, made with the evidence in hand rather than instead of it. |
| Reusable across the migration, not a one-off | Every successful run is comparable against the last one — the same capture, a different target configuration, becomes a sizing instrument as well as a proof. |
What it removes from the risk register
- “We won't really know if the migration worked until real traffic hits it.”
- “Security won't approve a tool that connects to the mainframe directly.”
- “We tested the queries we thought of, not the ones production actually runs.”
- “Nobody can tell us whether the new system will be faster or slower until it's already live.”
Why Oninit
DBReplay is built and delivered by the same Oninit engineering team behind DBVoyeur, Oninit’s SQL-level performance monitor, and two decades of supporting the global Informix community as “the Down System Specialists.” The protocol decoders, the operational discipline around capture, and the read on what actually goes wrong in a live database estate all carry over directly into proving a migration.
Time to value
| Step | Typical effort |
|---|---|
| Trial capture — a plain packet capture, no DBReplay software involved | This week. No security approval needed beyond a standard capture request. |
| Scoping call and capture-point confirmation | Days. |
| Deploy capture, confirm keep-up rate and coverage | Days to a couple of weeks, depending on capture topology. |
| Pre-process review and coverage report | The customer's first look at translated vs. untranslated SQL, before any replay runs. |
| First full replay-and-compare run | Depends on catalog extract and target provisioning — typically the long pole, and outside DBReplay's own control. |
Next step
A short scoping call to understand the migration in question — source and target engines, expected volume, and any constraints on capturing traffic. The trial capture, a plain packet capture with no DBReplay software involved, can usually happen the same week. Call +1 913 732 8892 (US) or +44 20 8133 7529 (UK), or email support.info@oninit.com.