Migrate in seven steps: inventory what the sheet holds, clean the identifiers, regenerate SBOMs from source where you can, import, verify counts, run both in parallel for a release cycle, then retire the sheet as read only. Regenerating beats converting rows whenever the source is available.
Step 1: inventory the sheet
List every tab, product, release and column. Mark which rows came from a generator and which were typed by a person. Typed rows are the risk, because they may hold knowledge that exists nowhere else, such as a manual license decision.
Step 2: clean the identifiers
A package URL for each component makes matching dependable. Where the sheet has only names and versions, add the ecosystem and build the identifier. Flag rows where you cannot, rather than guessing. The post on which identifier an SBOM should use helps with the choice.
Step 3: regenerate where you can
For current and recent releases, regenerate the SBOM from source, lockfiles or images using your generator in the build. This is more accurate than converting rows. See how to generate an SBOM for npm, Python and Maven projects for starting points. Reserve conversion for old releases where the source is gone.
Step 4: carry over human knowledge
Collect notes people added to the sheet: license decisions, not affected rationales, supplier contacts, approved exceptions. Move them as annotations on components, with author and date. Do not paste them into a single comment field where they will be lost.
Step 5: import and verify
Import a pilot set of two or three products. Check:
| Check | Method |
|---|---|
| Component counts | Sheet or source file versus platform |
| Relationships | Spot check twenty components |
| Licenses | Compare for a sample |
| Status values | Map your old vocabulary to the new one |
| Releases | Each release is its own record |
Fix mapping issues before importing everything.
Step 6: run in parallel
For one release cycle, keep updating both. Answer real questions from the platform and compare with the sheet. Differences are either platform errors you need to report or sheet errors you can now stop making. Set a date for the end of parallel running so it does not drag on.
Step 7: cut over and archive
On the cutover date, make the sheet read only, rename it with the date, and store it with the migration notes. Do not delete it. It is your fallback and a historical record. Update the runbook: where SBOMs live, who uploads, who approves, how to export. Review roles as described in which roles an SBOM platform needs.
Mistakes to avoid
- Migrating everything at once. Pilot first.
- Importing stale data and treating it as current. Mark the original timestamp.
- Skipping the exit test. Confirm you can export before you commit, as in the round trip test.
- Forgetting the people. Teach the readers how to find what they used to read in the sheet.
Where Safeguard fits
Safeguard scans produce SBOM and dependency inventories you can use as the regenerated baseline in step 3. Run the free scan at gold.safeguard.sh/scan on one repository to see the output.
Try it yourself
Click through it at your own pace, or open it full screen.
Compare the inventory view to your sheet and note which of your columns are missing from it, or the other way round.
Quick check
Should I convert old rows or regenerate SBOMs?
Regenerate wherever the source or image still exists. Convert only when it does not, and label those records as converted.
How long should parallel running last?
One release cycle is usually enough to expose mapping problems.
Last reviewed: 19 October 2026.
