The healthcare technology company I worked with in early 2024 had been using the same SBOM tooling vendor since 2021. It was one of the first products in the space. It was also, by 2024, clearly not keeping up -- the UI was slow, the API had not been updated in over a year, and the support team had stopped responding to tickets under eight days. The leadership team had decided to move to a different platform, and they wanted me to handle the migration without disrupting the FDA submissions pipeline that depended on SBOM data.
This is the story of what went wrong, what went right, and the checklist I now use whenever someone asks me about switching SBOM tools. The migration took four months start to finish. I would budget longer if I were doing it again.
Why SBOM Migrations Are Harder Than They Look
On paper, moving SBOMs between platforms should be straightforward. The documents are standard. There are two major formats, CycloneDX and SPDX, and both have open specifications. Any serious platform can import and export both. This is the sales pitch you will hear from the new vendor, and it is roughly true.
In practice, the challenge is not the SBOM documents. It is everything around them. The vulnerability annotations you added over two years. The VEX statements you wrote explaining why a CVE was not exploitable. The policy decisions attached to specific components. The links between SBOMs and deployed environments. The workflow state for outstanding findings. None of this is covered by the SBOM format standards. All of it is vendor-proprietary, stored in the tool's database, and the main thing it was doing for you.
For this migration, we inventoried the state. The SBOM archive itself was about 14,000 documents covering 380 services over three years. The annotations and workflow state attached to those documents weighed about 40 gigabytes in the old vendor's database. The format for that data was, of course, proprietary.
Step One: Export Everything Twice
The first thing I do in any SBOM tool migration is export everything, immediately, before any contract renegotiation or timeline pressure kicks in. You export in two forms: the raw SBOMs in CycloneDX or SPDX, and the full data export in whatever proprietary format the old vendor provides. You store both in cold storage that does not depend on either the old or the new vendor.
This sounds paranoid. It is also the cheapest insurance you will ever buy. The old vendor, in our case, went through a change of ownership about two months into the migration. The API we had been using to export data had its rate limits cut by 80% without notice. Had we not already exported the bulk of the data, we would have been on a four-month export path at the new rate limits. Because we had exported during the first week, we were fine.
The export should be verified. Do not trust that the export tool wrote what you think it wrote. We picked a random sample of 200 SBOMs from the export, re-imported them into a staging instance of the new vendor, and manually compared the component lists and vulnerability annotations against what the old tool showed. We found three classes of bugs in the old vendor's export tool. One was silent truncation of component lists for SBOMs with more than 10,000 entries. If we had skipped verification, we would have lost data for about 15 of our largest services.
Step Two: Understand What Does Not Translate
Every SBOM tool has its own data model, and the mapping between models is not one to one. The old vendor had a concept of "suppressed findings" that combined a VEX-style statement with a time-based expiry. The new vendor had VEX statements, but no expiry -- suppressions were forever until manually lifted.
We made a list of every concept in the old tool that did not have a direct equivalent in the new tool. There were eleven of them. For each, we made a decision: translate the data into the closest equivalent and lose some fidelity, transform the data into a different shape that captured the intent, or leave the data in the archive and not migrate it at all.
The suppression expiry was the trickiest. Losing it would mean that 340 suppressions with expiry dates in 2024 and 2025 would silently become permanent. We wrote a small service that held the expiry dates externally and used the new vendor's API to lift suppressions when they expired. It was twelve pages of Go code. It saved us from a compliance gap that could have gone undetected for years.
Step Three: Run Both Systems in Parallel
We did not cut over from the old tool to the new tool. We ran both in parallel for eight weeks. Every build pipeline pushed SBOMs to both platforms. Every vulnerability that showed up in one was checked against the other. Every policy evaluation was compared between the two.
During this period, we found about 40 discrepancies. In 30 cases, the new tool was right and the old tool had been wrong for a while -- usually because the old tool's vulnerability database had gone stale. In 8 cases, the new tool was wrong, which we reported to the vendor. In 2 cases, the two tools disagreed on a component identity in a way that neither was cleanly right about, and we picked an interpretation and moved on.
The parallel run also served an audit purpose. We had exported and re-imported data. We had verified the import. But until the new tool had actually been making the real decisions in our pipeline, we could not claim equivalence. Eight weeks of parallel operation with no business impact let us make that claim with real evidence behind it.
Step Four: Migrate Integrations Carefully
The SBOM tool does not exist in isolation. It was connected to Jira for ticket creation, to Slack for alerting, to our CMDB for asset correlation, and to our identity provider for SSO. Each integration had to be migrated, and each one had subtle differences.
The Jira integration was the most painful. The old tool created tickets with a specific field layout and a specific labeling convention that had been in place for three years. The new tool's Jira integration wrote to different fields and used different labels. We had 2,800 open tickets in Jira that had been created by the old tool. If we just let the new tool create new tickets, those 2,800 would become orphans -- nothing would update them when their underlying findings resolved.
We wrote a migration script that took the old tickets, mapped them to the new tool's findings, and reattached them. It took three days to develop and about six hours to run. During the run we disabled both tools' Jira integrations to avoid race conditions. Afterward, the new tool seamlessly continued updating the 2,800 existing tickets as findings resolved.
Step Five: Decommission on Your Timeline
The final step is decommissioning the old tool. We waited six months after the parallel run ended before canceling the contract. During those six months the old tool was read-only, available for reference if an auditor wanted to check historical state as it had been recorded at the time. We did this because the regulatory guidance in healthcare is that you preserve evidence in its original form for the full retention period, not just the underlying artifacts.
At month seven we exported the full state one more time, stored the export in the same cold archive as the original, and canceled. The cold archive is still there. I have not needed it yet. I would still do the same thing tomorrow.
How Safeguard Helps
Safeguard treats SBOM portability as a first-class feature rather than an afterthought. The platform imports SBOMs from every major format and vendor, preserving not just component data but vulnerability annotations, VEX statements, and policy decisions wherever the source format allows. Parallel operation modes let teams run Safeguard alongside an existing tool for weeks or months before cutting over, with automated comparison reports that surface discrepancies in real time. Full data export in open formats means that switching away from Safeguard is as painless as switching to it, because lock-in has no place in compliance tooling. For teams escaping a vendor that has stopped serving them, Safeguard is designed to be the last SBOM migration you need to do.