Siemens PLC Migration in Thailand: S7-300 Upgrade and Acceptance Guide

A Siemens PLC migration at a Thai factory—from S7-300 and ET 200M toward S7-1500 and ET 200MP, or another validated target—is not complete when the CPU and I/O model numbers have been replaced. The project must also control the production outage, machine safety, communications, legacy software assets, FAT/SAT, rollback, local maintenance capability and OT cybersecurity. This guide follows the practical sequence from site survey and scope definition through conversion, acceptance and handover.

Why a Siemens PLC migration is more than a hardware replacement

The longer an S7-300 machine has run reliably, the more undocumented operating knowledge it is likely to contain: a timer adjusted during commissioning, a special recovery sequence used by maintenance, an HMI shortcut, a data layout expected by a production system, or an interlock that appears only during shutdown. A bill of materials cannot describe all of this behavior.

Siemens’ official blog describes a product phase-out announcement on 1 October 2023 for the S7-300 and ET 200M system families. It says the generally 10-year spare-parts availability starts from that announcement, although it may end earlier because of electronic-component scarcity. Type cancellation follows on 1 October 2025; after that, components are handled as spare parts and may be sent for repair or, where applicable, supplied in exchange for defective parts. The lifecycle normally ends 10 years after the phase-out announcement. None of this is a delivery guarantee for every order number, country, inventory position or requested date. For a project in Thailand, confirm the exact MLFB/order number, substitution status and required delivery date with Siemens or an authorized channel before committing to a shutdown plan.

The lifecycle notice does not mean that every installed system stops working on that date. It is a reason to make a planned decision before a failure turns the upgrade into an emergency. Spare holdings and planned migration are separate controls. Spare hardware cannot compensate for a missing source project or lost process knowledge; an upgrade completed without discovery may also fail to reproduce behavior that the old equipment performed correctly.

Define the objective in one sentence

A useful objective is:

Preserve the approved production behavior and safety of the existing machine while moving to a maintainable PLC, remote-I/O and engineering environment, with enough evidence and time to accept the new system or restore the old one within the agreed outage.

“Modernize the line” is too vague. Capacity improvements, new screens, standardized code and additional data collection can be valuable, but they should be managed separately from mandatory migration requirements. If conversion and improvement share one undifferentiated test list, a defect becomes difficult to classify: was it a failure to reproduce the old requirement, or a design problem in the new feature?

Start legacy-equipment renewal with three views: physical, software and operation

Agree the deliverables of the site survey before requesting a fixed migration quotation. Photographs alone, a PLC archive alone or drawings alone are insufficient. Link the physical equipment, software assets and operating practice with common equipment tags, and identify which information is verified and which remains an assumption.

Physical survey: trace relationships, not only cabinet labels

Record CPUs, power supplies, racks, signal modules, interface modules, communication processors, terminal assemblies, spare slots, grounding and 24 VDC distribution. Trace ET 200M stations that may sit in remote cabinets or inside machine sections. Map Profibus, PROFINET, Industrial Ethernet, serial links and vendor gateways to their actual peers.

An I/O count is not an electrical design. Record signal voltage and polarity conventions, isolation, diagnostics, analog signal type, scaling and resolution handling, thermocouples or RTDs, pulse and high-speed counter functions, positioning, redundancy and any hazardous-area requirements. Even where a functional replacement exists, differences in front connectors, terminal allocation, heat, space and cable length may require a cabinet modification.

Software survey: prove recoverability, not merely the existence of a backup

A folder on a maintenance computer is not necessarily a restorable master. Confirm that the offline project matches the running CPU, and that symbols, comments, libraries, sources, user blocks, communication configuration, HMI project, recipes, drive parameters and controlled credential information are available. Protected blocks and third-party libraries require an early review of technical and contractual rights to migrate, compile and maintain them.

Test whether the legacy engineering computer still starts and whether the required operating system, STEP 7, option packages, adapter and licenses work. A file is a weak disaster-recovery control if the plant can no longer open or download it. The current Siemens TIA Portal page refers to V21, but that does not prove that V21 will automatically open, convert, license or commission every legacy arrangement. Check compatibility by CPU, module, firmware, operating system, license and options such as Safety or Drive integration. Record the exact toolchain used by the project.

Operational survey: turn local knowledge into testable requirements

