Can a Different PLC Family Run Your Existing Program Without a Rewrite?

Can a Different PLC Family Run Your Existing Program Without a Rewrite?

We are an independent distributor of industrial-automation components (not an authorized distributor) sourcing out of China for overseas panel shops, OEMs, plant MRO and repair shops — including buyers in Moscow, the Russian regions and the wider CIS. A different PLC family almost never runs an existing program without rework, even within the same brand. We read the original program, the I/O map and the candidate datasheet side by side and tell you line by line what changes, what is unknown, and what must be re-engineered.

This is a methodology piece, not a cross-reference chart. If you have already chosen the candidate family and only want a per-axis comparison, the cross-reference workflow lives at /compare and the procurement intake is at /procurement. The piece below explains why "same brand, same vendor, surely the program moves" is the most expensive assumption in a PLC migration — and what a sourcing desk does to keep that assumption from costing you a line stop.

Why this question comes up — and what the buyer's first message actually looks like

The buyer who asks this is almost never a software engineer with time on their hands. They are a maintenance lead, a panel builder, or a procurement officer whose production line is down, whose preferred PLC is out of stock at twelve-week-plus lead time, and whose engineering team has quoted four to eight weeks for a program rewrite. The Russian-language version of the question is just as direct as the English one: «Можно ли заменить ПЛК одного производителя на другой без переписывания программы?» and «Чем заменить снятый модуль ввода-вывода?». Both reduce to the same engineering reality: the controller that ships in the next three weeks has different instruction names, different memory layouts, different I/O addressing, and a different engineering environment than the one sitting in the cabinet.

We see four concrete triggers for the question:

• A discontinued CPU (the classic case — Omron CP1E, Siemens S7-300, Mitsubishi FX3U) is no longer available, and the successor platform exists but the program does not move across.
• A current family has allocation pressure and the next-higher family is the only one in stock.
• A buyer wants to consolidate two different PLC brands in the same plant onto one platform and is looking for a way to keep the legacy program running on the new platform.
• A repair shop has a customer who insists on "the same part" and the same part is not in the channel — the shop needs to know whether a successor family can be made to look like the original to the program.

In every one of these cases, the question is real and the answer is almost always partial. The rest of this article explains what "partial" means and where the line is between "candidate, with caveats" and "do not migrate this family pair at all."

What "running the existing program" actually means

A PLC program is not a single file that "runs." It is a stack of interlocking artefacts:

• The application logic itself — ladder, structured text, function blocks — written in the engineering environment of the original family (CX-Programmer for Omron CP1E, STEP 7 for S7-300, GX Works for Mitsubishi FX3U).
• The I/O address map — which input and output bit is wired to which terminal on which module.
• The memory map — data registers, holding registers, timers, counters, retentive areas — and the implicit conventions the original programmer relied on.
• The instruction set and library of function blocks — including any vendor-specific blocks, motion blocks, or PID blocks.
• The hardware configuration file — rack or slot layout, module types, firmware versions.
• The communication configuration — serial port settings, Ethernet/IP or PROFINET device descriptions, peripheral device addresses.
• The HMI tag database, the SCADA tag database, and any historian that points at the original memory layout.

For an Omron CP1E to "run its existing program" on a CP2E, NX102 or NJ101 controller, every one of those artefacts has to be either compatible, translatable, or rebuilt. A program porting tool will convert the application logic; it will not convert your engineer's habits, your customer's commissioning checklist, or the labels on the HMI.

When a buyer asks us "can the new PLC run my program?", the honest first sentence of the answer is: which part of the program, on which firmware, against which engineering revision, with how much time on the bench? Without those four pieces of context, the answer is a guess.

What a sourcing desk can and cannot tell you

Here is the boundary we draw in writing on every quote and every program-migration conversation:

What we can do

