AtrekesLibHFTDocumentationQuickFIX migration

Migration

Keep the dictionary. Prove the change.

LibHFT accepts QuickFIX-format XML dictionaries and provides an assessment path for QuickFIX/C++, QuickFIX/J and QuickFIX/n settings. Migration still requires behavioral evidence—not a compatibility badge.

Dictionary reuseSettings assessmentReplay before cutover

Reusable assets

Start with what is genuinely portable.

DICTIONARIES

QuickFIX XML

Reuse standard or counterparty-specific field, message and repeating-group definitions after validation.

SESSION IDENTITY

Roles and CompIDs

Map initiator/acceptor identity, endpoints, credentials and schedule policy without copying secrets into reports.

RECOVERY POLICY

Stores and resend

Translate persistence, reset, replay, gap-fill and reconnect intent into LibHFT’s explicit model.

APPLICATION CONTRACT

Messages and callbacks

Port builders, field access and lifecycle hooks against the chosen LibHFT flavor.

Settings assessment

Classify every setting before translating it.

ClassActionExamples
DirectMap to an equivalent LibHFT setting and preserve the value.Session identity, heartbeat interval, endpoint, role.
Semantic translationMap the operational intent, then verify behavior.Reset policy, resend bounds, schedules, validation flags.
Application-ownedMove behavior to application hooks or deployment logic.Custom authentication, business validation, lifecycle orchestration.
Unsupported or obsoleteRecord the gap; do not silently discard it.Engine-specific plugins or settings with no safe equivalent.
SensitiveRedact values while retaining the fact that configuration exists.Passwords, tokens, keys and credential-shaped custom settings.

Migration route

Move through evidence gates.

  1. Inventory configuration, dictionaries, custom fields, callbacks, stores and operational procedures.
  2. Run the settings and dictionary assessment for the source QuickFIX family.
  3. Select the LibHFT flavor and transport boundary the application will deploy.
  4. Port source APIs or introduce an adapter while preserving application semantics.
  5. Replay captured and adversarial FIX traffic through both paths.
  6. Run session, validation, recovery and store conformance scenarios.
  7. Benchmark the target workload only after functional parity passes.
  8. Run a shadow or certification environment before production cutover.

Deterministic oracle

Compare outcomes, not implementation details.

A migration oracle should compare normalized application messages, session events, sequence transitions, rejects, resend responses and durable-store outcomes. It should deliberately mutate relevant business fields so a superficially compatible adapter cannot pass by ignoring work.

Readiness is broader than a successful Logon.

Prove reconnect, high and low sequences, resend ranges, gap fills, invalid messages, durable-write refusal, session schedules and operational telemetry before treating the port as ready.

Source families

QuickFIX/C++, QuickFIX/J and QuickFIX/n.

The assessment recognizes that these implementations share concepts but not a perfectly interchangeable settings surface. Runtime ownership, store behavior, callback APIs and scheduling details must be interpreted in the source family’s terms.

QuickFIX/C++ ↗ · QuickFIX/J ↗ · QuickFIX/n ↗