Open the current CATIA Magic documentation for its SysML v1 to v2 migration plugin and you'll find a warning box most people miss on the first read. The element migration is described as a work in progress covering about 20% of the metamodel, and diagram migration is not covered at all. That's the 2026x release, not a beta from three years ago. If you've been telling your program manager that the v1 model "will just export to v2 when we're ready," this post is for you.
The good news is that the migration problem is now well understood, there's a published OMG transformation specification, and the DoD-sponsored transition guidance gives you a repeatable process. The less good news is that the process is mostly human effort, and the parts a tool can do for you are narrower than the marketing implies.
The transformation exists on paper, less so in tools
OMG published the SysML v1 to SysML v2 transformation as its own part of the v2 specification. It defines a rule for each kind of v1 element, including rules for cases where v2 has no equivalent concept. The often cited example is the isEncapsulated flag on a v1 block. SysML v2 dropped the concept entirely, so the spec has to say what happens to it rather than leaving it to each vendor.
That's the standard. Tool support lags behind it. In CATIA Magic 2026x the workflow is a File > Export To > SysML v2 Model action that produces a local v2 project, plus a spreadsheet listing every element and property that failed to migrate. The mapping table it ships with covers the core: blocks to part definitions, part properties to part usages, value properties to attribute usages, ports and proxy ports to port usages, requirements to requirement usages, activities to action definitions, state machines to state definitions. Satisfy relationships come across as satisfy requirement usages. Derive, verify, and refine land as a plain dependency plus metadata, which is a hint that you'll be cleaning those up by hand.
Some v1 constructs have no target at all in the current mapping. Use case extend and extension points, activity parameter nodes, and flow final nodes are listed as "no alternative match." Those aren't exotic. If your behavior models lean on activity parameter nodes, expect gaps.
Other vendors are in a similar place. Sodius Willert frames adoption as a phased pilot rather than a bulk conversion, and Siemens describes Teamcenter supporting both formats so v1 and v2 can run side by side. Nobody is selling a one-click conversion of a mature program model.
The four-step process the guidance actually recommends
The INCOSE and DoD transition guidance, hosted on the OMG MBSE wiki and derived from OUSD(R&E) material, breaks conversion into four steps. It's worth internalizing because it sets expectations correctly: the tool step is step two of four, and the other three are engineering work.
Pre-processing means making the v1 model conform to the v1 specification. That sounds trivial until you inventory how many tool-specific extensions, custom stereotypes, and validation warnings a decade-old model carries. Adjunct properties are a named example of a v1 feature with no v2 counterpart. Circular dependencies need to be found and broken. The guidance also recommends partitioning the model into packages by structure, behavior, and requirements, and by mission, system, and subsystem level, so that conversion can proceed in slices.
Transformation is the tool run. The guidance expects errors and warnings out of it, and then explicitly calls for manual inspection comparing the two models.
Post-processing is where the real value shows up. A converted model is structurally v2 but stylistically v1. It won't use the usage-focused modeling paradigm that v2 is built around, it won't take advantage of the textual notation, and it won't be organized the way a native v2 modeler would organize it. The guidance is direct that reorganizing and refactoring is part of the job.
Validation means reproducing selected views, system hierarchy above all, and comparing them against the v1 originals. Layout is not preserved. Every diagram gets re-laid out, by you.
Convert, rebuild, or freeze
The guidance raises a question most teams skip: whether to convert at all. If the v1 model wasn't maintained, or if its scope no longer matches the current program, starting fresh in v2 may be cheaper than converting and then refactoring. Three options are on the table for any given model.
- Convert when the model is well maintained, actively used, and its structure and requirements will carry forward largely intact. The conversion is one-way; there's no standard v2 to v1 path, so once a slice is converted, that's the new master.
- Rebuild when the model has drifted from the system, relies heavily on constructs with no v2 mapping, or was built with conventions nobody remembers. Use the v1 model as reference material, not as input.
- Freeze when the program is late in its life and the v1 tool will remain supported for its duration. The DoD guidance acknowledges that some legacy programs will stay on v1 for years, until tools are no longer supported. A frozen model doesn't need to be migrated; it needs a plan for what happens when the tool is retired.
Most large programs end up doing all three across different parts of the portfolio, which is why the incremental approach matters. Convert structure first, then behavior, then requirements, validating each slice before moving on.
Where the tooling landscape stands
Tool choice affects every one of the four steps, because the transform capability is tool-specific and the post-processing depends on how well the target tool supports native v2 modeling. Dassault CATIA Magic (the former Cameo line) is the only widely deployed v1 tool with an in-product migration path, and it's the 20% coverage described above. Eclipse Capella isn't SysML at all; teams there face a different problem, since there's no standard transformation from Arcadia to v2. Native v2 tools without a v1 heritage, including Siemens' v2 support in Teamcenter, Dalus, and the open-source SysML v2 pilot implementation from the OMG submission team, can import v2 textual or API-based content, which makes them viable targets once a transformation has produced a v2 model, but they don't run the v1 transformation themselves.
That split matters for planning. A migration to a native v2 platform is a two-tool exercise: transform in the v1 tool, then move the resulting v2 model across via the standard API or textual interchange. Validate the v2 model in the source tool before moving it, so you can separate transformation defects from interchange defects.
What migration won't solve
It's tempting to treat migration as the moment your modeling problems get fixed. Some things it does nothing about.
- Model quality. A poorly organized v1 model becomes a poorly organized v2 model with better semantics. Refactoring is a separate effort that the conversion only makes possible.
- Derived artifacts. Reports, requirement exports, analysis inputs, and test plans generated from the v1 model are explicitly out of scope of the conversion process. Each one needs to be regenerated or re-pointed at the v2 model.
- Diagrams. Nothing in the current tooling preserves diagram layout. Budget time for it, especially for the diagrams that appear in reviews and contractual deliverables.
- Execution semantics. The guidance notes that comparing execution results between v1 and v2 models would help validation, but v2 execution semantics were still being finalized when it was written. Don't plan on simulation-based equivalence checking yet.
- People. Engineers who model in v1 idioms will keep modeling in v1 idioms inside a v2 tool. The usage-focused paradigm is a real shift and needs training, not just a converted file.
- Classified models. The guidance calls for a security extension using v2 metadata to preserve classification markings, plus manual inspection. That's a process you have to define, not something the transformation does for you.
Bottom line
SysML v1 to SysML v2 migration in 2026 is a partially automated, mostly manual engineering task. The standard transformation exists, the process guidance is solid, and the leading v1 tool can convert the structural core of a model. Diagrams, roughly 80% of the metamodel, and all the refactoring that makes a v2 model worth having remain your job.
The practical move is to stop treating migration as a future switch you'll flip. Pick one well-maintained, well-bounded model. Pre-process it to spec conformance, run the transformation, read the failure report, and rebuild the top-level hierarchy views. That single exercise will tell you more about your real migration cost than any vendor demo, and it'll give you the numbers you need before deciding which programs convert, which rebuild, and which stay frozen on v1 until the end.