Observe normal start, stop, recipe or model change, alarm recovery, material shortage, power recovery, loss of utilities, communication failure and sensor failure. Ask operators which actions they avoid. Ask maintenance what they inspect first for important alarms and what must be confirmed before restarting.

Do not accept one interview as the final specification. Triangulate explanations against the PLC program, HMI, electrical drawings, I/O and actual machine behavior. Disagreement is useful: it reveals migration risk while it can still be resolved. Record it as an open decision with an owner and due point.

S7-300 to S7-1500: separate conversion from redesign

Siemens’ official migration guide provides technical considerations for hardware and software differences and project conversion. It also contains historical forward-looking wording, including statements framed around dates before 2020. Do not reuse those passages as a statement of the 2026 product situation. Use the guide for migration concepts, then verify current lifecycle, compatibility and support with current product information and the manuals for the exact selected items.

Build a hardware mapping with differences, not a two-column substitution list

For every existing BOM line, record its role, candidate target, differences, additional components, evidence and approver. A simple “old model/new model” table loses power, terminal, shield, cable, protocol, dimensions and diagnostic behavior. Select a CPU against the real application: program structure, cycle requirements, communication load, motion, safety and planned expansion—not a generic claim that one processor is “faster.”

The same discipline applies to ET 200M and ET 200MP. Equal channel counts do not establish equivalence. Keeping field wiring, using a transition component or rewiring from terminal level creates different outage tasks and different long-term maintenance. An adapter may reduce field work in a suitable case, but its future availability, space, extra connection points and maintainability still require assessment.

A successful compile is not proof of equivalent machine intent

Review instruction semantics, addressing, data types, initial values, retentivity, startup behavior, timers and counters, indirect addressing, system functions, diagnostics, communication blocks, interrupts and execution order. Measure application performance on the selected target where it matters. Do not place an invented speed improvement in the business case.

Legacy programs often depend on absolute addresses and broadly shared data blocks. A full rewrite into a structured, optimized S7-1500 style may improve maintainability, but it also expands the change surface. Where outage risk is high, create a behavior-preserving migration baseline first. Treat refactoring and functional improvement as a separate branch, requirement set and test scope.

Maintain a human-readable change ledger in addition to conversion-tool logs. Link each removed function, replaced instruction, changed DB/tag and manual edit to its reason and test. This ledger supports FAT completeness and becomes practical training material for Thai maintenance staff.

Put communications early in the control-system modification

A PLC that runs by itself is not a functioning production machine if it cannot communicate with HMI, SCADA, MES, production PCs, robots, drives, instruments or other controllers. Early in the project, build a matrix of peer, direction, data, timing requirement, failure behavior and responsibility boundary.

Build a communication matrix

For each peer, capture protocol, medium, IP/node, tags or data regions, handshake, timeout, reconnection, time synchronization and safe behavior on failure. If an upper-level system reads absolute PLC addresses, a DB redesign has consequences outside the cabinet. When retaining a gateway, specify who owns the configuration and how it will be restored.

Decide HMI migration as a separate scope choice. If the old HMI remains, verify its driver, addressing, alarms, recipes and user roles against the new PLC. If it is replaced, control the operational change through a screen comparison, language review, rights, history, input limits and misuse prevention. Our HMI screen development guide for Thai factories expands these interface considerations.

Select staged or single-outage migration from plant constraints

A staged migration creates a controlled boundary between old and new systems and changes one section at a time. It can divide shutdown exposure but creates temporary conversion, dual maintenance and boundary testing. A single-outage migration avoids the interim architecture but concentrates work and acceptance. Choose from machine divisibility, allowed outage, material readiness, rollback and acceptance authority—not from a general preference.

Give safety functions a separate approval path

Where E-stops, guard doors, light curtains, two-hand controls or safe speed/position functions are involved, do not change safety “incidentally” during the PLC work. Review the existing safety requirements, circuit, safety PLC/relay, machine risk assessment, validation record, regulations and plant rules. Qualified parties with defined responsibility must approve the change boundary.

Passing normal I/O checks is not safety validation. Keep safety requirements, design, implementation, verification, validation and change evidence traceable. If a safety program, license, signature or protected access is involved, prepare the toolchain and authorized staff before the outage.