• Read the original manufacturer datasheet for the original PLC family and the candidate family side by side, axis by axis. We use the twelve-axis framework that the engineering community has converged on: form and mounting, dimensions, terminal and interface assignment, electrical parameters, function and I/O specification, firmware and engineering-software compatibility, communication protocol, mechanical parameters, environmental class and EMC, ingress protection and temperature, materials and construction, certifications and lifecycle.
• Tell you, axis by axis, whether the candidate matches, differs, or is unknown because the manufacturer does not publish the data for the specific revision you hold.
• Tell you which axes we cannot verify at all from a datasheet — usually the firmware-version axis and the certifications-lifecycle axis — and recommend bench work to close those.
• Source the candidate controller per line, with the condition of each unit (new, new surplus, refurbished, used) written on the quote so your engineering team knows what is going onto the bench.
• Aggregate the I/O, power supply, communication module and any required battery or memory-card accessories into a single consignment, so the migration kit ships as one shipment rather than seven.

What we cannot do

• Sign off that the candidate "runs the existing program." That conclusion belongs to your engineering team after bench testing.
• Convert the program for you. We are a sourcing desk, not a systems integrator.
• Recreate your HMI tags or SCADA database. The tag database has to be re-pointed by whoever owns the SCADA project.
• Provide a safety-integrity conclusion. Functional safety (SIL/PL) compatibility is a customer engineering decision; we do not substitute on safety circuits.
• Claim that any platform migration is a verified direct controller swap with no rework. That kind of equivalence is reserved by the framework for documented cross-references where the manufacturer itself publishes the equivalence, and that almost never exists between two distinct PLC families.

If you are weighing this question on a production line, take the boundary above to your engineering lead before you talk to us. It saves a round of e-mail.

The three-axis minimum that decides most migration outcomes

If a buyer pushes back and says "give me the short version", the short version is three axes:

1. Firmware and engineering-software compatibility. This is the axis that decides whether the existing program text is readable on the new platform. Even within the same brand, a controller from a different family ships with a different engineering environment. Omron's CP1E programs are authored in CX-Programmer; CP2E programs are authored in CX-Programmer as well, but the supported instruction set differs and the I/O comment handling changes. CP1E programs do not open directly in Sysmac Studio, the engineering environment for the NX/NJ series. A program-migration tool can convert a CP1E project to a CP2E project with limitations; the same tool does not produce a runnable NX102 project from a CP1E project. Always verify against the original manufacturer datasheet and your own qualification process.
2. I/O address map. A CP1E program refers to inputs as CIO 0.00, outputs as CIO 100.00, and so on. A CP2E program uses the same conventions, but a CP1E program does not natively run on an NX102, which uses different variable names tied to the EtherCAT or EtherNet/IP slave configuration. If your HMI or SCADA is hard-coded to the CIO addressing scheme, the migration has to either replicate the CIO mapping on the new platform (often possible on CP2E with the right configuration, not possible on NX/NJ) or rewrite the HMI tag database.
3. Communication protocol. A machine built around a CP1E with a serial option board (RS-232C or RS-485) does not become a machine built around an NX102 with EtherCAT slaves just because the brand is the same. The communication wiring is different. The peripheral devices, the baud rates, the device-description files are all different. A program that polled a VFD over RS-485 Modbus on the CP1E will not poll the same VFD on the NX102 without re-engineering the comms block.

If those three axes work out for your application — firmware compatibility, I/O map translatable, communication path preservable — the migration is feasible with a controlled bench effort. If any of those three fails, the migration is "rewrite the program" or "don't migrate this one".

A worked example from the Omron CP1E → CP2E → NX102/NJ101 path

Because Omron CP1E series is the most common discontinued-controller request we see right now, here is the axis-by-axis view of moving a CP1E program to the next family. The verdicts below reflect the published datasheets; we mark every axis as matched, differs, or UNKNOWN in line with the framework, and we have not omitted any axis that the framework requires.

