Mitsubishi FX3U to FX5U Migration: 12-Axis Cross-Reference

Mitsubishi FX3U Discontinued: Can the Existing Program Move to FX5U Without a Rewrite

Same-brand does not mean same-program. An FX3U program can usually be carried across to an FX5U with the manufacturer's own migration tool, but the result needs an engineering review — the tool does not catch every instruction-set difference, and firmware version on the new module has to match what the migrated program expects. The verification work belongs to your engineering team.

FX3U End-of-Life Is Already a Cabinet Problem, Not Just a Catalog Problem

The FX3U series entered the discontinuation window several years ago, and the practical effect on a working machine is now showing up as a stock problem rather than a notice. A panel shop running a 2014-era packaging line in Moscow or a bottling line in the Urals often opens a control cabinet to find an FX3U-32MR or FX3U-48MR on the DIN rail and discovers that the franchised channel no longer holds stock at all. The line is running today; the spare in the drawer is the spare — there is no replacement behind it.

Three paths are realistic for the buyer in that position, and they are not equal:

Remaining channel stock — surplus FX3U CPUs, I/O and special-function modules still turn up through non-franchised desks, mostly tested-refurbished units pulled from decommissioned equipment. Condition varies from one unit to the next; pricing varies with what the unit is and where it came from. It is the route that keeps the existing program and the existing wiring intact.
Migration to FX5U — the manufacturer publishes a documented migration path, the engineering software is updated, and a new module sits on the same DIN rail. The cabinet wiring may or may not carry over, and the program may or may not run unchanged. This article is mostly about this route.
Cross-brand swap — replacing Mitsubishi with another manufacturer's PLC family. Outside the scope of this piece because it adds a further set of axes to verify; it deserves its own article.

The hard part is that none of these three paths is a clean "yes". They each carry their own work, and which one you choose depends on what is most expensive for you — a longer cabinet downtime, a program rewrite, or a redesign of the whole control section.

What the Migration Question Actually Looks Like

The buyer's question, in the form it most often arrives in our inbox, is something like this:

«Можно ли заменить FX3U на FX5U без переделки шкафа?»

— that is, can the FX3U be replaced with an FX5U without reworking the cabinet? A second form, sometimes from a different engineer on the same project, asks the program angle instead:

«Mitsubishi FX3U снят — чем заменить без переписывания программы?»

— FX3U is discontinued — substitute without rewriting the program.

Both questions are reasonable. The reason they are hard to answer with a one-word yes is that "same brand" and "same family spirit" are not the engineering argument. The FX3U and FX5U are programmed in different engineering software versions, the FX5U has its own instruction-set differences, the I/O terminal assignment shifts on several suffixes, and the FX5U's transistor-output modules are not interchangeable with FX3U's relay-output modules at the wiring end. Same brand; same DIN-rail width in many cases; same general purpose. That is not the same thing as "the program will run unmodified."

A further source of confusion: the FX5U does not exist as a single product. It is a family — FX5U-32MT/DS, FX5U-32MT/ESS, FX5U-32MR/DS, FX5U-64MR/DS, FX5U-80MR/DS, FX5UC-64MT/D and so on — and the suffix encodes the I/O mix, the supply voltage, the output type (transistor vs relay) and the engineering-software generation. "FX5U" as a search term is not specific enough to identify a replacement for a given FX3U on the cabinet drawing; you need to match the I/O count and the output type before you can even start the firmware question.

The Twelve Axes, Filtered to This Swap

The cross-reference framework used across this site lays out twelve axes that have to be looked at before any industrial-automation substitution is declared compatible. On the FX3U to FX5U swap, four of them do most of the work and several others must be reported as unknown because no supplier — independent or otherwise — can answer them without seeing your program.

Firmware, hardware version and engineering-software compatibility — the dominant axis on this swap. The FX5U runs GX Works 3; the FX3U was programmed in GX Works 2. The migration tool (a separately published utility) handles most instructions and most function blocks, but it does not handle every legacy instruction, and custom function blocks written by your engineering team need manual review. Hardware version and FS state of the new module have to match what the migrated program expects.
Function and I/O specification — I/O count has to match the program logic. An FX3U-32MR (16 inputs / 16 relay outputs) maps to an FX5U-32MR/DS at the count level; the relay vs transistor output type is a separate question. If your program relies on the relay outputs' dry-contact behaviour for any interlock, the FX5U-32MT/DS (transistor outputs) is not equivalent regardless of I/O count.
Terminal and interface assignment — the FX5U terminal numbering on several suffixes differs from the FX3U even when the module width is the same. Wiring diagrams for the FX3U do not transfer to the FX5U without review.
Communication protocol — built-in Ethernet on FX5U differs in default addressing and supported protocol family from FX3U's serial and any FX3U-ENET add-on. Any HMI, SCADA or inverter that talks to the existing FX3U over its native port needs reconfiguration.
Form / fit outline and mounting — DIN-rail mounting is the same. Module width is the same on the most common FX3U-32M and FX5U-32M pairings. Depth can differ; verify against the datasheet for the specific suffix.
Electrical parameters — supply voltage range differs on the AC-supply FX5U variants; I/O channel ratings are similar but not identical. Verify against the specific suffix datasheet.