Rollback must also preserve safety. Any temporary wiring or jumper requires authorization, identification, independent checking and removal confirmation. Do not rely on casually disabling a device “for commissioning”; define approved test modes and risk controls during design.

Build OT cybersecurity into the Siemens PLC migration

A new PLC should not automatically inherit a flat network and shared passwords. Nor should an IT control be applied without considering production availability and physical safety. NIST SP 800-82 Rev. 3, published in September 2023, explains OT security in the context of unique performance, reliability and safety requirements. ISA’s public overview of ISA/IEC 62443 emphasizes lifecycle work and shared responsibility among asset owners, suppliers, integrators and service providers.

Minimum security items in the migration specification

• Update the old/new asset register and network drawing; close temporary or unmanaged connections.
• Define role-based access for PLCs, HMIs, engineering stations, gateways and remote support.
• Record permitted communication flows and reduce unnecessary paths and services.
• Define backup scope, controlled storage, restore procedure, restore test and change approval.
• Assign evaluation of vendor vulnerability notices and firmware/software updates.
• Control remote support identity, authorization, time window, logging and disconnection.
• Preserve time synchronization, events, alarms and change history for investigation.

The control must be operable by the factory. Individual accounts are weak if a night shift has no emergency recovery route; a shared administrator used every day makes changes untraceable. Design emergency elevation, custody and use records.

Referring to NIST or ISA/IEC 62443 does not by itself establish compliance or certification. Those claims require scope, requirements, assessment method and evidence. A practical starting point is to document which requirements the migration adopts and who accepts each residual risk.

PLC upgrade and replacement project flow

Plan by decision gates, not a generic number of days. Duration varies with source condition, communications, safety, cabinet work, material availability, outage and acceptance scope. The following is a sequence, not a standard schedule.

Initiation and survey

Define boundaries among asset owner, production, maintenance, quality, safety, IT/OT, machine builder and system integrator. Survey physical, software and operations. Put unknowns in the risk register. Confirm outage rules, blackout periods and production-release authority.

Basic and detailed design

Document target architecture, BOM, cabinet work, I/O, communications, safety scope, software strategy, HMI, security, test strategy and rollback. Separate equivalent behavior from improvements and write acceptance criteria before implementation.

Offline implementation and review

Build hardware, PLC, HMI and communications configurations. Retain conversion logs and manual-change evidence. Check compile warnings, libraries, licenses and firmware combinations. Review state transitions in critical sequences against the old intent.

FAT

Use real I/O where practical, simulation, signal injection and peer emulation. Test normal and abnormal behavior including recovery. Anything that cannot be proven in FAT is a documented SAT carry-over with reason, preparation and acceptance method—not an assumed pass.

Site changeover and SAT

Follow plant controls such as lockout/tagout. Execute backup, labeling, removal, installation, required electrical checks, power-up, I/O verification, dry operation, material run, quality confirmation and production release through authorized gates.

Stabilization and handover

Close or formally carry open items. Hand over restorable source, backups, drawings, licenses, credential control, training, spares, support contacts and change management. “The machine ran” is not enough if the accepted documentation and recoverable master are missing.

FAT and SAT acceptance content

Create tests from machine requirements, not from the author’s program structure. “Check all I/O” and “check auto mode” are not objective acceptance statements. Each test should capture prerequisite, action, expected result, evidence, authority, result and deviation.

Test abnormal recovery, not only alarm appearance

Select sensor disagreement, link failure, power cycle, emergency stop, blockage, drive fault or missing upper-level command according to machine risk. Check detection, safe output, understandable cause, prevention of unintended restart, controlled recovery and record retention.

Make the acceptance basis signable before shutdown

“Same as before” is disputed when the old state was never documented. Production, quality, maintenance, safety and project authority should agree what permits provisional run, conditional acceptance and final acceptance. Where product-quality evidence is required, define the approved measurement and decision process.

Make rollback an executable work package

“We will put it back if something goes wrong” is not a plan. Prove that old wiring can be restored, old software and parameters can be downloaded, and the decision can be made before the outage leaves insufficient recovery time.

Rollback package

