MELSEC-Q to iQ-R Migration: Step-by-Step

By Abdullah Zahid
25 min read
Mitsubishi Electric MELSEC-Q Series and MELSEC iQ-R Series PLC modules side by side for migration planning

MELSEC-Q to MELSEC iQ-R Series Programmable Controller Migration: Complete Step-by-Step Guide

Controls engineers and automation teams managing existing MELSEC-Q Series Programmable Controller installations are increasingly facing the same inflection point: Q-series hardware is entering its legacy lifecycle, and Mitsubishi Electric has established the MELSEC iQ-R Series Programmable Controller as the strategic successor platform. The decision is rarely whether to migrate, but how to do it without exposing production to unnecessary risk. This guide walks through every stage of that process — from hardware inventory and module mapping through GX Works2 to GX Works3 project conversion, network migration, phased implementation, and final commissioning — using Mitsubishi's official migration documentation as the technical foundation.

If your team is already shortlisting MELSEC iQ-R CPUs, base units, and modules for an upcoming project, check current pricing and availability at LeadTime.ca — ships worldwide.

Is Your MELSEC-Q System Ready to Migrate — and Are You?

This guide is written for engineering teams, system integrators, and OEM designers who are actively planning or evaluating a MELSEC-Q to MELSEC iQ-R migration. You are in the right place if:

  • Your Q-series hardware is at or approaching the manufacturer's lifecycle limits, or sourcing specific Q-series modules has become difficult
  • You need capabilities that Q-series cannot deliver — improved diagnostics, modern security, CC-Link IE or Ethernet-based networking, or higher integrated control performance
  • You are standardizing engineering tools on GX Works3 and aligning new and legacy projects on the iQ Platform
  • You are planning SCADA, MES, or OT network upgrades that are better supported by iQ-R architecture
  • You have access to Mitsubishi's official migration guides and module replacement lists and are ready to use them as the primary reference

If your Q-series system is stable, spares are available, and no performance or lifecycle pressure exists, a phased or deferred approach may still be appropriate. For systems with special Q-series modules that have no direct iQ-R equivalent, RQ extension base units provide a validated bridge — this guide covers that scenario in detail.

On this page:

What Is Actually Changing When You Move from MELSEC-Q to MELSEC iQ-R

The MELSEC-Q Series Programmable Controller has served as a capable modular PLC platform across process industries, discrete manufacturing, automotive, food and beverage, and material handling applications for many years. Mitsubishi Electric has positioned the MELSEC iQ-R Series Programmable Controller as the current flagship platform and provides a documented upgrade path, including an official "MELSEC-Q Series to MELSEC iQ-R Series Migration Guide" and module replacement lists that map Q-series components to their iQ-R equivalents or extension-base solutions.

The changes involved in this migration are not cosmetic. Five technical dimensions shift simultaneously:

  • The CPU platform and base unit architecture change — Q-series base units and iQ-R base units are not interchangeable, and slot arrangements differ
  • The engineering environment moves from GX Developer or GX Works2 to GX Works3, with a structured conversion procedure required for existing projects
  • Network architecture shifts toward CC-Link IE and Ethernet-based communications, away from MELSECNET and legacy fieldbus options that were central to many Q-series designs
  • The module lineup changes — some Q-series modules have direct iQ-R equivalents, others require retention via RQ extension base units, and some require functional redesign
  • Diagnostics, password protection, security features, and remote access capabilities are expanded in iQ-R compared to Q-series

Understanding these five dimensions before starting is what separates a controlled migration from an extended debugging exercise.

How to Audit Your Existing MELSEC-Q System Before Starting

No migration plan is reliable without a complete inventory of what exists. This step is not optional — it is the foundation on which hardware mapping, network planning, and project conversion all depend.

Start by cataloguing every MELSEC-Q component installed:

  • All Q-series CPUs by model, including standard CPUs, motion CPUs, and process CPUs, and their roles in the control architecture
  • All base units, extension base units, and power supplies
  • Every I/O module and intelligent module (analog, communication, positioning, instrumentation) with slot locations documented
  • All network modules and the networks they serve — CC-Link, MELSECNET/10, Modbus RTU, Ethernet, and any vendor-specific fieldbus
  • All GX Developer and GX Works2 project files, including ladder and structured text code, device comments, labels, and system parameter settings
  • All safety-related I/O, interlocks, and critical control loops that require functional safety re-validation if hardware changes

