Friction migrating MathWorks legacy customers
MathWorks
The core issue is that MathWorks has to sell a different operating model, not just another license. Long tenured MATLAB and Simulink teams already run proven desktop workflows built around named users, local scripts, and validated models. Products like MATLAB Production Server, Simulink Copilot, and the Simulink Agentic Toolkit ask those same accounts to involve IT, cloud licensing, sign in services, and new review steps, which slows expansion even when the product value is real.1 2 3 4 5 6
- MATLAB Production Server is valuable when a company wants to turn a tested MATLAB function into a shared service that a web app, database app, or internal system can call. That sale often shifts from an engineer buying a toolbox to an IT team standing up servers, network licenses, cloud configs, and client integrations.2 3 7
- The newer AI products add another layer of adoption friction. Simulink Copilot requires MATLAB, Simulink, MATLAB Copilot, account sign in, internet access, and maintenance coverage. The Agentic Toolkit also leans on surrounding tools like Simulink Test and Requirements Toolbox, so the upgrade path is really a bundle and workflow change, not a simple seat expansion.4 5 6
- This is the downside of deep lock in. The same proprietary scripts, validated models, and trained engineering habits that make switching away from MathWorks hard also make internal change slow. In safety critical environments, teams prefer to keep using the exact setup that already passed review, which raises the bar for every new layer MathWorks tries to add.1 4 8
MathWorks is heading toward more deployment and AI revenue, but winning it will depend on packaging new products so they fit existing engineering controls instead of forcing a full workflow reset. The accounts that expand fastest will be the ones where MathWorks can make server deployment, validation, and agent supervision feel like an extension of Simulink, not a separate modernization project.2 4 5 6