• Verified old CPU, I/O, communication units, connectors and required cables.
• Running-version backups for PLC, HMI, drives and gateways, plus a working tool environment.
• Before-change photos, wiring and terminal records, addresses and parameters.
• Changeover/restore procedures, tools, labels and independent-check records.
• Decision gate, authorized decision maker, production communication and restart tests.
• Retention period for the old configuration and approval for disposal or reuse.

Set the rollback gate by calculating backward from the plant’s own allowed outage. The exact time is project-specific; do not borrow a generic hour figure from an article.

Estimate cost and duration with variables, not a headline rate

No universal price or shutdown duration can be responsibly stated before discovery. Break cost into hardware, panel/wiring, software, communication, HMI, safety, testing, site work, training, spares, logistics and risk response. Break schedule into design, procurement, implementation, FAT, shutdown preparation, SAT and stabilization.

A low hardware price can be outweighed by extensive field rewiring and debugging. A transition component or pre-test can reduce uncertainty in a suitable design. Compare total work to accepted production state and remaining operational risk, not only the parts invoice. Quantify benefit only from this machine’s work breakdown and test evidence.

Handover of PLC programs in a Thai factory

Projects often connect Japanese equipment owners, Thai production and maintenance, machine builders, local SIs and IT. The larger problem is frequently unclear ownership, not translation alone. Bilingual meetings are insufficient if alarms, drawings, source comments, maintenance procedures and change requests do not use the same controlled baseline.

Define the handover package in the specification

Include editable PLC/HMI/drive/gateway sources, compiled deliverables, tools and versions, licenses, credential-control method, BOM, drawings, network and I/O records, communication matrix, FAT/SAT evidence, backup/restore, change history, spares and training evidence.

Where protected software or third-party IP prevents full source delivery, define what maintenance is possible, who responds, under what terms, and whether escrow or a recovery route is available. Our PLC program handover guide for Thai factories covers governance principles that apply beyond one PLC brand.

Separate operator, diagnostic and change-control training

Operators need displays, alarms, recovery conditions and prohibited actions. Maintenance needs hands-on online diagnostics, module replacement, backup, communication checks and fault isolation. Program editors also need request, review, test, version control and formalization of emergency changes.

Completion should mean that the responsible person can perform the approved procedure and retain the required record—not merely attend a class. Adapt material to Thai roles, escalation, shifts and site rules. For broader outsourcing and standardization, see our machine control software development guide in Thailand.

Pre-order checklist

• Verify exact S7-300/ET 200M order numbers, firmware and as-built configuration.
• Compare the running CPU with the offline source.
• Prove the legacy project can be opened and, if needed, downloaded with working licenses.
• List every HMI, SCADA, PC, drive, controller and instrument communication peer.
• Define the safety boundary, authority and revalidation need.
• Separate equivalent migration from additional improvement.
• Verify BOM differences, dimensions, supply, terminals, wiring and environment.
• Separate FAT proof from SAT-only proof.
• Define pass, conditional acceptance, rollback trigger and authority.
• Test old/new backup and restoration environments.
• Define OT asset, flow, account, remote access, log and backup requirements.
• Include Thai permits, outage rules, language, training and support escalation.
• Assign ownership of sources, drawings, licenses, records and spares.

Common PLC upgrade and replacement failure patterns

Many failures begin with an unverified assumption rather than a lack of programming skill. A quotation says “source available,” but implementation reveals that it differs from the running CPU. One communication peer is omitted, and SAT is the first time anyone discovers that the production system cannot read the new data. Cabinet labels are surveyed, but an ET 200M in another building is left out of scope. Faster coding will not solve these conditions. Separate verified facts, unknowns and assumptions, and define the commercial and schedule process to follow when an assumption changes.

“Equivalent to existing” means different things to each department

Production may mean unchanged throughput, operation and quality. Maintenance may mean that alarms lead to a diagnosable cause and recovery path. Quality may need control of critical parameters and records. Safety needs preserved requirements and validation evidence. Decompose “equivalent” into departmental acceptance requirements, assign each to FAT or SAT, and name its evidence and authority.

Simultaneous cleanup makes differences untraceable

Reworking comments, tags, DBs, HMI, communications and sequences during migration can produce a cleaner system but obscure the cause of a fault. Classify each change as mandatory compatibility, maintenance improvement, production improvement or security treatment, then link its change ID to tests. Even when all changes share an outage, separate logical change sets improve FAT diagnosis and conditional acceptance.

