A year ago, asking "which SysML v2 tool should we use?" mostly got you a shrug and a roadmap slide. That's changed. The Object Management Group approved SysML v2.0, KerML 1.0 and the Systems Modeling API and Services specification for final adoption on July 21, 2025, and vendors have been shipping against it since. Now the question has real answers, and a real risk: picking a tool on a demo and discovering the gaps eighteen months into a program.
This is a checklist for avoiding that. It's written for the person who has to defend the choice to both engineers and a budget owner.
Start with what the standard actually gave you
The July 2025 adoption wasn't one document. It was three: the language itself, KerML as its semantic foundation, and a standard API for tool interoperability. That third piece matters more for tool selection than most evaluations admit. The language tells you what a model means. The API tells you whether you can get your model out of one tool and into another, or into your own scripts, without a vendor-specific export.
OMG named Ansys, IBM, Siemens, PTC and MathWorks among the vendors announcing support, so the field is wide. "Supports SysML v2" on a product page can mean anything from a full native implementation to an import filter. Your job is to find out which one you're buying.
The six questions that separate tools
Practical adoption guidance from Sodius Willert lists the criteria worth testing, and they map well to what we see teams stumble on. Here they are as questions you can put in an RFP.
- Standards compliance. Does it read and write the standard textual notation? Does it expose the standard API, or only a proprietary one? Can you round-trip a model without losing elements?
- Migration from v1. What converts automatically, what needs manual rework, and does the vendor say so up front?
- Execution and validation. Can you run or at least check the behavior you've modeled, or is the model a drawing with extra steps?
- Configuration management. Is there real versioning, branching and diffing, or just file checkout?
- Lifecycle integration. Does it connect to the requirements, ALM and simulation tools you already pay for?
- Usability across views. Textual, graphical and tabular editing are all part of v2. Test whether your non-programmers can live in the graphical view and your software people can live in the text.
Don't weight these equally for everyone. A team that wants models in a Git workflow will care about questions 1 and 4 above all. A team with a decade of v1 assets will live or die on question 2.
What the current options look like
The field splits roughly three ways, and it helps to name real examples.
Established desktop suites have added v2 alongside v1. The 2026 releases of No Magic Cameo and CATIA Magic support both SysML v1 and v2 for project modeling, but only in specific bundles: Cameo Enterprise Architecture and Cameo Systems Modeler (Enterprise Edition), plus Magic System of Systems Architect and Magic Cyber-Systems Engineer. According to GoEngineer, Cameo Systems Modeler (Architect Edition) and MagicDraw with the SysML plugin don't gain v2 access in 2026x, and a price increase of around 20% applies from January 1, 2026 to bundles that support it. Read your edition's fine print before assuming an upgrade path.
Open-source options exist too. SysON is a web-based SysML v2 editor maintained as an Eclipse Foundation community project, with Obeo and CEA List as project leads and an 8-week release cycle. It offers graphical, form-based and tabular editors, and Capella interoperability is a stated goal, which is relevant if you already run Eclipse Capella for architecture work.
Then there are newer platforms built around v2 from the start. Dalus is one example of a SysML v2-native, browser-based MBSE platform.
Which category fits depends less on feature lists and more on your constraints: existing licenses, security posture, how much v1 you carry, and who maintains the thing in year three.
Run a pilot that can fail
The most useful single step is a pilot with a pass/fail definition written down in advance. Sodius Willert's guidance points toward the same shape: transition teams, pilot projects, updated methods and retrained people, rather than a switch flipped across a program.
Pick a real subsystem, not a toy. A redesign or a next-generation variant is ideal, since that's where v2 is most likely to pay off. Model it in the candidate tool. Then do the unglamorous part: push the model through the standard API into a second tool or a script, and see what survives. Finally, put it in front of the reviewers who will actually have to read it, including the ones who hate new tools.
Write the exit criteria before you start. "Round-trips with no element loss" and "a reviewer can find the requirement allocation in under two minutes" are testable. "Feels modern" isn't.
What this checklist won't solve
Be honest about the limits.
A tool evaluation can't fix an unclear modeling method. If your team hasn't agreed on what a model is for, v2 will give you a more expressive way to produce the same confusion. The language is also young. Even the people closest to it have published critical reviews, such as Cris Kobryn's "The Good, the Bad & the Ugly" at sysml.org, so expect rough edges and read them as normal for a new standard rather than a reason to stall.
Conformance claims are hard to verify from outside. A vendor can truthfully say it supports the API and still implement only part of it. Your pilot is the only reliable test.
Finally, migration is a risk calculation, not a technical one. As the Sodius Willert guide puts it, migrating a whole program from v1 to v2 takes a high level of risk tolerance. A hybrid period, with v1 kept for legacy work and v2 introduced for new subsystems, is a legitimate end state for many programs, not a failure to commit.
Bottom line
Choose a SysML v2 tool the way you'd choose any piece of infrastructure: by testing the interfaces, not the interface. Ask about the API, versioning and v1 coexistence before you ask about diagrams. Name your real constraints, pilot on a real subsystem with written pass/fail criteria, and expect to learn something unflattering about every candidate. The tool that survives that exercise is usually a better fit than the one that won the demo.