A Mitsubishi PLC program handover is complete only when an authorized engineer other than the author can identify installed MELSEC hardware, open the right project with licensed tools, compare it with the running CPU, and restore a safe baseline. This guide covers evidence, tests, and a 90-day plan.
1. Program handover is different from replacement or new PLC development
A PLC replacement and retrofit project asks whether and how to migrate aging hardware. Outsourced PLC program development asks how to specify and accept new control logic. Existing-system handover asks a third question: can someone other than the incumbent recover the machine that is running today?
A project folder alone cannot answer it. The offline project may differ from the CPU, comments and labels may be missing, HMI and motion data may live elsewhere, and the installer or license may no longer be available. A defensible handover therefore combines asset identity, online comparison, access rights, a controlled golden package, and a recovery exercise.
| Work type | Primary decision | Role of this guide |
|---|---|---|
| PLC replacement | Whether and how to migrate old hardware | Establish evidence needed before the decision |
| New PLC software outsourcing | How to specify and accept new logic | Define any outsourced gap-closing scope |
| Existing-program handover | Whether a third party can recover the current machine | Main scope, proved by records and restore tests |
The goal is not “a backup exists.” It is “an authorized person can restore the approved safe baseline, with specified tools, within an agreed recovery target.”
2. Fix the identity of every installed MELSEC asset
Machines with the same line name can have different modifications inside their panels. Begin with an equipment ID and hardware register, not with a download. Record panel, line, machine, serial or asset number, location, and owning department, then compare physical nameplates with the engineering configuration.
Do not stop at the CPU model. Record the rack and power supply, local and remote I/O, analog and high-speed modules, positioning and motion CPUs, networks, serial modules, safety CPU and I/O, SD cards, battery, GOT/HMI, servo amplifiers, and inverters. Firmware is module-specific. Mitsubishi Electric’s iQ-R firmware page also shows that required GX Works3 versions vary with modules and firmware functions.
| Asset | Required record | Evidence |
|---|---|---|
| PLC CPU | Series, full model, manufacturing data, firmware | Front label, diagnostics, panel drawing |
| Modules | Slot, model, firmware, station | Installed order, label, online configuration |
| Network | Type, station, IP, route, exchanged data | Settings, switches, connection drawing |
| GOT/HMI | Model, OS, screen project, communication | Device information and transfer settings |
| Motion/servo | CPU, amplifier, axis, parameters, origin | Axis table, motor and encoder data |
| Inverter | Model, capacity, parameters, communication | Front panel, readout, bill of materials |
| Safety | Safety CPU/I/O, validation status and scope | Safety drawings and signed test records |
Photographs help but may expose sensitive network and equipment data. Store them under access control and corroborate them with online information, purchase records, and maintenance history.
3. Record the exact GX Works3, GX Works2, or GX Developer environment
“Requires GX Works” cannot reproduce a recovery laptop. GX Works3, GX Works2, and GX Developer serve different generations and project formats. Record the full software version, update history, language, operating system, dependencies, communication drivers, media, and license method.
Mitsubishi Electric presents GX Works3 as an engineering environment for MELSEC iQ-R/iQ-F, with IEC 61131-3-oriented programming and lifecycle functions. That does not mean any version supports every installed CPU and firmware. Match the installed module/firmware list to official compatibility information, then retain verified installers and updates through legitimate channels.
| Item | What to record | Acceptance evidence |
|---|---|---|
| Engineering software | Product, complete version, language, updates | About screen and installation register |
| Operating system | Edition, version, architecture, update state | System information |
| License | Owner, entitlement, count, transfer/reissue process | Purchase and account records |
| Communication | USB/Ethernet/serial drivers and cables | Connection test and spare cable |
| Companion tools | GOT, motion, servo, inverter, network | Version and matching project for each |
| Manuals | Machine/version/language and local notes | Offline viewing test |
An installer copy is not a license. Clarify whether rights belong to a company, site, device, or user, and how a failed PC can be replaced. Replace unknown shared keys with legitimate entitlements.
4. Inventory PLC, HMI, motion, servo, inverter, network, and safety separately
Opening the PLC project does not recover the machine. GOT screens, scripts and recipes; motion projects; servo tuning; inverter parameters; vision, robots, industrial PCs, and managed switches may use separate tools and backups. Give each asset its own file, tool, connection, owner, and validation method.
Safety CPUs and safety logic must not be treated as ordinary controls. Preserve the safety signature or validation state, risk assessment, test evidence, access rights, and the required revalidation scope. This article provides no password bypass or protection-removal procedure. If authorization is missing, return to the asset owner, OEM, and official support process.
| Asset | Main handover content | Common dependency missed |
|---|---|---|
| PLC | Project, program, label, parameter, device values | CPU/firmware, libraries, special modules |
| GOT/HMI | Screens, scripts, recipe, alarms, OS | Fonts, language, driver, users |
| Motion | Axis setup, programs, parameters | Servo firmware, origin, mechanical ratio |
| Servo | Gain, filters, limits, motor data | Tuning record and absolute position |
| Inverter | Parameters, communication, control mode | Motor rating, terminal mapping, station |
| Network | Stations, IP, routing, cyclic data | Switch settings, certificates, time sync |
| Safety | Safety program, parameter, validation | Authorization, signature, retest boundary |
Inventory is finished only when another engineer knows how to open each item, what live state to compare, and which test will prove recoverability.
5. Start online verification with read and preserve the pre-write difference
Connecting to running equipment requires authorization, hazard review, operating-mode agreement, and an assessment of communication impact. Do not transfer or convert on first contact. Within the approved read-only scope, record CPU status, errors, clock, configuration, and comparison with the executing project. Where even an online operation can affect performance, use the OEM procedure and an approved stop window.
- Obtain owner, production, safety, maintenance, and IT/OT approval.
- Confirm models, firmware, tool version, and connection path.
- Duplicate existing files and preserve originals read-only.
- Save a controller readout as a separately identified snapshot.
- Produce an offline or supported online comparison report.
- Separate program, parameter, design-data, and operating-value differences.
- Have the factory, SIer, and OEM approve the golden candidate.
- Treat any required write as a separate controlled change with backout.
Do not assume that the laptop file is newest or that a PLC upload is complete. The controller may include undocumented site edits but lack comments; the offline file may contain rich labels but omit the last field change.
| Difference class | Examples | Decision owner |
|---|---|---|
| Executing logic | Ladder, ST, FB instances, tasks | Controls owner and OEM/SIer |
| Configuration | Modules, network, CPU parameters | Controls and network owners |
| Design information | Labels, comments, library, documents | Design owner |
| Operating data | Recipes, retained devices, offsets | Production, quality, maintenance |
| Security | Users, roles, allowed connections, certificates | Asset owner and IT/OT |
6. Treat labels, comments, FBs, and libraries as source
Executable content alone is difficult to diagnose and modify safely. Receive global/local labels, device comments, structures, function blocks, user libraries, constants, tests, design notes, cross references, and alarm lists with the project. For each external library record the version, source, license, and modifications.
Preserve original-language comments. If Japanese design comments, English site additions, and local abbreviations coexist, add a controlled glossary for critical interlocks and fault recovery. Do not overwrite source meaning with an unreviewed translation.
When source is incomplete, distinguish content read from the machine, design information recovered from another revision, and unverified reconstruction. Never label an inferred project as the original.
7. Build a recovery package, not one “golden ZIP”
A golden backup is not the newest-looking folder on an engineer’s desktop. It is a configuration-controlled package with equipment ID, collection time and source, approver, hash, tools, hardware scope, restoration procedure, and validation result. Separate frequent snapshots from the approved golden baseline.
| Content | Examples | Recovery decision |
|---|---|---|
| Editable source | PLC, HMI, motion projects | Include references, libraries, conversion state |
| Generated/binary data | Transferable output where applicable | Map it to the matching source revision |
| Parameters | CPU, modules, network, servo, inverter | Identify every behavior-changing write |
| Recipes | Product, offset, limits, HMI recipes | Confirm units and quality approval |
| Retained devices | Latch values, counters, calibration | Do not restore every value blindly |
| Communications | IP, stations, routes, ports, mapping | Protect confidentiality and avoid conflicts |
| Time | Clock source and timezone for PLC/HMI/server | Affects event order and deadlines |
| Documents | As-built, I/O, alarms, procedure, history | Confirm mapping to hardware and project |
Retained data may represent machine life, calibration, position, production counters, or quality limits. Classify each set as restore, initialize, or set only after production/quality approval.
8. Hand over credentials safely—never bypass protection
An unknown password does not authorize circumvention. Follow asset-owner approval, contracts, and OEM or official support identity and ownership checks. If legitimate recovery is unavailable, record it as a recovery risk and escalate it to production and management planning.
Do not store credentials in plain spreadsheets, email, or inside the cabinet. Use an audited enterprise vault. Separate personal and emergency accounts; define owner, approver, expiry, use log, leaver revocation, and periodic review. Avoid permanent shared SIer accounts and restrict service access by purpose, time, and asset.
Test access beyond the PLC password: recovery-laptop login, license portal, PLC/HMI roles, VPN or jump host, backup repository, keys/certificates, and support portals. A second authorized person should prove that each path works.
9. Integrate backup with change management using NIST SP 1339
NIST published SP 1339, the OT Backup Quick Start Guide, as Final on 17 June 2026. It frames OT backup as a lifecycle process integrated with change management: create backups regularly, test them, perform recovery exercises, and review the program based on results.
For MELSEC equipment, make backup update a completion condition for program changes, module replacements, firmware updates, recipe revisions, and network changes. Link the ticket to before/after snapshots, comparison, approvals, functional and safety checks, golden promotion, and backout.
NIST SP 800-82 Rev.3 is the September 2023 Final guide for OT security with performance, reliability, and safety considerations. Rev.4 is an Initial Preliminary Draft published on 22 January 2026 and is not Final; it should not be presented as the current final publication.
| Gate | Required evidence | Failure example |
|---|---|---|
| Before change | Current golden, live compare, backout | Write while current revision is unknown |
| During change | Person, time, object, difference, authorization | Verbal edit with no ticket |
| After change | Compare and function/safety test | “It runs” but no saved difference |
| Golden promotion | Approval, hash, restore result, storage | Only a personal laptop is updated |
| Periodic exercise | Actual RTO, failures, improvement owner | Checking only that a copy exists |
10. Use offline recovery tests to prove open, build, and explain
Before writing to production, unpack the package on an isolated recovery workstation. A new engineer should follow the procedure to start licensed tools, open projects, resolve libraries, compile or convert, display configurations, and generate comparison reports. Plan for a recovery situation without internet access by retaining legitimate installers and manuals.
Mitsubishi Electric’s e-Manual Viewer integrates manual search, bookmarks, and notes. It can export e-Manual data—including manuals, bookmarks, and notes—for migration to another PC or backup when recovering a PC. Distribution of its tablet app ended in March 2024, so current plans should center on supported Windows operation and legitimately obtained manuals, subject to regional availability.
Passing means more than opening a file. Missing modules or libraries and warnings must be listed; the CPU/module configuration must match the asset register; source, binary, and parameter revisions must be explained; write targets and operating values not to write must be separated; and results, duration, device, and engineer must be recorded in the required languages.
11. Perform a restore test on a spare CPU or approved stop window
An offline project can open yet fail to restore. Where compatible spare hardware exists, restore it in an isolated configuration and verify startup, diagnostics, I/O configuration, communications, and retained-data handling. Without a spare, plan the feasible read, compare, and recovery exercise in an approved stop window with backout.
Production testing requires safe outputs, energy control, prevention of duplicate IP or unintended communication, and production/safety witnesses. Do not omit safety-CPU revalidation. Record SD-card model, capacity, contents, write protection, spare, and storage conditions; never make the card the only copy.
The figures below are a hypothetical process example, not market data or guaranteed times.
| Recovery step | Target (hypothetical) | Actual (hypothetical) |
|---|---|---|
| Diagnose and authorize | 30 min | 35 min |
| Prepare spare CPU/workstation | 20 min | 25 min |
| Replace hardware/check configuration | 45 min | 50 min |
| Restore project and parameters | 30 min | 40 min |
| Verify communication, I/O, safety | 45 min | 55 min |
| No-load and product check | 50 min | 60 min |
| Total | 220 min | 265 min |
The target is 30+20+45+30+45+50 = 220 minutes. Actual is 35+25+50+40+55+60 = 265 minutes, 45 minutes over target. Set real objectives from criticality, production impact, spares, staffing, and safety.
12. Divide recovery responsibility among factory, SIer, and OEM
“Maintenance keeps the backup” and “the SIer will fix it” fail during an off-hours incident. Assign Responsible, Accountable, Consulted, and Informed roles from diagnosis through production release. Separate OEM intellectual property, SIer modifications, and factory-owned recipes or retained data.
| Recovery task | Factory | SIer | OEM |
|---|---|---|---|
| Stop, LOTO, work authorization | A/R | C | C |
| Diagnose | R | R | C |
| Select golden package | A | R/C | C |
| Replace CPU/module | A/C | R | R/C |
| Restore program/parameter | A | R | R/C |
| Revalidate safety | A/R | R/C | C |
| Product check/release | A/R | C | I |
| Update evidence | A | R | C |
Adapt this example to contracts and competence. Define deputies, after-hours contacts, remote-access approval, site response, logs, fees, and closure. Mitsubishi Electric’s support pages list manuals, support, training, and backup-related services, but availability differs by region; verify the Thailand arrangement.
13. Apply IEC 62443-2-4, TIS 62443, and IEC 60204-1 carefully
IEC 62443-2-4:2023 addresses security program requirements for IACS service providers. Thailand’s TIS 62443 Part 2(4)-2568 covers the same domain as a general standard and took effect on 9 May B.E. 2569, or 9 May 2026. Do not infer that every engagement complies or that a provider is certified. Define applicability and evidence contractually.
For handover, evaluate account management, technician authorization, change records, remote access, removable media, backup protection, incident contact, and revocation when personnel change. Ask what evidence the provider will leave on this asset, not only for a policy document.
IEC 60204-1:2016 with Amendment 1:2021 addresses electrical equipment of machines; the IEC page lists a stability date of 2027. It can inform verification of output state, emergency stops, safety circuits, and restart after recovery. Confirm the selected edition, Thai law, and customer requirements with qualified safety personnel.
14. A 90-day existing-MELSEC handover plan
Ninety days is not a promise to complete every modernization. It is a period to establish current state, prove recoverability, and move gaps into owned remediation.
| Period | Main work | Gate deliverable |
|---|---|---|
| Days 1–15 | Equipment, owner, hardware and tool inventory | Asset register, access gaps, priorities |
| Days 16–30 | Collect source, read live state, compare | Difference register, missing list, snapshot |
| Days 31–45 | Link PLC/HMI/motion and confirm rights | Recovery package candidate, license register |
| Days 46–60 | Offline open/build, procedures, training | Offline test evidence and improvements |
| Days 61–75 | Restore exercise on spare or stop window | Actual RTO, safety and communication results |
| Days 76–90 | Correct, approve golden, operationalize | Signed golden, RACI, recurring exercise plan |
During days 1–30, establish facts without writes. During days 31–60, a person other than the incumbent opens every project and resolves dependencies. During days 61–90, measure the exercise and turn failures into procedure, spare, access, and training improvements.
15. RFP and acceptance for outsourced MELSEC handover work
If gaps are outsourced, do not specify only “take backups.” Define assets, authorization, read/write rules, stop windows, asset-level deliverables, differences, offline tests, restore tests, training, intellectual property, security, and unresolved-item handling.
Effort varies with CPU generation, peripheral assets, missing source, access, stop constraints, languages, and mismatch between drawings and reality. This article provides no unsupported market price. A short paid discovery can establish the register and risks before a fixed implementation scope.
Acceptance should require all assets to be registered; live/golden comparison approved; another engineer to open projects with legitimate tools and rights; separate restore policy for source, parameters, recipes, and retained values; a recorded restore exercise; and explicit backout, safety, and production-release authority.
FAQ: Mitsubishi PLC program handover
Q1. Is a file read from the PLC sufficient?
Usually not. Comments, labels, libraries, HMI, motion, servo, network, recipes, retained data, and tool environment may be separate. Compare the readout with the design source and assemble an equipment-level package.
Q2. Can GX Works3 handle every MELSEC controller?
No. Series, CPU, firmware, and project format determine whether GX Works3, GX Works2, GX Developer, or companion tools are required. Confirm the exact version from official compatibility information.
Q3. May we remove an unknown password?
Do not bypass protection. Use owner authorization, contracts, and OEM or official support verification. This article provides no circumvention method.
Q4. Should the golden backup be overwritten every day?
Separate snapshots from the approved golden. Promote only a revision with comparison, tests, approval, hash, and restore result.
Q5. Can we test recovery without a spare CPU?
You can test offline opening, building, configuration, and the procedure first. A production stop-window exercise needs approved safety, backout, and production planning.
Q6. Should all retained devices be restored?
No. They may represent calibration, position, lifetime, counters, and quality conditions. Decide restore, initialize, or reset per data group.
Q7. Is English-only training enough in a Thai factory?
It depends on assigned personnel. Verify Thai understanding of safety actions, recovery, and prohibitions through practical exercises, with a glossary across Japanese and English design information.
Q8. Should replacement start immediately after handover?
First document current condition, parts availability, recoverability, and downtime impact. Then compare continued support, spares, staged migration, and full replacement.
Conclusion: receive evidence that a third party can recover the machine
An existing MELSEC handover inventories CPU, modules, tools, HMI, motion, servo, network, and safety separately; freezes live differences before any write; and builds a controlled golden package containing source, parameters, recipes, retained-data policy, and rights. A second engineer must pass an offline test and a spare-hardware or approved-window recovery exercise.
If source is scattered, an SIer is changing, or recovery time has never been measured, you can contact TOMAS TECH at the inventory stage. We can help separate read-only discovery, difference approval, and recovery testing before any production write.
References
- NIST SP 1339: OT Backup Quick Start Guide (Final, 17 June 2026)
- NIST SP 800-82 Rev.3 (Final, 2023; Rev.4 is a non-Final Initial Preliminary Draft dated 22 January 2026)
- Mitsubishi Electric: GX Works3
- Mitsubishi Electric: MELSEC iQ-R firmware updates
- Mitsubishi Electric: e-Manual Viewer
- Mitsubishi Electric: Technical Support
- IEC 62443-2-4:2023
- TISI: TIS 62443 Part 2(4)-2568 (effective 9 May 2026)
- IEC 60204-1:2016+A1:2021 (stability date 2027)
*Online access, writing, restoration, and safety validation require asset-owner authorization, manufacturer procedures, applicable law, and a documented risk assessment.*