FAT becomes a demonstration

Showing only familiar normal operation and testing whatever the customer notices on the day is not acceptance. Review the FAT specification in advance against machine requirements, change ledger, communication matrix, I/O, safety scope and alarms. Useful extra tests may be added, but must not replace agreed tests. Record “failed” separately from “not executed.”

Changeover completion is confused with production release

Power-on and one automatic cycle do not necessarily authorize production. Quality checks, abnormal recovery, shift handover, backups, temporary changes, enhanced monitoring and support coverage may remain. Use separate gates for technical completion, conditional production and final acceptance, with open items and owners at every gate.

Rollback assets are removed too early

If the old CPU and wiring are moved away after a brief successful run, restoration may become impossible when a condition-specific defect appears later. Define retention from acceptance coverage, representative production, quality approval and open issues—not elapsed time alone. Identify and control the old equipment so it is not borrowed as a spare for another machine.

Frequently asked questions

Does an S7-300 stop working after 1 October 2025?

No. 1 October 2025 is the type-cancellation milestone; it does not mean installed systems stop on that date. Siemens’ official blog places the phase-out announcement on 1 October 2023 and says the generally 10-year spare-parts availability starts from that announcement, while warning it may end earlier because of electronic-component scarcity. After type cancellation, components are handled as spare parts and may be repaired or, where applicable, exchanged. The lifecycle normally ends 10 years after the phase-out announcement. Exact items, regions, stock and delivery times are not guaranteed, so verify order numbers and plan both spares and migration.

Is automatic conversion enough for a PLC upgrade or replacement?

No. It is a starting point. Instructions, data, retention, startup, timing, communication, HMI, safety, diagnostics and libraries need review, followed by requirement-based FAT and SAT. Compilation and behavioral equivalence are different claims.

Does TIA Portal V21 support every old project?

That conclusion is not justified. Compatibility depends on CPUs, modules, firmware, OS, license, option packages and the project’s original environment. Check official compatibility information and test a controlled copy.

Should we fully standardize the program during the control-system modification?

It may improve maintenance but increases the change surface. For a constrained outage, establish an equivalent migration baseline and manage standardization as a separate requirement and test set. A full redesign needs its own requirements, acceptance and rollback decision.

What do a legacy-equipment upgrade and outage cost?

There is no responsible universal figure. I/O, communications, safety, source quality, cabinet work, supply, testing and site conditions differ. Build a survey, BOM, communication matrix, acceptance specification and changeover runbook, then estimate each work package.

What is required to localize PLC-program maintenance in Thailand?

A controlled editable master, working tools and licenses, version control, backup/restore, understandable diagnostic material, role-based training and change approval. Ask local staff to demonstrate diagnosis and restoration as part of acceptance.

Can OT security be a separate contract?

A specialist assessment can be separately scoped, but architecture decisions cannot ignore security. Asset records, flows, accounts, remote access, backups, logs and update governance belong in migration design. Any compliance or certification claim needs a defined scope and evidence.

Conclusion: make the Siemens PLC migration an accept-or-restore project

An S7-300/ET 200M migration in Thailand should begin with physical, software and operational discovery and integrate hardware mapping, behavior-preserving software work, communications, safety, OT security, FAT/SAT, training and handover. The objective is not merely to select a newer model. Success means approved machine behavior is protected, every deliberate change is traceable, acceptance is evidence-based, and the plant can restore the old state safely if the agreed gates are not met.

TOMAS TECH can support the early stage when exact models, source quality or acceptance boundaries are still unclear, including Thai-site discovery, migration strategy, FAT/SAT and handover scope. We validate the actual assets and requirements before defining a replacement. Discuss a Siemens PLC migration

Official references

• Siemens Blog: lifecycle explanation for S7-300 and ET 200M
• Siemens: Migration Guide SIMATIC S7-300 to S7-1500
• Siemens SCE Technical Support
• Siemens: TIA Portal
• Siemens: SIMATIC S7-1500 Controller
• NIST SP 800-82 Rev. 3
• ISA: ISA/IEC 62443 series overview

This article is general planning guidance. It is not a compatibility guarantee, machine-safety validation, standards certification, supply commitment or project schedule. Confirm current documents and site conditions for the exact equipment, and obtain approval from qualified, accountable parties.