Migrate from Ketryx: overlay to one system of record

Leaving Ketryx (or a similar compliance overlay) is an architecture change: you stop synthesizing the regulated thread across Jira, GitHub, TestRail, and connectors, and you start authoring requirements, tests, risk, and SBOM in one system of record.

Neither pattern is universally better. Overlay minimizes disruption to engineering tools. A system of record minimizes the stack you license, validate, and reconcile. This guide is for teams who have already decided to consolidate into traceunified.

Inventory what the overlay was covering

1. Where requirements are authored today — Jira issues, Confluence, a separate ALM, or overlay-managed records.
2. Where tests and runs live — typically TestRail or equivalent.
3. Where risk and SBOM live — overlay-native vs scanner vs spreadsheet.
4. What evidence packages you generate for audits — list the reports you cannot afford to lose mid-cutover.
5. Connectors — what still needs to sync after consolidation (often GitHub/Jira for work tracking, not as the SoR).

What to export / bring forward

• Requirements and IDs — ReqIF, CSV, Excel, or Word from the underlying ALM/Jira export you can get
• Test cases — CSV/Excel from TestRail (see Migrate from TestRail)
• Risk registers and mitigations you will still defend — CSV/Excel where available
• SBOM inventories — CycloneDX or SPDX from your build/SCA tooling
• Trace matrices or connector-derived link exports — treat as a mapping aid, then rebuild as native links

Import into traceunified

Consolidation is several Import Center passes, not one magic “Ketryx file.”

Requirements

1. Upload ReqIF / CSV / Excel / Word in the Import Center.
2. Set Import Destination, map fields (and ReqIF Type Mapping when using ReqIF).
3. Enable Import Traceability Links when the file carries relationships.
4. Preview, then commit.

Details: Import requirements and ReqIF & field mapping.

Tests

Import the TestRail (or equivalent) library via CSV/Excel with field mapping, then link cases to the requirements they verify — on import if IDs align, or in a structured cleanup pass. Pattern: Migrate from TestRail.

SBOM

Import CycloneDX or SPDX so components become first-class records on the thread (SBOM import, Import & triage an SBOM).

Architecture (if in scope)

If Cameo/Rhapsody sat under the overlay stack, bring models via XMI as in Migrate from Cameo or Rhapsody.

Keep satellites on purpose

Jira can remain a task board; GitHub can remain the code host — without remaining the compliance system of record. Wire what you keep through Integration Hub / API if you still need sync; do not dual-write the regulated thread forever.

Cutover pattern

1. Pick one product or release train.
2. Author new work in traceunified first; import history as needed — do not require perfect history before new authoring starts.
3. Re-link the thread — requirement → test → risk → SBOM component. The overlay often displayed that graph; traceunified must store it.
4. Retire the overlay when coverage views, signatures, and SBOM impact paths match your QMS bar.
5. Confirm outbound export (Export) before you turn off the old layer.

Validation checklist

• Critical requirements and tests present with stable IDs
• Coverage for a known subsystem matches prior audit understanding
• CVE or requirement change flags linked risk / verification as expected
• Part 11 path exercised on a controlled approval (if in scope)
• Clear RACI: what is still done in Jira/GitHub vs traceunified

When staying on an overlay is right

If engineers cannot leave Jira/TestRail as the authoring surface, and you are willing to validate the overlay plus every connector underneath, staying can be the lower change-management cost. Consolidation wins when stack cost, validation surface, or drift across tools is the real pain.

Related reading

• Ketryx alternatives
• traceunified vs Ketryx
• Ketryx alternative
• Migrate from TestRail
• Import requirements
• SBOM and FDA cybersecurity (524B)