Export, archive, and verify all project files before any migration work begins. A missing or corrupted project file discovered after hardware removal is among the highest-risk situations an engineer can face on a migration.

System Audit Checklist

Audit Area What to Document Risk If Skipped
CPUs Model numbers, firmware version, program memory usage Incorrect iQ-R CPU selection, memory shortfall
Base units and racks Slot count, extension base connections, power supply ratings Physical incompatibility, power budget errors
I/O modules Signal types, channel counts, terminal types Wiring mismatches during replacement
Intelligent modules Model, function, parameter settings Parameter loss or misconfiguration after conversion
Network modules Network type, station addresses, connected devices Communication failure after migration
Project files GX Developer / GX Works2 project archives, version, comments Logic lost or unverifiable at conversion stage
Safety I/O Safety functions, interlock wiring, functional safety documentation Safety re-validation gap after hardware change

Official Mitsubishi Migration Resources and Tools You Need

Mitsubishi Electric provides a dedicated set of official documents for this migration path. Using community advice without cross-referencing these documents is one of the most common causes of mid-project surprises. The four core resources to obtain before designing any replacement architecture are:

  • The MELSEC-Q Series to MELSEC iQ-R Series Migration Guide — the primary reference covering recommended replacement CPUs, base units, modules, and migration procedures
  • The official Q-to-R module replacement list ("MELSEC-QシリーズからMELSEC iQ-Rシリーズへの置換え機種一覧") — a structured table of Q-series models and their corresponding iQ-R equivalents or extension-base solutions
  • The Migration Guide of Motion Controller [Q17nDSCPU] and equivalent documents for process CPUs — these cover special migration conditions that the general guide does not fully address
  • GX Works3 project conversion documentation — describing the procedure for opening GX Works2-formatted Q-series projects in GX Works3 and the checks required at each stage

Mitsubishi also provides a web-based migration selection tool that supports Q-to-R model mapping. This tool is a useful cross-check against the module replacement list, but the printed migration manual remains the authoritative reference for project decisions.

Step-by-Step Hardware Mapping: MELSEC-Q Modules to MELSEC iQ-R Equivalents

Hardware mapping is where the migration plan either holds together or begins to unravel. The objective is to match every Q-series component in your audit to one of three outcomes: a direct iQ-R equivalent, a retention via RQ extension base unit, or a functional redesign where neither of the first two options applies.

Mitsubishi's official module replacement list is the starting point for every mapping decision — not distributor catalogues, not community forums, and not assumptions based on similar part numbers. The list distinguishes between modules with confirmed direct replacements and those that require extension-base solutions or architectural changes.

Conceptual Hardware Mapping Table

Legacy Q Component Type Recommended iQ-R or R-Series Replacement If No Direct Equivalent: RQ Extension Base Solution Notes and Conditions
Q-series standard CPU CPU Corresponding R-series CPU (per manufacturer list) Not typically required for standard CPU Confirm program memory and instruction set compatibility
Q-series motion CPU Motion CPU R-series motion CPU or hybrid solution May require RQ extension base for retained Q motion modules Use dedicated motion migration guide; verify axis count and performance
Q-series process CPU Process CPU R-series CPU with process control functions May require intermediate conversion step Convert to universal model CPU before final iQ-R migration per guide
Q-series digital I/O module I/O Corresponding RX/RY iQ-R I/O module Retain via RQ extension base if required Verify terminal layout and connector type; rewiring may be required
Q-series analog module Intelligent Corresponding R-series analog module Retain via RQ extension base if no direct equivalent Review analog scaling parameters in GX Works3 after conversion
Q-series CC-Link master module Network R-series CC-Link IE master or CC-Link module Retain Q CC-Link module via extension base during transition Plan path to CC-Link IE; existing CC-Link devices can be retained short-term
Q-series MELSECNET module Network No direct iQ-R equivalent in most cases Retain Q MELSECNET module via RQ extension base Plan migration to CC-Link IE or Ethernet; design gateway solutions as required
Q-series Modbus RTU module Communication Limited direct equivalent on iQ-R Retain Q communication module via extension base or use gateway Community and official sources confirm this is a gap area; plan early

CPU and Special Module Mapping Overview

