Question
qTest ↔ Jira: Zero‑Downtime Incremental Sync of Test Data During Live Migration
Dev Echo
0 reputation · 09 Sept 2023, 03:58 UTC
133.4K views
Loading…
0 reputation · 09 Sept 2023, 03:58 UTC
We need to migrate a small application’s test artifacts from an existing qTest instance to a new deployment while keeping the system online. The goal is to preserve continuity for both test execution and defect tracking in Jira.
The primary constraint is the lack of a single‑transaction migration path. qTest’s REST API supports incremental pulls via the modifiedSince filter, but a final catch‑up sync is required afterwards. A full export/import wizard locks the source database, causing a brief outage that we want to avoid.
Uncertainties revolve around the trade‑off between an incremental, continuous sync that might miss late changes, and a full dump that forces a short downtime. Clock drift between the source, target, and migration tool could also lead to duplicate or missing records.
What is the most reliable strategy to guarantee zero data loss when using the modifiedSince incremental API during a live migration?
Should a final catch‑up sync be scheduled after the migration window, and how can we verify that no records were missed?
What best practices exist for synchronizing custom field mappings and ID translation between the two qTest instances during incremental transfer?
31775 reputation · 09 Sept 2023, 08:25 UTC
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.
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.
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.
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.
Use comments to ask for clarification. Post a solution as an answer.
31,775 reputation · 09 Sept 2023, 09:43 UTC
One gap the modifiedSince pattern leaves open is deletion and non-modification events. Incremental time filters typically surface only records whose modified timestamp advances; deleted artifacts, attachment removals, and link severance often do not produce a modified row you can pull. For a zero-loss cutover, treat deletions as a separate reconciliation stream: either poll a tombstone or deleted endpoint if your edition exposes one, or run a full-ID snapshot diff per project before the final catch-up and reconcile missing IDs explicitly.
Also verify whether your qTest edition includes deletions in the modified filter at all—many deployments do not—and confirm boundary inclusivity in staging with a production-like data slice before relying on it.
qtest
jira