Export every open ticket that references an old finding ID, build a mapping from old ID to new finding using package, version and advisory, and update tickets in one controlled pass. Turn off automatic ticket creation in the new tool until the mapping is done, or you will get duplicates for work already in flight.
What breaks
Many scanners create a ticket per finding and store the finding ID in the ticket, often in a custom field or the description. The new scanner does not know those IDs. It sees a vulnerable package with no ticket and happily opens another. Engineers then get two tickets for one problem, and any automation that closes tickets when findings resolve has nothing to act on for the old ones.
Prepare before the first scan
- Pause auto creation. In the new scanner, keep ticket creation off until you finish relinking.
- Find the tickets. Query your tracker for tickets created by the old integration. Search by label, creator account or the field that holds the finding ID.
- Extract identity. From each ticket, pull the package, version and advisory ID. If that data lives only in free text, parse it with a script and check a sample by hand.
Build the mapping
For each ticket, find the matching finding in the new tool. Use the package identifier, version and advisory ID, and include aliases for the advisory because the new tool may prefer a different ID than the old one.
| Ticket state | Finding match | Action |
|---|---|---|
| Open | Found in new tool | Link ticket to new finding |
| Open | Not found | Check whether fixed or a coverage gap |
| Closed | Found, still open | Reopen or flag for review |
| Closed | Not found | Leave alone |
The third row deserves attention. A closed ticket with a still open finding means the fix did not stick, or the new scanner disagrees with the old about whether the fix was enough.
Do the relink in one pass
Run the update as a script, in batches, with a dry run first. For each ticket, add the new finding ID or link to the field you chose, and add a comment such as "Relinked to the new scanner on 19 October 2026". Keep the old ID in the ticket. It is your bridge back to historical reports.
Then turn on ticket creation, with a rule that prevents creation if a ticket already references the finding.
Watch for loops
Two way sync between tracker and scanner can fight itself during a migration: the scanner closes a ticket, the tracker reopens it. Test status sync on a single project before enabling it everywhere.
After the pass
Run a count: open tickets with a new finding link versus open findings with a ticket. Differences are either findings with no ticket yet, which is normal for new items, or tickets with no finding, which need a decision.
Quick check
Should we close old tickets and start new ones?
Usually no. Closing loses discussion history and may trigger notifications. Relink and keep the thread.
What if tickets have no finding ID in a field?
Parse the title and description for package and advisory identifiers, then verify a sample of matches by hand.
Last reviewed: 19 October 2026.