Legacy Q CPU Category Recommended R CPU Approach Special Migration Guide Required? Key Considerations
Standard Q CPU Direct R-series CPU replacement per manufacturer list No — general migration guide applies Confirm memory, instruction set, and parameter compatibility in GX Works3
Motion CPU (Q17n-series) R-series motion CPU or motion-capable R CPU Yes — dedicated motion migration guide required Axis count, response time, and positioning instruction set must be validated
Process CPU R-series CPU with process control capability Yes — process CPU migration guide required Intermediate conversion to universal model CPU may be required before iQ-R migration

Compatibility and Redesign Impact Overview

Function Direct Mapping Possible? Redesign Required? Impact Level Mitigation Approach
Standard logic and I/O Yes, in most cases No Low Use module replacement list; verify wiring and parameters
Motion control Partial — depends on model Sometimes Medium to High Use dedicated motion migration guide; pilot on non-critical machine first
Process control (analog, PID) Partial Sometimes Medium to High Follow process CPU migration guide; validate analog scaling and alarms
Legacy network (MELSECNET, Modbus RTU) No in most cases Yes Medium to High Use RQ extension bases, gateways, or plan phased CC-Link IE migration
Standard Ethernet communications Yes No Low Confirm IP addressing and protocol settings in iQ-R CPU built-in Ethernet

Base Units, Power Supplies, and RQ Extension Racks

Q-series base units and iQ-R base units are architecturally different. They are not interchangeable, and the slot arrangement, backplane interface, and power supply requirements differ between the two platforms. When designing the new iQ-R rack configuration, slot count, power budget, and module placement must be recalculated from scratch using iQ-R specifications.

RQ extension base units are the official Mitsubishi-specified solution for situations where certain Q-series modules have no direct iQ-R equivalent. These units allow Q-series modules to connect to and operate under an iQ-R CPU, providing a validated bridge during phased migrations. Key points to understand about RQ extension bases:

  • RQ extension bases physically connect Q-series modules to an iQ-R system; they are not Q-series bases repurposed — they are purpose-specified iQ-R accessories
  • Not every Q-series module is supported on an RQ extension base; the official module replacement list specifies which Q modules can be retained this way and any operating conditions that apply
  • Panel space must be re-evaluated when adding RQ extension racks alongside new iQ-R main racks — mechanical dimensions differ and mounting arrangements must be planned in advance
  • Power supplies must be re-evaluated for the iQ-R platform; Q-series power supplies are not carried over to iQ-R racks
  • RQ extension bases are a transitional tool, not a permanent architecture — plan the timeline for eventually replacing retained Q modules with native iQ-R equivalents

GX Works2 to GX Works3 Project Conversion: What Actually Happens

GX Works3 includes a conversion function that opens GX Works2-formatted Q-series projects and migrates logic, device assignments, labels, comments, and system parameters to the iQ-R format. Mitsubishi documents this as a structured procedure with confirmation dialogs and review steps — it is not a simple file-open operation, and treating it as one is one of the most consequential mistakes engineers make in this migration.

The conversion process involves several stages that require active engineering judgment:

  • Open the GX Works2 project in GX Works3 and review all conversion messages and warnings — do not dismiss messages without understanding their implications for each affected program or parameter block
  • For process CPU projects, an intermediate conversion step is required: the project must first be migrated to a universal model CPU before completing the full iQ-R conversion; skipping this step produces incorrect results
  • Intelligent module parameters must be reviewed individually after conversion — module model changes in the new architecture can require parameter re-entry or adjustment that the conversion function does not perform automatically
  • Device assignments, label declarations, and system parameter settings must be cross-checked in the converted GX Works3 project against the original GX Works2 project before any field deployment
  • Converted projects must be tested offline in GX Works3 simulation before being loaded to iQ-R hardware; runtime behaviour differences can exist in edge cases, particularly in motion and process applications

Motion CPU project conversion follows its own dedicated guide rather than the general Q-to-R migration manual. If your system includes a Q17n-series motion CPU, obtain and follow the dedicated Migration Guide of Motion Controller [Q17nDSCPU] as the authoritative procedure.

Network and Communication Migration: CC-Link, MELSECNET, and the Path to CC-Link IE

Network migration is frequently the most technically complex and time-consuming part of a Q-to-iQ-R project. Engineers who focus on CPU and I/O hardware first and defer network planning often encounter the hardest problems at the worst time — during commissioning with production pressure mounting.

