MATLAB → Python migration.
Any math, any domain.
We help R&D and engineering teams move scientific code from MATLAB to a modern Python stack. By an engineer with 20+ years across power systems, embedded firmware, and machine learning — and a portfolio of ported algorithms to back it up.
Why teams move from MATLAB to Python
The reason rarely starts with "we hate MATLAB." It starts with something practical — a renewed license invoice, a new hire who doesn't know the toolboxes, a need to ship the algorithm to a cloud backend. These are the recurring pressures.
Cost
MATLAB licenses run €2,000–5,000 per seat per year — for the base product alone. Add specialized toolboxes (Optimization, Signal Processing, Simulink) and a small R&D team easily spends €30,000–100,000/year on tooling. Python is free.
Deployment
Python containers deploy to Docker, Kubernetes, and any cloud without licensing dance. MATLAB Runtime ships, but adds an install step, version-matching, and platform constraints at every deployment.
Hiring
Engineers graduating today know Python from their first ML course. MATLAB is a learnable but extra skill — and finding senior MATLAB engineers in Europe gets harder each year.
Integration
Modern systems — ML pipelines, web APIs, real-time backends, IoT data ingestion — are Python-native. Calling out to MATLAB from a FastAPI service or a PyTorch training loop becomes the weakest link in the stack.
Vendor independence
Open-source numerical Python (NumPy, SciPy, pandas, JAX, PyTorch) has no surprise license terms, no forced subscription model, no single vendor that can change the rules. For research that needs to outlive a budget cycle, this matters.
A note on speed: we don't promise raw performance gains. Well-tuned MATLAB often matches or beats naive NumPy. The win from migration is in everything around the math: deployment, integration, hiring, license freedom.
Three ways to engage
We start small. Most clients begin with a free readiness call, then move to a paid assessment, and only then commit to a full migration. This keeps risk low on both sides.
Readiness call
Free · 30 minutes
Walk through your codebase together. Honest assessment: is migration the right move? Rough sense of scope.
No pitch. No commitment.
Book a callMigration assessment
€5,000–8,000 · 1–2 weeks
Written report on your codebase. Risk matrix per module. One pilot module ported as proof of approach. Budgetary estimate for full migration.
Deliverables: report + working Jupyter notebook with tests.
Discuss your projectFull migration project
Custom quote · weeks to months
Module-by-module port with side-by-side validation against MATLAB outputs. CI/CD, Docker, documentation. Optional team onboarding and code review.
Typical: €25,000–100,000 depending on scope.
Discuss your projectRisk reversal: if after day 1 of an assessment we agree your code isn't a good fit for migration, you pay only that day's rate and we part ways. No further obligation.
Work and writing
We don't disclose client names. Here's what we've actually built and written about — the things that prove we know how to move math from one stack to another.
Ported MATLAB algorithms to Python (anonymized clients)
- —Power-system state estimation (multi-substation, weighted least squares)
- —Optimal power flow (DC and AC formulations)
- —Transient stability simulation
- —Short-circuit calculation with fault analysis
Open-source projects
- — paraglideml — paragliding weather prediction with PyTorch
- — FlyBeeper — BLE wearables firmware on Zephyr RTOS (nRF52)
Domains we've written about in depth
Power systems & grid analysis · Quadcopter motor parameter estimation · Bicycle electrification & energy conservation · Atmospheric modeling & paragliding weather · Real-time sensor fusion · Deep learning for N-1 contingency analysis · Embedded BLE protocols
This breadth matters. MATLAB code lives in many domains, and the migration questions repeat: numerical precision, vectorization patterns, toolbox replacements, validation strategies. We don't have to be domain experts in your specific field — we are experts in moving math from one stack to another.
FAQ
Which MATLAB toolboxes are hardest to migrate?
Signal Processing and Control System toolboxes have good SciPy/python-control equivalents. Simulink and Stateflow are harder — they typically require partial rewrite rather than mechanical translation. Specialized toolboxes (RF, 5G, Powertrain Blockset) may need custom development of equivalent functions.
Can we do it gradually — keep some MATLAB, add Python?
Yes. Most successful migrations are gradual: identify low-risk modules first, port them with side-by-side validation, then expand. We can also set up Python-MATLAB bridges (the MATLAB Engine API) so both coexist during the transition period.
What about Simulink?
Simulink models are simulations plus visual logic, not just code. Migration options: (a) rewrite in Python with SciPy and python-control; (b) use OpenModelica or SimuPy as a Simulink-like alternative; (c) keep Simulink for what's working and migrate only the computational kernels that need Python integration. We assess this in the readiness call.
What about compiled .p files or proprietary toolboxes?
.p files are obfuscated MATLAB — they can sometimes be reverse-engineered from documentation and behavior, but it's slow and risky. The pragmatic path is to re-implement from the algorithm spec, not from the .p binary. For proprietary toolboxes we evaluate licensing constraints case-by-case.
How do you handle NDAs and IP?
We sign mutual NDAs as part of every engagement. Code stays on your systems; we never move it without explicit written agreement. For highly sensitive projects we can work in an air-gapped setup on hardware you provide.
Have a project?
Tell us about your codebase. We'll reply within two business days with either questions, a suggested call time, or — if it's clear we're not the right fit — a referral to someone who is.
Or reach out directly:
Alpisto d.o.o. — Slovenian LLC, EU VAT registered.
We invoice in EUR via standard reverse-charge for B2B clients within the EU.
NDAs welcome.