Dyad Migrates Legacy Engineering Models

This migration layer is really a wedge into locked up engineering budgets. Most industrial teams already have years of plant, controls, and system models sitting in MATLAB, Simulink, or Modelica, so the real barrier is not interest in faster simulation, it is the cost and risk of rebuilding old models by hand. Dyad makes the switch practical by converting legacy artifacts into Julia based workflows, then backing that handoff with services and a physics constrained environment for validation.

• The practical point is workflow continuity. Dyad models map into Julia code, can be edited visually or in VS Code from the same source of truth, and can export FMUs or embedded control code, so migration is not just file conversion, it is a path from old models to production engineering workflows.
  1 sacra 2 juliahub 3 juliahub
• MathWorks remains the hardest account to displace because Simulink already owns model based design, code generation, verification, and requirements workflows inside many aerospace, automotive, and industrial programs. MathWorks also launched Simulink Copilot in Release 2026a, so JuliaHub is attacking an incumbent that is adding AI without asking customers to change stacks.
  1 sacra 2 juliahub 5 mathworks
• Modelica is the clearest comparison for open style system modeling. Dyad is explicitly inspired by Modelica, and JuliaHub has described LLM based translation as part of its pitch to Modelica users. That suggests the strategy is to inherit existing multiphysics models, then pull users onto Julia for simulation, optimization, and AI work that sits around the model.
  4 juliahub 6 modelon

The next step is for migration to become less of a one time services project and more of a repeatable land and expand motion. If Dyad keeps turning legacy models into living Julia assets that engineers can simulate, tune, and deploy in one stack, JuliaHub moves from being a niche replacement tool to being the modernization layer for industrial model based design.