Decide how each old application maps to a project in the new monorepo before you cut over, then carry over its SBOM history, suppressions and owner. If your security tooling keys records by repository name, a move makes the old history look like a different product. Write the mapping down and test one service first.
What is at risk
Security records tend to hang off an identifier: a repository URL, a project name, a component name. Change the identifier and three things can break at once.
- Trend and history. Reports that show findings over time start from zero, which looks like a miracle or a gap.
- Suppressions and accepted risks. A suppression keyed to the old repo no longer applies, so findings you triaged return as new. Our note on what to do with old scanner history covers a similar loss.
- Ownership. An owner set on the old project is not set on the new one, so alerts go nowhere. See build an alert ownership map.
Customers and auditors ask about a product's history, not your repository layout, so continuity is also an evidence question.
Make an identity map
| Old identifier | New identifier | Owner | Records to carry |
|---|---|---|---|
| payments repo | services/payments in platform repo | Payments team | SBOMs, suppressions, VEX |
| search repo | services/search in platform repo | Search team | SBOMs, suppressions |
Keep a stable product or application name that does not change when the code moves. Then the repo is an attribute, not the identity.
Steps
- Export what you have from the current tooling: component inventory, open findings, suppressions with reasons and dates, owners, and any VEX statements.
- Create one project per deployable service in the new setup, named after the product, not the directory.
- Import or recreate suppressions with their original reason and date. Add a note that they were carried over on the migration date.
- Run the first scan in parallel with the old one and compare findings. Differences need explanations, as in check scan coverage before and after a monorepo migration.
- Archive the old exports with the migration record.
- Retire the old projects only after a full release cycle.
Per-service reports from a single repo
A monorepo can still produce a separate SBOM per service. The trade is covered in one SBOM or many for a monorepo, and the fields to include are in per-package scan report fields for a monorepo.
Do not rewrite the past
Carried-over records should say what they were. If a finding was accepted on a certain date under the old project, keep that date. Rewriting dates to look continuous is misleading, and it will not hold up when someone asks for the original.
Safeguard's SBOM and dependency scanning, compliance and evidence automation, and asset discovery can help you keep inventory and evidence tied to the application rather than to a repo name.
Quick check
Should the project be named after the repo?
Better to name it after the product or service, so a repo move does not change its identity.
Do I need to move old findings?
Carry over open findings, suppressions with reasons, and owners. Archive the rest as exports.
Last reviewed: 19 October 2026.