The remaining six axes — dimensions in detail, mechanical parameters, environmental class, ingress and temperature, materials, certifications and lifecycle — are usually matched or carry over cleanly between FX3U and FX5U on a same-cabinet, same-environment swap. Each of them is still checked in the comparison; none of them is the axis that breaks the program. If any of these six does turn out to differ on a specific suffix pair, the substitution moves from a programmable migration to a cabinet redesign and that is a different project.

The axes we cannot verify without seeing your program and your installation are: the program portability itself (firmware_version), any safety-function scope carried by the FX3U program (certifications_lifecycle), and the specific custom function blocks your engineering team may have written. These are reported as unknown in any cross-reference we issue. They are the axes a supplier — this one included — has no business claiming a yes or no on.

Matched, Differs and Unknown: How to Read the Comparison Honestly

A clean cross-reference for an FX3U to FX5U migration looks like this in practice, on the axes that matter:

Firmware_version — differs. The FX3U program runs in GX Works 2; the FX5U runs GX Works 3. The migration tool bridges the common instruction set and most function blocks. Vendor-specific instructions and any custom function blocks are flagged for manual review.
Engineering software generation — differs. The engineering team needs GX Works 3 licences and a migration-tool licence; the old GX Works 2 project does not open directly in GX Works 3 without conversion.
I/O count and type (matched suffix pair) — matched on the count (FX3U-32MR to FX5U-32MR/DS, for instance); differs on output type if the original was relay and the candidate is transistor.
Terminal assignment — differs on most suffix pairings. Verify against both datasheets; do not transfer the FX3U wiring schedule.
Communication, built-in Ethernet — differs. Address range, default port and supported protocol family differ between FX3U-ENET and FX5U built-in Ethernet. HMI/SCADA configuration needs updating.
Mounting, DIN rail — matched. Module width is the same on the common 32-point pairings.
Environmental class, IP rating, temperature range — matched on same-cabinet, indoor industrial use.
Lifecycle — FX3U is discontinued; FX5U is current. The substitution is in the direction that the manufacturer intends to support.

What we cannot honestly answer without seeing your project: whether any given FX3U instruction in your specific program survives the migration tool's conversion unchanged; whether any safety interlock in your program is implemented in a way that the FX5U's instruction set handles identically; whether any HMI/SCADA tag database on the existing installation re-binds without manual remapping. These are reported as unknown in any cross-reference we produce, and the instruction at the bottom of the document reads:

Verify against the original manufacturer datasheet and your own qualification process.

That sentence is not a disclaimer — it is the engineering instruction. The migration tool gets you most of the way; your engineering team has to verify the last part.

When the Migration Is the Wrong Answer

The FX3U-to-FX5U route is right when the FX3U stock has dried up, the program is migrating cleanly, the engineering team has access to GX Works 3 and a migration-tool licence, and the cabinet can be reworked without changing the machine's safety scope. There are cases where the migration route is the wrong choice even when all of those are true, and cases where it is the wrong choice because one of them is not.

Safety functions. If the FX3U program participates in a category-stop circuit, a light-curtain interlock, or a two-hand control, the migration changes the program and therefore the safety-function validation. Treat the migration as a safety-relevant change; have it reviewed by the engineer responsible for the machine's safety scope, not by a parts supplier.
Programs that rely on legacy-specific instructions. Some FX3U programs use instructions that the migration tool cannot convert or that the FX5U instruction set handles differently. If your program has not been audited against the FX5U instruction set, the result of the migration is unknown until that audit is done.
Custom function blocks written against GX Works 2 libraries. These usually convert, but the converted block needs a manual review to confirm it does what the original did. Skipping this review is the most common way a migration "works in the lab and breaks on the floor."
Cabinets where terminal rework is not feasible. If the cabinet cannot be reworked — depth, wiring schedule, panel-builder constraints — the cabinet rework itself becomes the cost driver. In that case the more economic answer may be to keep sourcing tested-refurbished FX3U modules until a full redesign window opens.
Cross-brand scope. If the question has moved beyond Mitsubishi (the buyer is considering switching to a Siemens S7-1200 or an Omron CP1E family, for instance), the cross-reference work expands significantly. That is a different article.