Document every network in the system before designing any replacements:

  • CC-Link field networks can typically be retained during a phased migration; existing CC-Link slave devices do not need immediate replacement, and CC-Link master capability is available on iQ-R, though the longer-term direction is CC-Link IE Field and CC-Link IE Field Basic
  • MELSECNET/10 has no direct iQ-R native equivalent in most configurations; Q-series MELSECNET modules can be retained via RQ extension base units during transition, with a planned path toward CC-Link IE for peer-to-peer and controller network functions
  • Modbus RTU and other serial protocol modules represent a documented gap in the Q-to-iQ-R migration; community experience and official documentation both indicate that Q-series communication cards retained via extension racks or gateway solutions are often the practical answer during and after migration
  • CC-Link IE Field and CC-Link IE Field Basic are Mitsubishi's recommended standard for new iQ-R network segments — plan to introduce these as new I/O segments or expansions are added during migration phases
  • Mixed CC-Link and CC-Link IE architectures are feasible during phased migrations; document the boundary clearly and test communication between segments during the pilot phase

Network Migration Change Summary

Network Type Direct iQ-R Support Transition Strategy Complexity Risk Notes
CC-Link Yes — via iQ-R CC-Link module Retain during migration; plan future CC-Link IE upgrade Low Existing field devices preserved; master module changes required
MELSECNET/10 No direct equivalent Retain Q module via RQ extension base; migrate to CC-Link IE over time High Plan this early; late discovery causes project delays
Modbus RTU Limited Retain Q communication card via extension base or use gateway Medium to High Confirmed gap in iQ-R lineup; plan workaround before project design is locked
Ethernet (standard) Yes — built into iQ-R CPUs Direct migration; verify IP configuration Low Confirm protocol and port settings match SCADA/MES requirements
CC-Link IE Field Yes — native iQ-R support Introduce for new segments and expansions Low Preferred target architecture for new iQ-R deployments

Safety, Diagnostics, and Security Considerations

Any change to PLC hardware that affects safety-related control loops, emergency stop circuits, or functional safety interlocks requires formal re-validation — regardless of how closely the new hardware matches the old. This is not a conservative interpretation; it is the required position whenever hardware changes affect the execution of safety functions.

The MELSEC iQ-R platform expands diagnostic capability compared to Q-series, including improved event logging, module diagnostics, and fault isolation tools. These improvements are beneficial, but they also mean that alarm and diagnostic behaviour visible to operators and maintenance technicians will change. Update HMI, SCADA, and alarm documentation to reflect the new diagnostic structure before handover.

Security capabilities on iQ-R are expanded compared to Q-series. Password protection for program and parameter access, secure remote connectivity, and IT/OT integration features are more developed on the iQ-R platform. If your organization has OT security policies or is subject to industrial cybersecurity standards, the iQ-R migration is an appropriate time to review and implement those controls formally.

Full Replacement vs. Phased Migration: How to Choose and Execute

The choice between a full system replacement and a phased migration is determined by three factors: available downtime, the complexity of the hardware mapping (particularly for special modules and legacy networks), and the readiness of the engineering team to support the new platform immediately after cutover.

A practical eight-stage phased migration sequence applicable to most plant sizes:

Stage 1 — Audit: Complete hardware and software inventory; identify all critical loops and safety functions; archive all project files.

Stage 2 — Design: Use manufacturer migration guides and module replacement lists to design replacement architectures; decide between direct replacement, RQ extension base retention, or redesign for each component; plan network migration and endpoint treatment.

Stage 3 — Procurement: Select and order appropriate iQ-R CPUs, base units, I/O modules, and network hardware; order RQ extension bases and any Q modules that must be retained short-term; align delivery with planned downtime windows.

Stage 4 — Pilot: Implement migration on a non-critical system or representative section first; convert and test GX Works2 projects in GX Works3 offline; validate hardware mapping and network behaviour under real conditions before touching critical lines.

Stage 5 — Installation: Replace or add hardware according to the design and official wiring guides; install and wire iQ-R racks and extension bases with strict safety practices; connect networks and verify addressing and topology.

Stage 6 — Software Conversion: Convert pilot and then main projects from GX Works2 to GX Works3 following the documented procedure; adjust parameters and module configurations as required; re-test logic and communications with field devices.

Stage 7 — Validation: Execute functional, performance, and safety tests; document results and obtain sign-off from engineering and operations; refine the approach for subsequent phases based on findings.