The CP1E → NX102 path is a different conversation. NX102 belongs to the NX/NJ platform, which is authored in Sysmac Studio, uses tag-based programming rather than the CP1E address-based scheme, and runs EtherCAT or EtherNet/IP for distributed I/O. A CP1E program does not run on an NX102. Migration from CP1E to NX/NJ is a full re-engineering project, not a "swap the CPU" project. We do not describe it as such.

Two situations where you should not migrate the family at all

There are two scenarios we flag in writing before we put a candidate on a quote.

Safety-rated logic on a CP1E. If the original CP1E CPU is wired into a safety circuit (a safety light curtain, a safety relay, an E-stop chain), the candidate controller has to carry the appropriate functional-safety rating and the wiring has to be re-engineered by a qualified safety engineer. We do not substitute on safety circuits. The candidates are: keep the original CP1E (we can source new-surplus or tested-refurbished units against our per-line quote for as long as the channel holds stock), or migrate to a controller family that the safety circuit is documented against, with a full re-engineering pass. There is no third path that we will offer.

A program that depends on a CP1E-specific function block the successor family does not implement. Some CP1E programs use vendor-specific blocks — for example, the Modbus-RTU easy master function block for a specific option board, or a particular high-speed counter setup, or a custom protocol block written in ladder. A candidate that does not implement that function block, or implements it under a different name with different parameters, is not a candidate. We will tell you in the quote that the function block is unverified, and we will recommend bench verification or a different candidate.

What we put on the quote — and what we do not

Every quote we send for a PLC-family migration includes, on a per-line basis:

• A per-line listing of the candidate controllers, with the manufacturer part number, the condition of each line (new, new surplus, refurbished, or used), and any bench-test record we hold for the specific unit.
• A per-line listing of the I/O modules, power supplies, communication modules, batteries and memory cards that the candidate requires to function in the same role as the original.
• An explicit "unverified" column for axes that we could not confirm against the published datasheet — usually firmware-version and certifications-lifecycle.
• A statement that the program-porting work is the customer's responsibility, and that the bench verification is the customer's responsibility.

What we do not put on the quote:

• A promise that the program will run on the new controller without rework.
• A fixed engineering-effort figure. We do not estimate engineering hours; we source parts.
• A functional-safety conclusion. That belongs to the customer's safety engineer.
• A compliance statement of any kind. We do not hold EAC or TR CU certification, and we do not provide compliance opinions; final compliance against Russian or CIS market regulations is the customer's responsibility, with documentation supplied by the manufacturer of the finished equipment.

Condition honesty on every line

A migration often pulls in a candidate controller that the channel only carries as refurbished or used. The condition of each line is not an aggregate statement about the order — it is per line. A quote might show one line as "refurbished, bench-tested against the manufacturer diagnostic checklist, 90-day bench warranty stated on the quote", another line as "new surplus, sealed original packaging, no bench warranty because the original manufacturer warranty window has closed", and a third line as "used, removed from a working panel, no bench warranty". The reason the conditions differ per line is that the channel available, the part number, and the manufacturer's current warranty position differ per line. We do not mix those three conditions into one statement. Per-line condition is written on every quote we send.

We screen end users and end uses, classify before quoting, and decline transactions that cannot be screened.

How a typical inquiry reaches a quotation

A buyer who is migrating a CP1E panel sends us an inquiry that typically includes:

• The original manufacturer part number of the CPU and any expansion I/O.
• A description of the application (machine type, I/O count, communication, HMI).
• The candidate family the engineering team is considering, or a request for our suggestion.
• The bench-test equipment and engineering environment the customer has available.

We reply, in English or in Russian where the inquiry is in Russian, with: a confirmation that we can source the candidate per line, a list of unknown axes, a recommendation on bench verification, and a quotation for the candidate controllers and accessories as a single consolidated consignment. Delivery to Russia is arranged under EXW, DAP or DDP where the quotation states it — we do not commit to a fixed assurance of transit time and we do not operate a dedicated consolidation lane; the terms on the quote are the terms.

