Motionwell provides PLC migration and upgrade services in Singapore, replacing obsolete control hardware while preserving the machine’s required sequences, interfaces and recovery behaviour. We start with the installed controller, I/O inventory, source program and shutdown window. The target platform is selected around technical requirements and the tools, spares and support already used by your maintenance team.
Control design and pre-commissioning tests take place at our Woodlands Link facility. Our machine experience spans palletizing, automated storage and CNC shot peening, with different motion, operator-interface and data requirements in each application.
Two landing shapes cover most of what we actually build, and the choice between them is made at the survey. The centralised shape puts the controller in the panel with an I/O rack beside it carrying the digital input, digital output, relay output and analogue input modules, and runs field wiring back to that rack. It suits a machine whose wiring is sound and whose cabinet has room.
The distributed shape puts I/O blocks out at the machine on a device-level network, takes adapters with two network ports so nodes can be daisy-chained, adds IO-Link masters where the sensor layer justifies it, and pulls one network cable back. It suits a machine where the existing loom is the thing you least want to keep, and it is the shape that makes a later sensor change a configuration job. Cost per point is higher on the distributed route. Installation hours are lower, and the difference usually decides it.
Whether to modernise the machine at all, the survey that precedes a price, and the conformity line a modernisation can cross sit on our machine retrofit and modernisation page.
Why Is a PLC Migration Rarely a PLC Problem?
The processor is swapped once, and everything it is wired to is handled one point at a time. Count the terminations and the shape of the project changes.
A controller sits at the centre of four things that all have to move with it. Every discrete and analogue point has to be identified, re-terminated and proven individually. Every field device at the end of those points has to be checked for type, signal convention and whether it can still be bought. Every drive has to be re-parameterised, re-tuned and re-proven on the mechanism it is bolted to. And the operator interface has to be rebuilt for people who have been using the old one for a decade. None of that scales with processor performance, and the effort is set by point count, device count and axis count.
| Subsystem | What the migration does to it | What sets the effort |
|---|---|---|
| Controller and chassis | One removal and one installation, plus communications configuration | Almost nothing; it is also the part most easily quoted |
| Discrete and analogue I/O | Identify, re-terminate and prove every point against the device at the far end | Point count, and whether the drawings match the machine |
| Field devices | Confirm type and signal convention, replace what is dead or out of production, re-bracket where the replacement body differs | How many devices are still procurable in the same form factor |
| Drives and motors | Re-parameterise, re-tune, re-measure run-down, confirm the mechanism still behaves | Number of axes, and whether motors are being kept |
| Operator interface | Rebuild screens, recipes, alarm text and user accounts | How much of the machine’s operating language lives on the panel |
| Network and cabling | New segment, address plan, switch, and cable suited to the new signal types | Whether the machine had a network before |
Field devices deserve their own warning because they are found late. A discrete sensor is sourcing or sinking and the two are not interchangeable with whichever input module was ordered. An analogue loop wired for a voltage card nobody sells becomes a signal conversion and a re-scale. Some devices are already dead, and the old program learned to work around them, so the fault is inherited. Writing the replacement code so it can be recovered from any state, carrying none of those workarounds forward, is covered on our PLC programming services page. And a sensor with the same function in a different body means a new bracket, which is fabrication work found during a shutdown.
Drives are the second surprise. A modern drive on old mechanics does not reproduce the old behaviour by default: acceleration, following error and run-down all change, and the mechanism has aged since the original tuning was done. Budget for tuning on the machine with the real load, and take the detail from our servo and drive retrofit page.
The operator interface is easy to cost as a screen redraw. On the 5-axis CNC shot peening machine we delivered for turbine blade treatment, the HMI carries the G-code program list, live X, Y, Z, B and C coordinates and an M-code function table, with M03 and M05 starting and stopping peening, M08 and M09 driving the air curtain and M212 and M213 controlling dust extraction. Reproducing that on a new panel is re-implementing an operating language the process engineers already think in. Operators also navigate by position as much as by label, so a screen set redrawn from a blank page costs training time in the weeks after cutover whether or not it is better.
Which of the Four Migration Strategies Fits Your Machine?
There are four, they are priced very differently, and the shutdown window usually decides between them.
| Strategy | What physically changes | Shape of the downtime | What you inherit | Where it fits |
|---|---|---|---|---|
| Like-for-like replacement | New controller and new I/O modules in the existing cabinet, field wiring re-terminated onto new terminals, program rewritten to reproduce the old sequence | One continuous window covering strip-out, termination and proving | The machine’s behaviour on purpose, including its habits | A machine that is correct, and whose controller is the only thing that has run out |
| In-chassis migration with conversion hardware | Processor and communications swapped; conversion adapters and wiring arms let a current processor take over the existing I/O chassis and field terminations | The shortest of the four, because the field wiring is not disturbed | The old I/O’s channel density and diagnostics, and a chassis that remains a spares question | A short window, a large point count, and field wiring in sound condition |
| Full re-architecture | New controller, distributed I/O on a current fieldbus, new drives, new HMI, program written from a fresh specification | The longest window, and the largest share of engineering ahead of it | Nothing, which is both the point and the risk | A machine being asked to do something new, or one whose I/O, drives and controller have run out together |
| New alongside old, phased cutover | The new panel is built and powered beside the running machine, and subsystems transfer one at a time | Several short windows | A temporary interface between two live control systems for the duration | Lines that cannot stop for long, and machines where a route back matters more than the schedule |
Three things are worth reading out of that table.
The second row is worth knowing about before the shortlist is drawn. Conversion hardware exists precisely because re-termination is the slow part, and leaving the field wiring undisturbed removes a large block of window time along with a common source of wiring errors. What it does not remove is the reason you started: the I/O modules behind those adapters are still the old generation, with the old diagnostics and the old spares problem. It is a good buy when the window is genuinely the binding constraint, and a poor one when the I/O is what is failing.
The fourth row carries costs that are easy to miss when it is quoted. You are paying for two control systems live at once, the interface between them, the panel space to stand the new one in, and the engineering to run a machine half on each. That is bought for one reason: at every stage there is a working machine to go back to.
The four are not exclusive. A workable shape on a large machine is a hybrid: conversion hardware on the bulk of the discrete I/O to protect the window, new drives and a new HMI because those are what the plant actually wanted, and a program written fresh. Choose the strategy per subsystem and the argument gets easier.
How Do You Recover the Logic When the Running Program Is the Only Documentation?
Establish which of three states you are in first, because they carry different work and only one of them is comfortable.
| What you have | What it gives you | What it still costs |
|---|---|---|
| A source project that matches the running controller | Structure, symbol names, comments, and the ability to compare versions | Proving that the file on the shelf is the one in the machine, before anyone trusts a line of it |
| An upload from the controller and nothing else | The logic exactly as it runs, which is the only version that is definitely true | On some older platforms an upload returns addresses and rungs without symbol names or comments, because those lived in the programming workstation |
| Neither, or a controller that will not communicate | The machine itself, and whatever the operators know | Tracing field wiring, building the I/O list from the terminals, and reconstructing the sequence from observed behaviour |
The third row is not rare, and it arrives for mundane reasons: a program password nobody recorded, a memory backup battery that died years ago, a proprietary programming cable that has gone missing, or a programming tool that only runs on an operating system no laptop in the building still has. One practical consequence follows. Where the controller cannot be uploaded and the machine is still running, do not power it down until the recovery work is finished. A controller holding the only copy of the logic in volatile memory can be switched off permanently by accident.
Whichever row you are in, the deliverable of this phase is the same, and it is not a program. It is a written sequence of operation covering every mode including setup, jog, cleaning and manual recovery; an I/O list with the actual field device named at the end of each point; and an interlock list saying what each one prevents and why. That document is what the new program and the safety assessment are written from, and what the plant will still have in five years. Working out what the existing circuits do before replacing them is frequently the largest single item in a retrofit safety scope, so price this phase separately, never buried inside a fixed-price build.
Before a controller hardware change, confirm how the installed processor retains its state. PLC battery maintenance separates battery maintenance from programme recovery.
Why Is Translated Code a Liability, Not an Asset?
A converted program is a faithful copy of decisions made under constraints that no longer exist, and it makes them permanent.
Consider what was in the original. A timer standing in for an instruction the old processor did not have. Logic that works because of the order rungs are scanned in. Addressing arithmetic that encoded which slot a card sat in. Retentive bits carrying state across a power cycle in a way nobody documented. A one-shot pattern written for a scan model different from the one you are moving to. A converter carries every one of those forward, and the reason for each of them is gone.
Three consequences follow, and they land after the project.
The first is readability. Converted output tends to look like neither the source platform nor the target platform, so the maintenance team who could read the old program cannot read the new one, and neither can the next contractor. This is the cost that gets paid at three in the morning.
The second is that the improvement never arrives. A migration is normally justified partly on better diagnostics, cleaner recipe handling or a data structure something above the machine can read. Diagnostics are a design decision, so a translated program keeps the old ones and the business case quietly loses part of what it promised.
The third is that on a regulated machine you pay for the testing either way. A converted program still has to be tested against a specification and the change still has to be impact-assessed, which is set out on our computer system validation page. So the saving a converter promises does not appear in the test budget. The only difference is whether you now own something worth keeping.
Where a converter earns its place is as a tool: reading the old logic quickly, generating the I/O and tag inventory, and cross-checking that the rewrite has not dropped a rung.
There is one genuine exception. If the machine is already scheduled for replacement and the migration is buying a defined period, a converted program is a reasonable purchase, because you are explicitly not planning to maintain it. Say that out loud when it is the plan, so the decision is recorded as deliberate.
What Happens the First Time the Machine Gets a Network Port?
The old controller had a programming port and nothing else. The new one has Ethernet interfaces, and a plant that would like the data.
Three paths appear at once and they are not the same kind of thing. Device-level traffic between controller, drives and remote I/O is deterministic and belongs to the machine. A path upward carries production data to a server or MES. A maintenance path lets somebody reach the controller without standing in front of it. Separating the first from the other two is a panel decision, given a controller with two interfaces and one managed switch.
The migration is when that partition costs almost nothing. After handover it costs a shutdown, an argument and a change record, so decide three things while the panel is still on a bench: which traffic sits on which interface, what the address plan is, and whether the maintenance path exists at all. The maintenance conduit is the one that gets argued over on retrofit work, because it is the path the machine never had before. Put the answer on the panel drawing, where it survives the people who made it. The zone and conduit reasoning behind all of this, including how much security level to specify and who is responsible for what, is in our guide to IEC 62443 for industrial control systems.
One item belongs on the migration scope. If the machine has to hold named user accounts, that is a controller and HMI capability decision taken at platform selection. On Allen-Bradley that is normally FactoryTalk security tied to the HMI application, and on Siemens it is WinCC user administration; what those accounts have to satisfy is on our 21 CFR Part 11 and electronic records page.
How Does the Cutover Actually Run Inside the Window?
The general staging of a modernisation against a shutdown is on the retrofit page. What is specific to a controller migration is the order of proving.
Inside the window the sequence is fixed and each step gates the next. Isolate and lock off. Strip out. Mount and terminate. Then prove the I/O point by point with the machine dead, one person at the terminal and one at the device, confirming that the point named on the list is the device that moves. Only then power the drives and check each axis for direction, scaling and limits before anything is asked to follow a profile. Then dry cycle without product, then a product trial, then production.
Point-by-point proving is the step that overruns, and it does so predictably: it scales with the number of points and cannot be parallelised beyond the number of people who can safely work in one panel at once. That ceiling is a physical constraint. It is also why the strategy table above matters more than the controller choice, since conversion hardware removes most of this step and a full re-architecture adds all of it.
Three decisions are taken weeks earlier and decide whether the window holds.
What is kept as the route back. The old processor, its I/O and its wiring either stay intact and available or they do not. Keeping them costs space and a little money and buys a return path; scrapping them saves both and commits you. Whichever you choose, choose it out loud, because a fallback that exists in nobody’s plan is not a fallback.
What counts as finished. Agree the acceptance list before the window opens: which cycles run, which products, which fault recoveries get demonstrated, and who signs. The argument you do not want is one at five in the morning about what done means.
Who is on the floor for the first production shift. The faults that appear then are format cases, recovery paths and operator habits, and they surface in hours. An engineer present converts them into fixes; an engineer who has flown home converts them into a support ticket.
Controller migration can change tags and driver behaviour at the supervisory layer. SCADA and PLC cutover coordinates version compatibility, archives and operating checks.
The CNC and machine PLC need an agreed split of axis and auxiliary functions. CNC and machine-PLC migration addresses interlocks, recovery and versioned handover.
What Does Replacing a Safety-Related Controller Re-Open?
It re-opens the performance level argument in full, and this is the part of a migration most often scoped as though it were the same work as the standard logic.
The first question is which of three states the machine is in, because the answer decides how much of the safety case moves.
| Where the safety functions live today | What a controller migration does to them | What has to be produced |
|---|---|---|
| Hardwired relays and contactors, independent of the PLC | Nothing directly, if the circuits are genuinely untouched and stay untouched | Confirmation that they were not touched, plus re-measured stopping performance, because new drives change run-down time |
| Inside the standard PLC, mixed in with the process logic | Everything; safety functions carried in standard logic do not transfer as safety functions | A safety function register, a required performance level per function, an architecture that can reach it, and validation of each |
| A dedicated safety controller or safety relay module | The safety architecture is being replaced, so each function is re-argued on the new devices | The same register and calculations, restated on the new components with their reliability data |
The middle row is the one that turns a controls quotation into a different project, and it turns up on machines built before a plant expected a safety function register at all. Safety functions written into ordinary logic on an ordinary processor are not safety functions in the sense a modern assessment uses, and finding that during a migration is finding it at the cheapest possible moment, because the panel is already open.
Two facts frame the paperwork. ISO 13849-1:2023 is the edition a current design is calculated against, and a design still documented against the 2015 edition will need its performance level calculations restated when the machine is re-assessed; a controller migration is one of the changes that puts that re-assessment on the table. And where no performance level calculation was ever recorded there is nothing to restate, so the register is built from the logic recovery phase above.
Whether the modernisation makes the machine into new machinery in the legal sense is settled per project, and it is set out on the retrofit page linked above. The guarding, interlocking, validation and documentation scope that follows either answer is on our machine safety and CE marking page. We implement and document that scope.
For a migration that changes the machine network, compare PROFINET and EtherNet/IP device compatibility before ordering the controller. Confirm retained I/O, drive functions and the diagnostic information that will reach the replacement system.
Which Platform Should the Machine Land On?
It should land on whichever platform your maintenance team already stocks spares for and has been trained on, unless something specific rules it out. That is why we ask what you run before anything is selected. The mainstream families a plant here chooses between are Allen-Bradley, Siemens, Mitsubishi, Omron, Beckhoff and Inovance, and what separates them on a migration is not processor performance. It is six ownership questions, and all six are answerable before a quotation exists.
| What actually decides the platform | What to ask for | Why it decides |
|---|---|---|
| The existing plant standard | Which platform your maintenance team is trained on, and what is in the store today | A fault on night shift is handled by whoever is on site, with whatever is on the shelf |
| How many toolchains the machine creates | The list of software needed to open every programmable device on it, including drives, robot and operator panel | Each extra toolchain is a licence, a trained person and a support route for the life of the machine |
| Who can open the program afterwards | Handover unlocked, with the project file and the symbol names intact | A machine nobody can edit is a machine that gets replaced |
| Whether named user accounts are required | Whether the platform holds accounts at all, and where a change to one is recorded | That capability is chosen at platform selection and cannot be configured in afterwards |
| Where the motion sits | Whether every axis on the machine is covered by one platform or needs a second | Motion is what usually forces a mixed-vendor machine, and that belongs in the decision |
| Spares route and lead time | Local stock and quoted lead time for the controller, the I/O modules and the drives, from the distributor who would actually supply them | A lead time on a failed input card is a production decision |
Two cautions on using that table.
Mixed-vendor machines are legitimate, and they are also a decision. A machine whose operator panel comes from one vendor and whose motion control comes from another can be sound engineering, and it is also two development tools, two spares chains and two support routes for whoever owns the machine afterwards. Decide that deliberately at platform selection.
And lifecycle status is a per-part question. Ask your vendor in writing for the published status of the controller, the I/O modules and the communications cards separately, because the case that becomes a second project is a supported processor sitting in a chassis full of modules that are not. Those dates also set your real patching horizon, so they belong in the handover pack next to the firmware versions.
A Siemens vs Allen-Bradley migration comparison should use the same machine behaviour, I/O and maintenance tasks. Where coordinated drives influence the destination platform, compare EtherCAT and PROFINET on the exact controller and device support.
How Do You Set the Right PLC Upgrade Scope?
Diagnose the failed component. Check whether the fault originates in the controller, drive, HMI, sensor or wiring. A targeted repair can restore production while a planned migration addresses lifecycle and future requirements.
Compare supported upgrade routes. Where the original builder offers an upgrade, include its sequence knowledge, source access, commissioning window and support package in the comparison with a new implementation.
Quantify the lifecycle driver. Review spare-part availability, lead times, network requirements, data needs and expected product changes. The resulting outage exposure and functional gains establish the timing and value of a migration.
Include mechanical condition. Measure repeatability and lost motion where accuracy is the complaint. Plan any mechanical work alongside controls commissioning and test both against the required part quality.
Start from your group standard. Bring the approved controller platforms, software tools and support requirements to concept review. They guide component selection, program structure and the handover package.
Compare replacement where the process has changed. Evaluate a standard or custom replacement against the migration scope using the same output, changeover and acceptance requirements.
What Should You Have Ready Before Asking for a Number?
Six items, in the order they change the answer. The first three decide the strategy and the last three decide the window.
- The controller make, model and vintage, with the I/O module list and the communications cards, plus the vendor’s published lifecycle status for each if you have it.
- Whether program source is available, and whether anyone has confirmed the file on the shelf matches the controller. If not, the recovery phase above is the first thing to price.
- Where the safety functions live, meaning hardwired, inside the standard PLC, or in a dedicated safety controller, and whether any register or performance level calculation exists.
- The drive and motor list, and whether the motors are being kept.
- What the operator interface carries beyond buttons: recipes, format settings, process programs, and whether named user accounts are required.
- The shutdown window, as hours, frequency, and whether the machine splits into stations that can transfer separately. That last part is what makes the phased strategy possible or impossible.
A replacement controller or drive also changes the cabinet layout. The industrial control panel enclosure guide checks installed depth, wiring access and heat losses before those changes consume the available space.
Standards Used in Machine Design and Validation
These references inform the design, testing and documentation described on this page. Each row links to its primary source and records the edition checked.
| Standard | Current edition | What it means for your machine |
|---|---|---|
| ISO 13849-1: Safety of machinery, safety-related parts of control systems | ISO 13849-1:2023 | Provides the design method for safety-related control functions, including architecture, component reliability, diagnostic coverage and common-cause failure measures. The machine risk assessment establishes the required Performance Level; design calculations and validation provide the evidence for each function.Checked 1 Sep 2026 against ISO 10218-1:2025 normative references |
Frequently Asked Questions
Can you convert our existing program to the new platform automatically?
Conversion tools exist for the mainstream platform pairs and we use them, but as a reading aid. What a converter moves is rungs, addresses and timers. What it cannot move is intent, so the workarounds the old platform forced on whoever wrote it come across intact and are now permanent: a timer standing in for an instruction the old processor did not have, logic that depends on scan order, addressing that encoded a physical rack layout. The output also reads like neither platform, so the maintenance team inherits code nobody can follow. Where a converter earns its cost is inventory and cross-checking.
How much of a PLC migration is downtime, and how much is engineering?
They are different numbers and they are not proportional. Panel build, program writing and testing against simulated I/O happen while the machine keeps producing. The shutdown window carries isolation and strip-out, mounting, re-termination, point-by-point I/O proving, a dry cycle without product, safety validation and a product trial. Point-by-point proving is the item that overruns, because it scales with the I/O count and cannot be parallelised beyond the number of people who can safely work in one panel at once. Which of the four migration strategies you choose changes the shape of that window more than the choice of controller does.
Do we have to change platform, or can we stay on the one we run today?
We ask which platform your plant already runs before selecting anything, and when two platforms both clear the technical requirements the existing standard wins on cost of ownership, because spares, training and support already exist. Changing platform is a purchase in its own right: a second programming toolchain to licence, a second spares holding, a second support route, and a maintenance team reading unfamiliar code during a breakdown. What overrides that is evidence, and the evidence is lifecycle status for your exact catalogue numbers, in writing from the vendor, covering the controller, the I/O modules and the communications cards separately. Where the platform you already run clears that test, staying on it is the cheaper machine to own.