Control & automation
Open PLC modernization: replace your legacy PLC, not your machine
Mechanically your machine has years left, but the S7-300 in the cabinet has left the portfolio, spare parts are getting scarce and nobody dares touch the program anymore. We replace the controller, not the machine: the logic moves to an open runtime on IEC 61131-3, with I/O and communication on standard protocols. You keep the machine, you keep control, and you are no longer tied to one PLC vendor.
Your machine has years left. Its controller often doesn't.
A machine can be in perfect mechanical shape while the PLC running its control slowly turns into a risk. Sound familiar?
Replacing such a PLC is rarely a simple hardware swap. The program has to be migrated, the I/O mapped, the communication rebuilt and the machine retested, while production keeps running. That is why obsolete PLCs often stay in service for years. Understandable, but every year the risk grows.
The facts
Even Siemens says: legacy automation has to migrate
This is not a hypothetical problem. Siemens runs explicit migration programs for obsolete SIMATIC systems, with hard dates. And regulation moves on the same rhythm.
Siemens of course offers migration to its next generation of controllers, and for many machines that is a perfectly good answer. But a question comes up more and more often: does migrating a legacy Siemens PLC necessarily have to end in another Siemens PLC? We don't think so.
A PLC is a function, not a brand
A machine's control needs a fixed set of functions, and not one of them requires by itself that the controller comes from one specific manufacturer.
So we build towards an architecture on open standards: IEC 61131-3 for the logic, EtherCAT or Modbus down to the I/O and drives, OPC UA and MQTT up to IT, standard Ethernet and Linux with real-time extensions where it fits. Which hardware and protocols exactly depends on the machine.
The same list, without the dependency on one ecosystem.
- Deterministic cycle times: the logic runs every cycle within the same milliseconds.
- Digital and analog I/O, from existing cards or over an open fieldbus.
- Industrial communication to drives, HMI and other controllers.
- State machines, timers, counters and fault handling, as in the current program.
- Diagnostics: seeing what the controller is doing, without the vendor tool.
- Controlled updates and a reliable recovery when something goes wrong.
From closed PLC to open control architecture
The goal of the architecture is separation: machine logic apart from controller hardware, the controller apart from the I/O, and the whole apart from cloud and IT. Every layer talks to the next through an open standard, so every layer can be replaced on its own.
Concretely, bottom up: I/O, drives and sensors hang off the machine over EtherCAT. Above that runs the open PLC runtime with the IEC 61131-3 program, in real time. Above that sits the Meshnex Edge for monitoring, fleet management, signed updates and security. And at the very top, over MQTT or OPC UA, the cloud and your IT systems: MES, OEE, energy.
That is the same separation of concerns the rest of the software world has applied for twenty years. On the factory floor it has been rare until now, because the PLC vendor's ecosystem delivered all layers in one go.
No layer is sacred. That is exactly the point.
- Machine logic: the IEC 61131-3 program, under version control, readable without a vendor tool.
- Controller hardware: an industrial PC or embedded controller, replaceable without rewriting the logic.
- I/O and drives: over EtherCAT or Modbus, from multiple manufacturers.
- Edge: monitoring, controlled OTA updates, access control and logging.
- Cloud and IT: MES, OEE, energy monitoring and analytics over MQTT and OPC UA, without touching the real-time layer.
No new vendor lock-in
Migrating to a new proprietary PLC solves one problem and sometimes creates another: new hardware, new engineering software, a new licensing model and a new dependency. Ten years from now you are back in the same spot, with a different sticker on the controller.
We don't want to get rid of industrial vendors. We want the architecture to be replaceable at every layer. You should be able to change these without redesigning the machine:
The goal is not to eliminate vendors. The goal is that the choice stays yours.
- The controller hardware, when a vendor stops or another platform fits better.
- The I/O supplier, module by module instead of the whole cabinet.
- The network hardware: switches, gateways and firewalls of your own choosing.
- The cloud platform: MeshOS, your own platform, or both.
- The engineering environment, because the program is written in standard languages.
Modernization is also cybersecurity
Legacy PLCs were designed for a machine that stood apart from the corporate network. That world no longer exists: remote vendor access, MES connections, engineering laptops, VPNs and IIoT gateways all hang off the same controller. The PLC has become part of your security perimeter, and NIS2 asks exactly there for asset management, access control, network security and continuity. A modern control architecture makes security visible and manageable:
No PLC migration makes you NIS2 or CRA compliant by itself. What a modern, observable and maintainable control architecture does do: make the controls that regulation expects a lot easier to implement and to demonstrate.
Regulation is changing along
The EU Cyber Resilience Act sets cybersecurity requirements for products with digital elements. The shift: security becomes a responsibility across the whole product lifecycle, not something bolted onto an installation afterwards. The reporting obligation for actively exploited vulnerabilities applies from 11 September 2026, the main obligations from 11 December 2027. For industrial technology that means thinking about:
With that, the architecture of a machine controller is no longer only the automation engineer's concern, but also IT's, security's, procurement's and management's. This is not legal advice: what the CRA means for your products depends on your role as manufacturer, integrator or user.
Why modernize? Six reasons you notice on the floor
An open controller is not a goal in itself. The goal is a machine that keeps running, that you can maintain yourself and that takes part in the rest of your factory.
Honest about open PLC: three things up front
An open controller is an engineering project, not a product out of a box. Three truths belong in an honest conversation, and they shape how we set up a migration.
That is why every project starts with an inventory. After that step you know whether open control is the right route for this machine, and if not, which one is.
From legacy PLC to open control in five steps
Every migration follows the same route, and production keeps running in the meantime.
Step 1: discover
We map the machine: PLC, I/O, drives, fieldbus, HMI, safety, network, the program and every external connection. Often passively, without touching the controller.
Step 2: analyze
What stays, what gets replaced, what gets translated? A decision per component, with safety and motion named separately.
Step 3: rebuild
The control logic moves to an open IEC 61131-3 architecture where appropriate, under version control from the first line.
Step 4: test
Validate I/O mapping and machine behaviour next to the existing controller, before the switch-over: outside production hours or on a test rig.
Step 5: modernize
The new controller goes live and is connected to monitoring, cybersecurity and your IT/OT infrastructure. The old PLC stays as a fallback until everything is proven.
We don't want to replace Siemens with another black box
Siemens makes excellent automation equipment, and for many applications it will remain the best choice. The point is not to swap one brand for another. The point is that you have a choice.
The answer to vendor lock-in should not be another vendor lock-in. We believe industrial automation should move in the same direction as the rest of modern software: open interfaces, version-controlled software, replaceable components and clear ownership.
The machine belongs to the manufacturer. The control software should too.
- The machine belongs to the manufacturer who uses it, not to the PLC vendor.
- So does the control software: readable, versioned and transferable.
- Every layer of the architecture can be replaced without redesigning the machine.
- You are not dependent on us either: your own engineers can carry on with it.
Proof from the field
Legacy controllers we have already opened up
No complete open PLC migration as a public case yet: but the steps that come before it. Reading out legacy Siemens PLCs, safeguarding their programs and recipes and connecting the data securely to IT.
Recipe digitalisation Recipes from legacy Siemens PLCs, digitally secured
Recipes that only existed on paper and inside ageing Siemens PLCs, now digitally backed up and versioned. Every setpoint change is logged: who, what, when, and what it did to production. Reverting takes one click.
Downtime tracking Every stop on the line, counted and classified
Every stop is captured automatically from the PLC and classified: changeover, jam, starvation, microstop. A live Pareto shows where the shift actually went, so improvement starts at the biggest eater of capacity instead of a gut feeling.
Pressure monitoring and control Pressure monitored and logged
A custom monitoring device that measures and logs pressure continuously. Deviations trigger an alert before they become a problem with a complete measurement history for analysis and reporting.
Frequently asked questions about open PLC modernization
What is an open PLC?
A PLC whose logic is written in the standard languages of IEC 61131-3 and runs on an open runtime, on hardware you choose yourself: an industrial PC or embedded controller with Linux and real-time extensions. The I/O and drives connect over an open fieldbus such as EtherCAT or Modbus. The difference with a classic PLC is not in what it does, but in who holds the key.
Can a legacy Siemens S7-300 be migrated without replacing the machine?
Usually, yes. The mechanics, sensors, actuators and often the wiring stay; the controller and, where needed, the I/O are replaced and the logic is translated. What shapes the project is the size of the program, the fieldbus (Profibus needs a different approach than Profinet), the HMI and the safety. That is why everything starts with an inventory.
Do the I/O and the drives have to be replaced as well?
Not necessarily. Existing remote I/O on Profinet or Profibus can often stay through a gateway or a suitable master card. With obsolete or hard-to-find I/O, replacing it with EtherCAT modules from a manufacturer of your choice is usually cheaper than repairing. Drives generally stay, provided they have an open interface.
What about safety (SIL/PL) and motion control?
Those are separate tracks. Safety functions need certified components and their own validation; we don't simply move them to an open runtime and sometimes a certified safety PLC remains the right choice. Motion control can run over EtherCAT and open drives, but complex synchronized motion we assess per machine, and we say so honestly when the regular vendor is better at it.
How long is the machine down during the migration?
As short as possible: usually a planned stop of a few hours to a few days, depending on the I/O. The new controller is built and tested beforehand next to the existing one, the switch-over happens in a planned window and the old PLC stays connected as a fallback until the new one has proven itself.
Is open source software reliable enough for machine control?
Open source is an ownership model, not a quality level. Linux runs in trains, network equipment and medical systems, and the same requirements apply here: deterministic execution, industrial hardware, a sound electrical design, testing and documentation. Open means you can read the code and manage the lifecycle yourself; reliable it becomes through engineering, as with any other controller.
Does a PLC migration make us NIS2 or CRA compliant?
No, not by itself. NIS2 asks for risk analysis, asset management, access control and demonstrability across your whole organization; the CRA places obligations on manufacturers of products with digital elements. What a modern control architecture does do is make the controls that come with them easier to implement and demonstrate: an asset inventory, unique accounts, logging and controlled updates are built in. This is not legal advice.
Can our own engineers maintain the new controller?
Yes, that is the intention. The program is written in the IEC 61131-3 languages your engineers already know (structured text, ladder, function blocks), under version control, with documentation. We hand over with training and stay available, but you are not dependent on us: that would only move the lock-in.
What does a PLC modernization cost?
That depends on the size of the program, the I/O, the fieldbus and whether safety and HMI come along. A single machine with a manageable S7-300 program is a different project than a line with ten controllers and synchronized motion. That is why every project starts with an inventory: after that you know what the migration takes, and whether it pays off compared to the vendor's regular migration.
Does this also work for Rockwell, Mitsubishi, Omron or Schneider PLCs?
Yes. The principle is the same per brand: the logic is translated to IEC 61131-3, the I/O and communication are rebuilt on open protocols. The details differ (a ControlLogix uses a different tag structure and fieldbus than an S7), so the inventory is slightly different per brand.
Is your PLC becoming the weakest link?
Do you have machines running on legacy Siemens, Rockwell, Mitsubishi, Omron or other PLC platforms? We assess whether the controller can be modernized without replacing the machine, and tell you honestly when the vendor's regular migration is the better route for this machine.