To move vulnerability tracking into an ASPM platform, clean your open tickets, map statuses and owners, import only open items, run old and new in parallel for a short period, then retire the old process on a set date. Keep the old data as a read only archive.
Why migrations go wrong
Teams often import everything, including years of closed tickets, duplicate entries and unclear owners. The new system then looks as cluttered as the old one, and trust drops before the benefits arrive.
Treat the migration as a clean up with a new home, not a copy.
The plan in six steps
- Freeze and export. Pick a date. Export all vulnerability tickets with fields for ID, title, status, owner, created date, closed date and links.
- Clean. Remove duplicates, close items that no longer apply, and add an owner to anything open without one.
- Map. Decide how old statuses translate to new ones before importing.
- Import open items only. Closed items go to the archive.
- Run in parallel. For two to four weeks, new work goes to the platform, and old tickets are only updated, not created.
- Cut over. Announce the date, make the old project read only, and link to the archive.
A status mapping example
| Old status | New status |
|---|---|
| Open, Backlog | Open |
| In progress, In review | In progress |
| Won't fix, Accepted | Accepted risk with end date |
| Done, Closed | Fixed, only if verified |
| Duplicate | Merged |
The "accepted risk" row deserves attention. In old trackers, "won't fix" often means "we gave up." In the new system, it should carry a reason and a review date.
What to verify after import
- Count open items before and after. Explain every difference.
- Spot check twenty records for correct owner and links.
- Confirm that ticket links in pull requests still resolve.
- Check that nobody lost access to something they need.
Keep the history reachable
An auditor or customer may ask about a fix from last year. Keep the exported archive in a controlled location, with a short note on how to search it. Do not delete the original tracker project until the retention period you follow has passed. If you are unsure about the length, ask your compliance owner.
Communicating the change
Tell developers three things: where to look now, what has not changed about how they work, and who to ask for help. Many migrations succeed technically and fail socially because people kept using the old board out of habit.
A worked example of a clean up
Imagine an issue tracker with 600 vulnerability tickets. The numbers are illustrative.
| Group | Count | Decision |
|---|---|---|
| Closed as fixed | 320 | Archive |
| Closed as won't fix | 60 | Review, convert to accepted risk with date where still relevant |
| Open, valid | 110 | Import |
| Open, stale or duplicate | 90 | Close with a reason, archive |
| Open, no owner | 20 | Assign before import |
After clean up, 130 items are imported rather than 600. The new system starts with a list people recognize as real, which is the most important condition for adoption.
Step by step: the weekend before cutover
- Confirm the final export of the old system and store a copy in the archive location.
- Run the status mapping and check a sample of twenty records.
- Import in a test space first and look for errors.
- Import into the live space.
- Check counts: items exported, items imported, items deliberately excluded. All three must add up.
- Announce the cutover with a short note: where to look, what changes, who to ask.
Integrating with the tracker you keep
Many teams keep their general issue tracker for day to day work and use the platform as the system of record for findings. If so, decide which direction is authoritative for status. A common choice is that the platform creates tickets and listens for status changes, while the tracker is where developers work. Test a full lifecycle, from creation to closure, before cutover.
Training and support
Hold a short session with developers and answer three questions: what is different, what do I need to do, and where do I get help. Record it so new hires can watch it later. For two weeks after cutover, keep a channel open for questions and note recurring ones. Turn them into a short guide.
Review after thirty days
Look at the new system with fresh eyes. Are people using it? Are owners correct? Are exceptions dated? Are statuses consistent? Use the answers to adjust process, not to blame people. Migrations succeed when the first month teaches you something and you act on it.
Rollback plan
Agree in advance what would make you pause the migration. Examples are a failed import that loses owners, a ticket sync that creates duplicates, or a loss of access for a team that needs it. Keep the old tracker project writable but hidden for the first two weeks, so you can switch back without losing the work done. After that window, make it read only. Having a rollback plan rarely gets used, but it lowers the stress of cutover and makes it easier to get agreement from nervous stakeholders.
Where Safeguard fits
Safeguard provides asset discovery, SBOM and dependency scanning, and compliance and evidence automation, which can serve as the new record while your tracker remains the place engineers do their work. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Think about how your current statuses would map.
Quick check
Should closed tickets be imported?
Usually not. Keep them in an archive and import only open items.
How long should we run both systems?
Two to four weeks is typical, with a fixed cutover date announced in advance.
What if we find thousands of old tickets with missing data?
Archive them and import only what is open and valid. Trying to repair years of poor data usually delays the benefits without improving decisions.
Last reviewed: 19 October 2026.