Stage 8 — Handover: Provide updated drawings, project files, and instructions to maintenance and operations; complete training on GX Works3 and new diagnostic procedures; establish support and spare parts plans for the iQ-R-based system.

Wiring and Terminal Changes During Module Replacement

Wiring and terminal layout differences between Q-series and iQ-R modules are underestimated in a significant proportion of migration projects. Plan explicitly for this work rather than treating it as incidental to hardware swapping.

  • Review Mitsubishi's wiring notes for each replacement module before installation begins — connector types, terminal arrangements, and labeling conventions differ between Q and iQ-R modules and the differences vary by module family
  • Prepare updated terminal diagrams for every panel or enclosure affected by the migration before the installation phase begins — do not rely on field verification during the downtime window
  • Verify field wiring, shield grounding, and signal types for every replaced module; signal type mismatches are a documented source of extended commissioning delays
  • Adapter cables may be available for certain module transitions — check manufacturer documentation before assuming rewiring is always required, but do not assume adapters exist without confirming
  • All wiring work must be performed under appropriate lockout/tagout procedures by qualified personnel following the applicable electrical safety standards and official Mitsubishi wiring diagrams

Testing, Commissioning, and Validation After Migration

A structured test and commissioning sequence reduces the risk of discovering problems under production pressure. The depth of testing required scales with system criticality — motion and process applications need more extensive validation than standard I/O-heavy systems.

  • Pre-commissioning checks: verify hardware placement, power supply ratings, module seating, firmware versions on iQ-R CPU and modules, and network addressing before first power-up
  • Offline testing: use GX Works3 simulation to cross-check converted project logic, label assignments, and parameter settings before loading to iQ-R hardware
  • Online commissioning: step through I/O verification, network communication checks, and functional logic tests methodically — do not attempt full-system commissioning without completing I/O and network verification first
  • For motion and process applications: execute response-time and performance validation specific to the application requirements; compare results against the original Q-series system baseline where possible
  • Document all test results and obtain formal sign-off from engineering and operations before returning the system to production; this documentation becomes the baseline for future maintenance and further migration phases

Five Realistic Migration Scenarios and Recommended Strategies

Migration strategy should match system complexity, available downtime, and the degree to which special modules and legacy networks are involved. These five scenarios cover the range of situations most engineering teams encounter.

Scenario System Description Recommended Strategy Key Risk to Manage
1 Small machine, single Q CPU, limited I/O Direct CPU and I/O mapping to iQ-R equivalents; full replacement in one planned shutdown; convert GX Works2 project offline first Project conversion warnings; verify all parameters before commissioning
2 Medium production line, multiple Q racks, CC-Link I/O Replace central CPU and main rack with iQ-R; retain some Q I/O via RQ extension bases; maintain existing CC-Link, plan CC-Link IE for new expansions Mixed CC-Link and CC-Link IE segment behaviour; test communication boundaries during pilot
3 Process plant with Q-series process CPUs and analog instrumentation Follow dedicated process CPU migration guide; migrate analog modules with full parameter review; run parallel testing before cutover Analog scaling and alarming behaviour changes; safety re-validation required
4 System with Q-series motion controller and high-speed positioning Use dedicated motion migration guide for Q17n-series; validate axis count, performance, and positioning instruction set on pilot machine first Motion instruction set differences; response time must be measured and confirmed
5 Large multi-area plant requiring gradual modernization Phase by area: start with non-critical zones and new expansions on iQ-R; use RQ extension bases and gateways to bridge legacy areas; plan final phase for remaining Q racks Extended coexistence of Q and iQ-R increases documentation and support complexity; manage actively

Common MELSEC-Q to iQ-R Migration Mistakes and How to Prevent Them

