Build a mapping sheet that pairs every old project with a new project, owner and set of tags before you move any decisions. A dismissal attached to the wrong project is worse than none, because it can hide a real finding in a different codebase that happens to use the same package.
Why structure matters more than it seems
Triage decisions are scoped. "Not used" is true for one service and false for its neighbor. Scanners model scope differently: some have organizations, groups and projects, others have flat repositories with labels, others tie scope to a build target. When you move history, you move scope with it, or you move nothing safely.
What to map
| Old concept | Questions to answer | New concept |
|---|---|---|
| Organization or workspace | Single or split? | Account or tenant |
| Group or business unit | Does ownership follow it? | Team or folder |
| Project | One per repo, or one per build target? | Project or repository |
| Branch | Which branches carry history? | Default and release branches |
| Tag or label | Is it used in reports or policy? | Tag or custom property |
| Owner | Person, team or rota? | Owner or code owner entry |
The key question is granularity. If the old tool had one project per repository and the new one has one per build target, a monorepo's decisions need splitting. If it is the other way around, decisions merge, and conflicts must be resolved.
Steps
- Export the full project list with owner, tags and last scan date.
- Remove projects with no scan in the last year. Decide whether to archive them or leave them behind.
- For each remaining project, assign the new project, team and owner.
- Identify tags used in policy, reporting or access control. Those are functional, not decorative, and must exist in the new tool before cutover.
- Convert tags to the new tool's scheme and keep a table of the changes.
- Run the first import on three projects of different sizes and look for decisions that landed in the wrong place.
Ownership is not optional
Findings without owners stay open forever. Use the repository code owners file or your service catalog as the source of truth for owners, and confirm each one with the team lead. If the old tool's owner field is stale, do not import it.
Branches and versions
Decisions often depend on the version of the package, which depends on the branch. Decide which branches migrate. A common choice is the default branch and active release branches. Feature branch decisions can be dropped, since they expire when the branch does.
Check access control
If the old tool limited who could see which projects, replicate that in the new tool before importing. Triage comments can mention sensitive details about internal systems, and a broader audience than intended is an avoidable problem.
Quick check
What if the new tool has a different project model?
Write the rule for splitting or merging in the mapping sheet and test it on one project before the bulk import.
Do tags need to migrate?
Only those used in policy, reports or access control. Purely descriptive tags can be rebuilt later.
Last reviewed: 19 October 2026.
