qTest ↔ Jira: Zero‑Downtime Incremental Sync of Test Data During Live Migration

Zero-loss incremental migration with modifiedSince

The reliable pattern is parallel baseline plus continuous incremental pulls with an overlap window, plus a final catch-up verification. This avoids the export/import wizard lock while limiting exposure to clock drift and API latency.

Confirmed behavior

qTest Jira integration maps issues to requirements via a connector. Synchronization is typically polling or webhook based and the sync engine tracks modified timestamps. Zero-downtime migration is normally done by mirroring to a new environment before cutover. Field sync direction depends on mapping configuration.

Likely explanation for risk

modifiedSince is time-based, so records modified during a pull can be missed if the next window starts exactly at the previous end time. Clock drift between source, target and migration host can create gaps or duplicates. The exact inclusivity of modifiedSince is not documented here and must be verified.

Steps for this case

1. Baseline via API: Pull all artifacts with pagination, not the wizard, and write them to target. Build a source-to-target ID map for test cases, test runs, requirements and defects.
2. Continuous incremental: Run scheduled pulls using modifiedSince with a safety buffer, e.g., subtract 5 to 10 minutes from the watermark. Store the watermark per entity type.
3. Custom fields and ID translation: Export custom field definitions from source and recreate them in target with matching internal names before data sync. Translate value IDs via a lookup table during POST. Use Jira issue key as the stable anchor for requirement-defect links because Jira IDs do not change.
4. Final catch-up: After users are instructed to pause edits, run one more incremental pull with the same buffer, then compare counts per entity type and date range between source and target.
5. Verification: Count-based checksums per entity type for the migration window, plus spot sample of records with recent modified timestamps. Review Sync History logs for failures.

Assumptions and uncertainty

This assumes administrative API access to both instances and that modified timestamps are updated on write only. Verification of modifiedSince inclusivity and clock sync is required for production use.

One diagnostic detail that changes the recommendation: does your migration tool support stateful per-entity watermarks and idempotent upserts, or is it a stateless script? Stateful tracking allows safe buffer reuse; stateless scripts need a wider overlap and manual reconciliation.