Six mistakes account for the majority of migration delays, extended downtime events, and partial rollback situations reported by engineering teams. Each one is preventable with the right preparation sequence.

  1. Assuming every Q module has a direct one-to-one iQ-R equivalent. Incomplete review of official migration lists and guides leads to late discovery that motion, process, or special communication modules need extension bases or architectural changes. Prevention: use the manufacturer's official module replacement lists and migration manuals at the planning stage; flag modules without direct equivalents and design solutions before procurement begins.
  2. Treating GX Works2 to GX Works3 project conversion as a simple file open. Underestimating parameter, device, and module-specific changes required after conversion leads to logic differences, parameter errors, and unexpected behaviour in the iQ-R system. Prevention: follow the documented conversion steps for each CPU type, especially process and motion CPUs; thoroughly review converted parameters, device assignments, and system settings before commissioning.
  3. Ignoring network migration challenges and legacy protocols. Focusing on CPU and I/O hardware while assuming existing networks will work unchanged results in communication failures or partial functionality after migration, particularly for legacy fieldbus and serial devices. Prevention: audit all networks and devices; plan CC-Link IE or other Ethernet adoption; design gateways or extension-rack solutions where required; test communications as part of the pilot.
  4. Underestimating changes in wiring and terminals. Assuming new modules can be swapped in without re-checking connector types and terminal positions causes wiring errors, miswired signals, and extended downtime during installation. Prevention: use manufacturer wiring notes for each module; prepare updated terminal diagrams; allocate time and QA checks for wiring verification during migration.
  5. Performing full migration on critical systems without a pilot. Pressure to complete the project quickly, skipping stepwise validation, leads to extended downtime, debugging under production pressure, and elevated risk to safety and quality. Prevention: implement pilot migrations on representative but lower-risk systems; refine hardware mapping, project conversion, and test procedures before touching critical lines.
  6. Neglecting training and documentation updates. Assuming existing staff can intuitively adapt to iQ-R and GX Works3 leads to misuse of new diagnostics, slower problem resolution, and inconsistent future changes. Prevention: plan formal training sessions on GX Works3 and iQ-R diagnostic functions; update internal standards, drawings, and functional specifications; ensure all stakeholders understand the new architecture.

If you are actively scoping hardware for a migration project and want to confirm module availability and lead times before finalizing your design, contact the LeadTime.ca team directly — we ship worldwide and can help coordinate iQ-R sourcing for projects of any scale.

What Engineers Have Learned from Real Q to iQ-R Migrations

Across PLC engineering communities — including Reddit's r/PLC and r/automation, PLCTalk, and PLCS.net — a consistent pattern emerges from engineers who have completed or attempted MELSEC-Q to MELSEC iQ-R migrations. The overall sentiment is clear: the migration is achievable and the iQ-R platform is widely regarded as a capable and worthwhile successor. The difficulties are almost always concentrated in the same few areas, and they are avoidable with the right preparation.

The most consistently reported success pattern is building iQ-R experience on non-critical systems or new projects before migrating legacy Q-series installations. Engineers who were already fluent with GX Works3 and the iQ-R platform before attempting a complex Q migration reported significantly smoother projects than those who were learning the new environment and managing the migration simultaneously. Using RQ extension bases to retain Q modules during phased transitions was also frequently cited as a practical and low-risk bridge strategy — particularly for MELSECNET and Modbus RTU modules where no direct iQ-R equivalent exists.

The recurring complaints cluster around three areas. Project conversion complexity is the most consistently reported difficulty, especially for process CPU and motion CPU applications where the intermediate conversion steps and parameter reviews are non-trivial. Network migration — particularly the decision of when to retain MELSECNET or Modbus RTU versus committing to CC-Link IE and Ethernet — is described as a source of prolonged design debate and occasional mid-project course corrections. The cases that draw the most cautionary discussion involve rushed migrations on critical production lines without completed pilot testing: partial rollbacks, extended debugging windows, and post-migration instability are the recurring consequences. The lesson the community returns to most often is simple — the official Mitsubishi migration documentation is comprehensive and trustworthy, and the engineers who follow it closely have better outcomes than those who shortcut it.

Expert Migration Verdict: When to Migrate, When to Phase, and When to Wait

For most plants running MELSEC-Q Series Programmable Controller systems, migration to the MELSEC iQ-R Series Programmable Controller is not a question of whether but of how and when. The iQ-R platform delivers expanded diagnostics, stronger security, native CC-Link IE and Ethernet integration, and a unified engineering environment in GX Works3 — advantages that compound as plants modernize SCADA, MES, and OT network infrastructure. The teams best positioned for a successful migration are those who treat it as a structured modernization project: they have completed a full hardware audit, they are working from the official Mitsubishi module replacement lists and migration manuals, and they have designed their replacement architecture before committing to procurement. For systems with special Q-series modules — particularly motion CPUs, process CPUs, and MELSECNET or Modbus RTU communication cards — the hybrid approach using RQ extension base units is the manufacturer-validated path, not a workaround. It reduces risk, preserves function during transition, and gives engineering teams time to validate the new platform before fully decommissioning legacy hardware.

