From SysML v1 to SysML v2: Is Switching Worth It?

Recently I presented our whitepaper “From SysML v1 to SysML v2” on LinkedIn. The post did well, but the most interesting reaction was a critical one: “I wish somebody would address the value proposition for moving to V2. At a glance it does not look very good. I must be missing something…” A fair question, and one that rarely gets a sober answer. As independent consultants we don’t earn our money with the standard but with working model-based systems engineering. So my view is a little more differentiated, and it is best laid out along three questions: What does v2 actually do better, and where does that show up as measurable ROI? What speaks against switching? And for whom does the switch pay off?

What does v2 actually do better, and where does it show in the ROI?

First, some context: SysML v2 is not a v1.8. The language was rebuilt on a formal foundation (KerML), with deliberate breaks from v1. I consider five improvements substantial. Since “higher ROI” remains a claim as long as nobody names the cost position that actually shrinks, each point states whether it saves money in a measurable way or simply makes everyone’s life easier.

One pattern instead of many special cases. The definition/usage principle runs through almost all language elements: part def and part, action def and action, requirement def and requirement. Once you have understood the pattern, you can work out large parts of the language on your own. In v1, blocks, activities, requirements, and ports each follow their own rules, many of them UML legacy. Measurable in the ROI: yes, in onboarding. Measure the training days and the time to the first productive model change, and compare them across your onboardings. This lever takes effect with every single onboarding, so it grows with the amount of turnover or supplier engineers in your project.

Behavior lives visibly inside structure. v1 can attach behavior to structure, too: a block owns its classifierBehavior, operations have methods. The separation starts one level below, inside the behavior. A v1 activity works with its own parameters and pins; it knows nothing about the block’s ports. If you want to use the part’s inputs and outputs in the activity diagram, you build auxiliary constructs from ReadSelfAction and ReadStructuralFeatureAction and keep ports and pins consistent by hand. This is exactly where we got stuck in a Cameo project until the workaround was in place. In v2, actions are usages in the part’s namespace: a perform action accesses the ports of its part directly, and the diagram shows which behavior is performed by which system element. Measurable in the ROI: hardly. A specification that anticipates questions saves review loops, but that is rarely attributable in a clean way. This point mostly makes life easier.

Textual notation and a standard API. A v2 model is also text. That means: diff and merge in Git, model reviews in the merge request, analyses and generation without proprietary plugin development. On top of that comes a standardized API for tool and script access to the model. Measurable in the ROI: twice, in fact. First, in engineering hours per review round: reviewers see in the diff what changed since the last state instead of putting two diagram versions side by side. The condition is that they can read the notation. Second, in the cost of automation: against a standard API, any software-minded engineer writes consistency checks, evaluations, and generators; in the v1 world, the same thing often meant Java plugin development by a dedicated tool specialist. Compare what such an evaluation costs you today.

Free tool choice instead of a vendor trap. A standard whose models are plain text lowers the entry barrier for tool vendors: the choice already ranges from lightweight editors with visualization to classic full clients. Above all, you take your model with you when switching from vendor x to vendor y, like source code when switching IDEs. In v1, switching tools effectively meant remodeling because of the lossy exchange. How tight that trap can get is something I experienced in a project with IBM Rhapsody: system architecture in version 9.x, the software architecture building on it in 8.x. A model import to create links and allocations between the two was impossible without irreversibly upgrading the older version, which was off the table for several reasons. Same vendor, same language, and still a wall. One caveat belongs here: you can take the model and the view definitions with you, not the hand-tuned diagram layouts. Graphical rendering remains tool-specific in v2 as well. Diagrams, v1’s biggest Achilles’ heel in model exchange, are mitigated in v2 only insofar as views are generated there instead of maintained by hand. Measurable in the ROI: only when the event occurs, in avoided migration costs at the next tool or version change and in the conditions of the next license renewal. Up front, both can only be priced into the business case as a risk discount.

Interoperability. The previous point was about switching your own tool. This one is about the ongoing exchange across organizational boundaries, where each side keeps its own tool. A commenter on my post, Doug Rosenberg, called it “the biggest win by a wide margin”. I share the direction. Measurable in the ROI: wherever models are rebuilt at organizational boundaries today. The supplier receives a PDF or a lossy XMI export and models it again, the integrator checks it manually; a standardized exchange format turns this duplicated work into an import. Today’s effort per model handover is the metric, and at the same time the upper bound of the savings potential. Two conditions remain: both sides have to speak v2, and the new language still has to prove at scale which of these benefits actually materialize.

None of these points is automatic, and none of them comes with a reliable industry figure. The core of your business case is measuring them in your own context: days per onboarding, hours per review round, effort per model handover, conditions at the next tool decision.

What speaks against switching?

The tool landscape is young. Collaboration in large teams, integration with requirements management tools such as DOORS or Polarion, report generation for assessments: these capabilities were hardened in mature v1 tools over years and are still unevenly distributed across the v2 tool landscape. Check the must-have criteria of your process against concrete tool versions, not against roadmaps.

Migration is remodeling. There is no lossless push-button migration from v1 to v2. The OMG does specify a transformation, but the semantics differ, and at the latest with your profiles, stereotypes, and scripts, every automatism ends. What is realistic is a tool-supported remodeling with review, not a conversion. Some tool vendors offer native transformation plugins, but without additional manual rework they won’t give you the full value of v2.

Your v1 investments are real. Trained teams, established methodology, profiles and libraries, automation, well-rehearsed review processes. In any business case, this inventory weighs more than language advantages on paper.

And the fundamental criticism. Another comment under my post said, in essence: v2 has piled too much onto the already misshapen v1, semantics have to come before notation, and approaches like CSDL or tools of the CORE/GENESYS line demonstrated that long before SysML. I take this objection seriously. The v2 answer to it is KerML as the formal basis underneath the language. Whether the OMG hit the nail on the head with it will only become clear once large programs have taken v2 through several product cycles.

For whom does switching pay off?

Whether the measurable levers from the first chapter outweigh the switching costs depends on where you start:

Mature v1 models. Here I am unambiguous: porting a working, validated v1 model for the sake of v2 conformance alone does not pay off. You pay for remodeling, revalidation, and retraining the team, and you get the same information back in a prettier language. The one exception I accept: the model becomes the basis of a new platform family with a long product lifecycle. Then the investment spreads over many years, and the v2 advantages in automation and exchange pay in over the entire lifetime.

New product, new model. Without migration costs, the math looks different. The flatter learning curve and the automation options take effect from day one. What remains is the tool question: does a v2 toolchain meet the must-have requirements of your process today? If yes, there is little reason to start a new model in a language whose end of life is in sight.

Introducing MBSE from scratch. The strongest case for v2. If you come from a document-based organization, nobody has to unlearn v1, and the uniform definition/usage pattern lowers the entry barrier for the whole team. One warning from project experience belongs here: MBSE introductions do not fail because of the language version. Methodology, modeling guidelines, and management backing weigh more than the question of v1 versus v2.

Switch or stay?

From the three starting points, clear patterns emerge for me:

And for everything in between: don’t judge by gut feeling or conference mood. Evaluate with your own use cases and a pilot model against your own criteria. Nobody is forcing you to hurry; v1 tools won’t disappear overnight, and a well-managed v1 model is worth more than a poorly managed v2 model any day.

Introducing MBSE at itemis — from analyzing your starting point to tool selection and the first implementation steps toward the final model: Systems Engineering →