The migration is also the wrong answer if the line is going to be redesigned in the next 12 months anyway — at which point the migration becomes a throwaway cost and the right answer is to skip directly to the redesign.

What an Independent Distributor Actually Does on This Swap

The role of an independent China-based sourcing desk on an FX3U-to-FX5U migration is narrower than the buyer's first email suggests, and that is the point. We do not program, we do not certify conversions, and we do not run a migration-tool project on the customer's behalf. What we do, on this kind of inquiry, is the part of the work that fits a parts-supplying desk:

Identify the FX5U suffix that matches the existing FX3U. I/O count, output type (relay vs transistor), supply voltage and engineering-software generation are matched to the original module before any cross-reference is written.
Source the FX5U modules in the condition the buyer wants. New, new-surplus, tested-refurbished or used — condition is disclosed per line, not summarised across the lot. The FX5U-32MT/DS, FX5U-32MT/ESS, FX5U-32MR/DS, FX5U-64MR/DS, FX5U-80MR/DS, FX5UC-64MT/D and FX5 special-function modules (FX5-20PG-P, FX5-20PG-D, FX5-4LC, FX5-ENET) all turn up through the channels we work with; availability, MOQ and lead time are quoted per line.
Source the FX3U spares if the buyer chooses the remaining-channel-stock path. Tested-refurbished FX3U CPUs, I/O and special-function modules still come up; condition is disclosed per unit; per-line photographs are sent before dispatch.
Issue a written cross-reference note. For BOM work we return a line-by-line comparison on the twelve axes with the unknown ones named; we do not issue a compatibility certificate, because we are an independent distributor and cannot certify a substitution on a manufacturer's behalf. The verification work belongs to the buyer's engineering team.
Consolidate across lines and across suppliers. Several FX5U modules, FX5 special-function modules, and any third-party I/O or HMI in the same consignment are sourced from the appropriate channels and shipped as one dispatch with one set of documents.

The cross-reference note itself is what the buyer's engineering team uses to drive the migration-tool project. It is not the migration; it is the input to the migration.

How the Inquiry Usually Runs From the First Message to the Cabinet

A typical FX3U-to-FX5U inquiry from a panel shop or an MRO team runs in roughly this shape. The first message contains the existing FX3U MPN (or a photo of the marking on the module), the existing I/O configuration if it is known, and a one-line statement of the situation — machine down, planned retrofit, or new design that has to reuse an existing program. From there the work proceeds in steps rather than in a single back-and-forth.

The first reply identifies the FX5U suffix that matches the I/O count and output type, with the engineering-software-generation question flagged for confirmation. Once the buyer confirms the migration target, the FX5U modules are sourced and quoted per line, with MOQ, lead time and condition disclosed on each line. Per-line photographs are sent before dispatch on used and refurbished items.

The cross-reference note is issued alongside the quotation, on the axes that matter for this swap: firmware_version (differs, with the migration-tool caveat named), function_io (matched on count, output-type caveat named), terminal assignment (differs, verify against both datasheets), communication (differs on built-in Ethernet), mounting (matched), electrical (verify against suffix datasheet), environmental and lifecycle (matched). Axes the note cannot verify without seeing the program are reported as unknown.

The consignment consolidates the FX5U modules with any other lines on the buyer's list — terminal blocks, power supplies, an HMI, I/O slices — into one dispatch. Where the buyer is in Moscow, the regions of the Russian Federation, or a CIS country, delivery is arranged under the commercial terms stated on the quotation. We screen end users and end uses, classify before quoting, and decline transactions that cannot be screened. EAC and TR CU conformity is not issued by an independent sourcing desk and must be addressed by the importer on its side of the border; the procurement documentation we provide is a commercial invoice and a packing list.

The Takeaway

An FX3U-to-FX5U migration is doable, but it is not "swap and go." The hardware is on the DIN rail; the engineering-software generation, the program instructions and the wiring schedule all need engineering review before the cabinet comes back up. Send the existing FX3U MPN (or a photo of the marking) together with the I/O configuration and any output-type constraint, and the cross-reference can be written on the axes that matter. The verification — the part that determines whether the program actually runs on the new module — is the engineering team's work, not the supplier's, and any supplier that tells you otherwise is guessing.

Send us your BOM and the FX3U MPNs and we will return a line-by-line cross-reference and a per-line quote for the FX5U replacement, with condition disclosed on every line. The first cut usually arrives the same working day.