Migration should be delayed or phased when critical systems cannot accept extended downtime and pilot validation is not yet complete, when replacement architectures for special Q-series functions are not fully mapped and confirmed, or when the engineering team lacks sufficient GX Works3 and iQ-R familiarity to support the system independently after cutover. In those situations, maintaining Q-series with evaluated spare stock while building migration readiness is the lower-risk choice. The deciding question to ask before committing to any migration schedule is this: do we have a fully documented hardware mapping, a tested GX Works2-to-GX Works3 conversion process, and a realistic downtime and phasing plan for each system? If the answer to any part of that question is no, complete that work first.

From a procurement standpoint, lead times on MELSEC iQ-R CPUs, base units, and specific intelligent modules should be confirmed early in the design phase — not after the hardware list is finalized. Availability for iQ-R hardware is generally better than for aging Q-series components, but specific modules may carry lead times that affect project scheduling. LeadTime.ca supports migration projects by helping engineering teams shortlist appropriate iQ-R hardware and coordinating sourcing and lead-time expectations — check current availability for your specific iQ-R module list at LeadTime.ca before locking in your project timeline.

For volume orders or to confirm lead times before committing to a build schedule, contact the LeadTime.ca team directly — we ship worldwide.

Sourcing MELSEC iQ-R Hardware: Lead Times and Procurement Considerations

Procurement planning for a MELSEC-Q to iQ-R migration involves more than simply ordering equivalent hardware. Several considerations are specific to migration projects and are worth building into the project schedule explicitly.

  • Confirm lead times for iQ-R CPUs, base units, RQ extension bases, and intelligent modules before finalizing the project schedule — specific modules may have lead times that require early ordering relative to the planned installation window
  • Order RQ extension bases alongside new iQ-R hardware when a phased strategy is planned — extension bases are part of the supported migration architecture and should be treated as first-class components in the bill of materials, not afterthoughts
  • For Q-series modules being retained short-term via extension bases, confirm current availability — Q-series sourcing may already be constrained depending on the specific model, which is often itself a driver of the migration decision
  • Stocking critical iQ-R spare modules after migration is a prudent practice; the new architecture should have a defined spare parts plan before handover to operations
  • Current pricing and availability for MELSEC iQ-R CPUs, base units, and modules require distributor confirmation — check pricing and lead times on the product page at LeadTime.ca or contact the team directly for project-specific sourcing support

Frequently Asked Questions

Does every MELSEC-Q module have a direct one-to-one iQ-R replacement?

No — while many Q-series standard I/O and analog modules have direct iQ-R equivalents listed in the official Mitsubishi module replacement documentation, certain modules — particularly motion CPUs, MELSECNET network modules, specific communication cards, and some process modules — do not have direct replacements. For those, Mitsubishi specifies using RQ extension base units to retain the Q-series module under an iQ-R CPU, or redesigning the affected function using alternative iQ-R capabilities. Always consult the official replacement list before finalizing any hardware decision.

Can I open my GX Works2 Q-series project directly in GX Works3 without any rework?

GX Works3 includes a conversion function for GX Works2 Q-series projects, but it is not a passive file open. The conversion produces messages and warnings that require engineering review; parameters for intelligent modules may need to be re-entered; and process CPU projects require an intermediate conversion step to a universal model CPU before the iQ-R migration can proceed. Converted projects must be validated offline in GX Works3 before being loaded to iQ-R hardware. Treating this as a simple import is one of the most frequently reported sources of post-migration issues.

How do I handle MELSECNET networks when migrating to iQ-R?

MELSECNET/10 does not have a native iQ-R equivalent in most configurations. The manufacturer-supported approach during phased migration is to retain Q-series MELSECNET modules via RQ extension base units while introducing the iQ-R CPU platform, with a planned long-term path toward CC-Link IE Field or CC-Link IE Control for the network backbone. Attempting to eliminate MELSECNET immediately at the time of CPU replacement without a tested alternative in place is a high-risk approach that has caused communication failures in documented migration cases.

What is the correct migration path for a Q-series process CPU?

Process CPU migration to iQ-R follows a dedicated migration guide separate from the general Q-to-R manual. A key requirement documented in that guide is an intermediate conversion step: the GX Works2 process CPU project must first be converted to a universal model CPU project before the final iQ-R migration proceeds. Skipping this intermediate step produces incorrect conversion results. Obtain the process CPU-specific migration documentation from Mitsubishi before beginning this type of project.