Frequently asked questions

Can an Omron CP1E program run on a CP2E controller without a rewrite?

Not without rework. CX-Programmer supports a manual conversion path from a CP1E project to a CP2E project, but I/O addressing, function-block availability and instruction-set differences mean that the project has to be reviewed line by line, bench-tested, and validated against the specific CP2E CPU part number. The datasheet is the contract; we provide the comparison per line and the bench verification is yours.

Can an Omron CP1E program run on an NX102 or NJ101 controller?

No. CP1E programs run in CX-Programmer against an address-based I/O scheme; NX102 and NJ101 programs run in Sysmac Studio against a tag-based scheme with EtherCAT or EtherNet/IP distributed I/O. The migration is a full re-engineering project, not a controller swap. We will tell you this in the quote if the candidate you propose is an NX/NJ, before the order is placed.

What if the same brand sells a "migration kit" or "migration guide" for the transition?

If the manufacturer publishes a documented migration guide — for example, a CP1E to CP2E migration manual with a conversion table — we treat that guide as the contract. We still flag every axis we cannot confirm against the guide and we still recommend bench verification. If the manufacturer does not publish a migration guide for the family pair, we mark the firmware-version axis as UNKNOWN in the comparison and we recommend that bench verification take precedence over the quote.

If we accept a candidate controller on the quote, do you also port the program?

No. We are a sourcing desk, not a systems integrator. We deliver the controller, the I/O, the power supply, the communication modules, and the accessories consolidated into one shipment. The program port is the customer's responsibility, performed by the customer's engineering team or by a qualified integrator of the customer's choosing.

What about the HMI tags and the SCADA database?

The HMI tag database and the SCADA database are tied to the original controller's memory layout. If the memory layout changes — and it does change when the family changes — the tags have to be re-pointed. We do not own that work. If your engineering team needs a hand with the HMI side, we can suggest a separate systems integrator; that engagement is not part of the parts quote.

Is it ever acceptable to mix families within one panel during a migration?

Sometimes, for a defined transition period. We have seen panels run a current CP2E CPU with a CP1E expansion rack as a temporary configuration while the application is migrated. The combination requires care: the I/O backplane, the power budget, and the cycle time all need re-validation. We will quote the configuration if the customer specifies it, and we will mark it as a temporary configuration in the quote.

How is the migration candidate quoted if it is not in stock at franchised channels?

We source per line from independent channel inventory: manufacturer-distributor surplus, panel-shop de-stocks, integrator decommissions, and tested-refurbished returns. Each line carries its own condition. The quote states the condition per line, not per order, and the bench-warranty window (if any) per line. Where the inventory does not support the candidate at all, we will say so in the quote rather than substitute a different candidate silently.

Closing

If you are weighing a PLC-family migration and want a per-axis, datasheet-grounded read on whether the candidate can take the program — or a quote for the candidate controllers and accessories on per-line terms — send us your BOM with the original manufacturer part number, the candidate family the engineering team is considering, and the application description. Contact our sourcing desk through /inquiry or upload the BOM at /procurement for a per-line quote. We will reply with a comparison table, an explicit list of the axes we cannot confirm, and a quote for the parts. The program port and the bench verification stay on your side of the table, where they belong.

By the aoctrl sourcing desk. As of September 2026.

Data Notes

• Omron CP1E series — product family page on the Omron Industrial Automation portal, last consulted for this article in September 2026.
• Omron CP2E series — product family page on the Omron Industrial Automation portal, last consulted for this article in September 2026.
• Omron NX/NJ series — Sysmac Studio environment documentation on the Omron Industrial Automation portal, last consulted for this article in September 2026.
• CX-Programmer manual — Omron documentation for CP1E and CP2E engineering environment, last consulted in September 2026.
• No independent distributor claim is made about any of the manufacturers named above. Verify against the original manufacturer datasheet and your own qualification process.