By AO Control, independent China-based sourcing desk — industrial automation distributor and sourcing desk for overseas panel shops, machine OEMs, plant MRO teams and repair shops, including buyers in Russia and the CIS. last updated 2026-09-29. Data through September 2026.

Data Notes — what this article is grounded on, and what it is not

Catalog grounding. Mitsubishi FX5U-32MT/DS, FX5U-32MT/ESS, FX5U-32MR/DS, FX5U-64MR/DS, FX5U-80MR/DS, FX5UC-64MT/D, FX5-20PG-P, FX5-20PG-D, FX5-4LC and FX5-ENET modules are present in the cross-reference page and in the published product index. Suffix pairings are matched against the published module listings; specific suffix-to-suffix compatibility has to be verified against the original manufacturer datasheet and your own qualification process.
Program portability. The claim that the manufacturer's migration tool handles most instructions and most function blocks is grounded in the published GX Works 3 release notes. The claim that legacy-specific instructions and custom function blocks need manual review is grounded in the same source. Any specific program's portability is reported as unknown until your engineering team has run the migration tool against that program.
Lifecycle. The claim that the FX3U series is in the discontinuation window and the FX5U is the documented migration target is grounded in the manufacturer's published product catalogue pages for the two families.
No fixed lead time, no fixed price. Delivery windows and per-line pricing are quoted per order; nothing in this article constitutes a service guarantee on either.
No certification claim. The desk is an independent China-based sourcing desk and is not an authorized distributor of any manufacturer. EAC and TR CU conformity is not issued by the desk; that is the importer's responsibility on its side of the border.

Dateline: as of September 2026 — Shenzhen, China. Cross-references in this article reflect the framework used across the site's compare work; specific module pairings depend on the suffix on the cabinet drawing and on the program in your engineering team's hands. Verify against the original manufacturer datasheet and your own qualification process before any cabinet is re-energised.

FAQ

Can an FX3U program run on an FX5U without rewriting anything?

Usually not without some conversion. The FX3U was programmed in GX Works 2 and the FX5U runs GX Works 3; the manufacturer's migration tool handles most instructions and most function blocks but does not catch every legacy instruction, and any custom function blocks written for the FX3U need a manual review. Treat the program portability as an engineering question that belongs to your team, not as something a parts supplier can answer for you.

Which FX5U suffix replaces a specific FX3U module?

Match the I/O count and the output type first. An FX3U-32MR (16 inputs / 16 relay outputs) maps to an FX5U-32MR/DS at the count level; if the original relied on the relay outputs' dry-contact behaviour, the FX5U-32MT/DS (transistor outputs) is not equivalent regardless of the I/O match. Supply voltage and engineering-software generation are checked against the cabinet drawing before any suffix is named.

Is it cheaper to keep sourcing FX3U modules than to migrate?

Sometimes, yes — particularly when the program is stable, the cabinet cannot easily be reworked, and the engineering team's time is the most expensive resource on the project. Tested-refurbished FX3U CPUs, I/O and special-function modules still come up through non-franchised channels. The break-even between continued FX3U sourcing and a migration depends on how many spare units the line will need over the next few years and how confident the engineering team is that the migrated program will run without a long commissioning loop.

What about cross-brand swaps — moving from FX3U to a Siemens S7-1200 or an Omron CP1E?

That is a different project and a different cross-reference. Same-brand migration (FX3U to FX5U) already has a manufacturer's migration tool; cross-brand migration does not. Engineering effort, cabinet rework and qualification all expand. For inquiries where the brand is open, we work through the substitution axes on the destination family before any hardware is quoted.

Do you handle cross-border delivery of FX5U modules to Russia and the CIS?

Yes. Delivery is worldwide, including Moscow and the regions of the Russian Federation, and we also serve buyers in Belarus, Kazakhstan, Uzbekistan and Armenia. The commercial terms for a specific consignment — EXW, DAP or DDP — are stated on the quotation. We screen end users and end uses, classify before quoting, and decline transactions that cannot be screened. EAC and TR CU conformity is not issued by an independent sourcing desk; that is the importer's responsibility on its side of the border.

What condition are the FX5U modules supplied in?

Condition is disclosed per line on the quotation — new, new-surplus, tested-refurbished or used — and is not summarised across the lot. Tested-refurbished modules come with a bench test record; used modules come with a photograph of the marking and the unit. The condition of each line is something the buyer can confirm before dispatch on used and refurbished items.

Can the migration be done without taking the cabinet offline?

Not safely. Even on a same-brand migration where the terminal layout carries over, the wiring schedule usually has to be reviewed and a function test has to be run before the line goes back into production. A planned downtime window — even a short one — is part of the migration cost. A "swap during a coffee break" approach is the failure mode the migration tool's existence is meant to discourage.