How much downtime should a typical MELSEC-Q to iQ-R migration require?

Downtime requirements vary significantly with system complexity, the number of modules requiring rewiring, the extent of network changes, and whether a phased approach is being used. A small machine with a single Q CPU and straightforward I/O can often be migrated in a single planned shutdown, provided the project conversion has been completed and validated offline in advance. Multi-rack systems with motion CPUs, process CPUs, or legacy network modules typically require multiple planned windows and a phased approach. Community experience consistently indicates that teams who complete offline project conversion and pilot validation before the production cutover window require significantly less on-site commissioning time.

Can I use Q-series Modbus RTU communication modules with an iQ-R CPU?

The iQ-R platform has limited native Modbus RTU module options compared to Q-series, and this is a documented gap that community users and official migration resources both acknowledge. The practical options during and after migration are retaining Q-series Modbus communication cards via RQ extension base units or implementing gateway solutions. Design this aspect of the migration early — discovering the Modbus RTU gap during the installation phase is a common cause of project delays.

Is it necessary to re-validate safety functions after a Q to iQ-R hardware replacement?

Yes — any change to PLC hardware that affects safety-related control loops, emergency stop circuits, or functional safety interlocks requires formal re-validation under the applicable safety standards. This applies regardless of how closely the new iQ-R hardware matches the replaced Q-series hardware. Safety re-validation must be planned and resourced as part of the migration project, not treated as an assumed carry-forward from the existing Q-series installation.

When does using RQ extension bases make more sense than pursuing a direct module replacement?

RQ extension bases are the correct choice when a Q-series module has no confirmed direct iQ-R equivalent in the official replacement list, when eliminating the module function immediately would require a complex architectural redesign that cannot be executed within the available migration window, or when a phased approach requires the Q-series module to remain in service while other parts of the system are migrated. They are also appropriate for retaining legacy network modules (such as MELSECNET) while the new CC-Link IE or Ethernet backbone is validated and deployed. RQ extension bases are a supported, manufacturer-specified transition tool — not a permanent architecture.

Why Order from LeadTime.ca

  • LeadTime.ca sources MELSEC iQ-R CPUs, base units, RQ extension bases, and intelligent modules for migration projects of all sizes, with worldwide shipping to engineering teams wherever they are located
  • Specialist support for controls engineers scoping migration hardware lists — help with part confirmation, lead-time coordination, and volume pricing for larger projects
  • Hard-to-find modules and legacy Q-series components for teams managing phased migrations that still require Q-series spares alongside new iQ-R hardware
  • Fast response for time-sensitive sourcing situations where downtime windows are fixed and procurement lead time is a constraint

MELSEC-Q to iQ-R Migration: At-a-Glance Summary

  • The MELSEC-Q Series Programmable Controller is a legacy platform with a manufacturer-documented upgrade path to the MELSEC iQ-R Series Programmable Controller
  • Mitsubishi provides an official "MELSEC-Q Series to MELSEC iQ-R Series Migration Guide" and a module replacement list as the authoritative references for hardware mapping decisions
  • GX Works3 includes a conversion function for GX Works2 Q-series projects; process CPU projects require an intermediate universal model CPU conversion step before iQ-R migration
  • For Q-series modules without direct iQ-R equivalents — including many motion CPUs, MELSECNET modules, and Modbus RTU communication cards — Mitsubishi specifies RQ extension base units as the validated retention solution
  • Network migration must be planned explicitly: CC-Link can be retained during transition, MELSECNET requires extension-base or gateway solutions, and CC-Link IE Field is the recommended target architecture for new iQ-R segments
  • A phased migration strategy — starting with non-critical systems, completing a pilot, then expanding — reduces risk and builds team competency on iQ-R before critical system cutover
  • Six common mistakes account for most migration difficulties: assuming direct module equivalents, treating project conversion as a simple file open, ignoring network migration, underestimating wiring changes, skipping pilot testing, and neglecting training and documentation
  • Safety functions must be formally re-validated after any hardware change that affects safety-related I/O or control loops
  • Current pricing and lead times for MELSEC iQ-R hardware require distributor confirmation — check availability at LeadTime.ca or contact the team for project-specific sourcing support