How to assess industrial automation suppliers for legacy integration

A supplier should make your installed equipment’s limitations visible before asking you to commit to an integration design. For legacy automation, the strongest candidate can demonstrate compatibility with your specific hardware and software versions, explain how failures will affect production, and provide a workable recovery path. A broad protocol list or an impressive demonstration on new equipment offers much less assurance.

When assessing industrial automation systems suppliers, start with three questions: can they connect without destabilizing existing control, can they prove the proposed migration fits your shutdown window, and can your maintenance team support the result after commissioning? Keeping older controllers may be sensible where the process remains reliable and the upgrade mainly adds visibility. Replacement deserves closer consideration where inaccessible programs, unsupported components, or inadequate control performance make continued integration difficult to sustain.

Give suppliers an integration boundary they can actually assess

Supplier comparisons become unreliable when each bidder makes different assumptions about the installed plant. One may price a monitoring gateway, another may assume PLC replacement, and a third may exclude undocumented machine interfaces. Establish a common technical baseline before comparing proposals.

Record controller models, firmware revisions, communication modules, HMI and SCADA versions, engineering software, network connections, and interfaces to drives, instruments, and production systems. Include available source files, passwords, software licenses, electrical drawings, and backups. Identify which records have been checked against the equipment and which remain uncertain.

The inventory should describe behavior as well as hardware. A machine may exchange only a small number of signals with the rest of the line, yet those signals can govern permissives, recipe selection, reject handling, or restart sequencing. Losing their meaning during an upgrade can disrupt production even when every device appears connected.

Define the intended change precisely. Reading production counts into a reporting system is a different assignment from changing setpoints through SCADA. Replacing an HMI introduces operator workflow and alarm handling questions. Replacing a PLC introduces control logic, timing, I/O, and validation questions. Each requires a different level of supplier evidence.

Ask bidders to return an annotated architecture showing retained equipment, new components, data paths, control ownership, and unresolved dependencies. Their response should distinguish confirmed compatibility from assumptions requiring inspection or testing. A proposal that treats missing information as a discovery task can be credible; one that silently assumes it away creates commercial and technical exposure.

Documentation access is an early decision gate. A supplier’s experience with a controller family does not guarantee access to your application. Establish who can lawfully obtain and modify the program, whether required engineering tools are available, and whether a backup can actually be restored. If those conditions cannot be met, require a revised integration boundary before proceeding.

Test compatibility at the application level

“Supports Modbus,” “OPC UA ready,” or “compatible with your PLC brand” should begin a technical discussion. These statements do not establish that the proposed system can preserve your application’s data meaning, update behavior, or control requirements.

Request a compatibility matrix tied to the installed versions and proposed interfaces. For each connection, the supplier should identify the driver or gateway, required licenses, supported operations, known restrictions, and evidence behind the claim. Exact hardware testing provides stronger evidence than experience with a related product; both should be clearly distinguished.

For example, a gateway may read registers successfully while interpreting a multi-register value incorrectly because of word order. A SCADA driver may display a value without preserving its quality status or source timestamp. A write request may reach the controller but bypass an intended operator permission or conflict with another system’s command. These are application failures despite successful communications.

Focus the review on the interfaces that could affect operation:

• Data interpretation: addresses, data types, scaling, engineering units, byte and word order, timestamps, and handling of invalid values.
• Timing and load: polling behavior, connection limits, controller communication load, and acceptable delay for each function.
• Command ownership: which system may write, how permissions are enforced, and what happens when requests conflict.
• Failure behavior: how stale data, lost connections, gateway restarts, and partial network failures become visible to operators and control logic.

Set timing requirements from the process. A dashboard may tolerate delayed updates; a coordinated machine function may not. Avoid accepting a generic “real-time” claim without a defined requirement and a measurement method. The supplier should also explain how added communication traffic will be assessed on older controllers and networks.

Protocol conversion deserves particular scrutiny when the proposal moves closed-loop control or time-sensitive coordination across a new gateway. A connection suitable for monitoring may be unsuitable for that purpose. Require evidence for the intended function, including behavior under load and during faults.

Changes involving safety functions need a separate assessment by suitably qualified personnel. Ordinary connectivity testing cannot establish that a modified safety function remains valid. The proposal should identify safety-related boundaries, potential effects of the work, and responsibility for any required validation.

Retrofit references help when they illuminate these same constraints. Ask about the equipment retained, interfaces changed, documentation gaps, commissioning scope, and support responsibilities. A project on the same brand is less informative if it involved a new installation with complete source files. Where references can be checked, ask how recovery and handover were handled, rather than relying on a general statement that the project succeeded.

Make migration and recovery part of the supplier demonstration

A demonstration should test the weakest assumptions in the proposed architecture. Watching values appear on a screen proves little about restart behavior, write permissions, alarm handling, or recovery from a failed cutover.

Select a representative integration slice: an older controller, a meaningful set of signals, the proposed communication path, and the relevant HMI or SCADA functions. Include a difficult dependency where practical, such as recipe transfer, an undocumented handshake, or an interface with limited communication capacity. Agree on acceptance criteria before the supplier configures the demonstration.

The test sequence should cover normal operation, defined faults, recovery, and restoration of the previous configuration. For each step, specify the expected result and the evidence to record. Useful evidence includes communication logs, controller diagnostics, configuration exports, alarm records, and observed operator behavior.

Keep read and write testing distinct. For monitoring, test scaling, update intervals, stale-data indication, and reconnection. For commands, also test authorization, rejection of invalid requests, acknowledgments, interlocks, and behavior after interrupted communications. Where writes could affect production or safety, use an isolated setup or an approved controlled procedure.

A bench setup can establish important interface behavior, but it may not reproduce plant network traffic, electrical conditions, mechanical response, or interactions with other machines. Ask the supplier to state what the demonstration proves and what requires site acceptance. This prevents a successful laboratory test from becoming an unsupported promise about production performance.

The migration plan should account for the entire shutdown window: preparation, backups, installation, checks, process verification, and the time needed to revert. Require dependencies and decision points, including the latest point at which rollback must begin to preserve the agreed recovery window.

A backup file alone is insufficient evidence of recoverability. Recovery may also require compatible firmware, engineering software, activation rights, communication settings, and working replacement hardware. Ask the supplier to demonstrate restoration where feasible and document the prerequisites wherever a full rehearsal is impractical.

Rollback must address operational state as well as configuration. Recipe changes, product tracking, historian records, and work in progress may need reconciliation after a cutover is reversed. Define who authorizes reversion, who performs it, and how operations determines that the line is ready to restart.

Use phased migration where the interfaces permit it. Establishing monitoring before enabling commands can reduce uncertainty and provide a baseline for comparison. Some tightly coupled processes require a coordinated cutover; in those cases, supplier selection should give greater weight to rehearsal quality, fault analysis, and available commissioning resources.

Assess the support burden that remains after commissioning

Integration can preserve useful equipment while adding dependencies that the plant must support for years. Evaluate the complete stack: gateways, drivers, servers, operating systems, engineering tools, licenses, and custom code. A low hardware price can conceal substantial maintenance obligations.

Ask the supplier to identify who supports each component and who owns incidents spanning several components. If a driver fails after an operating system update, your team needs a defined route to diagnosis and resolution. Contractual clarity matters when the equipment manufacturer, software vendor, and integration contractor are separate organizations.

Cybersecurity review should follow the proposed architecture. Examine which legacy devices would become reachable, how network boundaries restrict access, and how remote support is authorized, logged, and disabled. Older devices may have limited security features, so the supplier should explain the protective controls around them and the operational implications of those controls.

Request a practical procedure for updates and configuration changes. Some legacy combinations cannot be updated independently without affecting compatibility. The supplier should describe how changes will be reviewed, tested, deployed, and reversed, with responsibilities assigned to the plant and support providers. Claims of compliance with a security standard should be accompanied by a clear scope; they do not by themselves demonstrate that the proposed installation is secure.

Handover requirements should enter the contract before award. Specify editable project files where applicable, configuration exports, interface documentation, license entitlements, account administration, and restoration instructions. Clarify rights to custom code and any restrictions on third-party maintenance. Your technicians should be able to diagnose routine faults and restore agreed functions with the delivered materials.

For cross-border suppliers, translate support promises into service arrangements. Confirm access to engineers familiar with the installed equipment, coverage during your operating hours, remote-access feasibility, and the route to on-site assistance. Check where replacement parts are held and how shipping, customs clearance, or applicable trade restrictions could affect recovery. A response-time commitment has limited value unless it defines the response and the resources behind it.

Compare proposals over an agreed operating horizon. Include integration engineering, shutdown work, recurring software charges, training, spares, support, and foreseeable migration dependencies. Where costs remain uncertain, require assumptions and exclusions to be visible. An inexpensive proposal with an unresolved interface should not receive the same cost confidence as one backed by demonstrated compatibility.

Choose on evidence, with clear conditions for award

Separate mandatory conditions from scored preferences. Lawful access to required software, acceptable failure behavior, a viable recovery plan, and appropriate treatment of safety-related changes can be mandatory gates. Relevant experience, documentation quality, support coverage, maintainability, and lifecycle cost can then differentiate suppliers that pass those gates.

Record the evidence behind each assessment. Distinguish demonstrated behavior, documented compatibility, transferable experience, and an untested assertion. This makes the shortlist easier to defend and exposes where a proposal needs a limited discovery phase before a full integration commitment.

A capable supplier may conclude that a particular legacy interface should remain isolated or that a controller needs replacement before the desired function is feasible. That conclusion can strengthen a proposal when it follows from specific constraints and includes a workable transition. The supplier to advance is the one whose integration claims survive testing and whose remaining uncertainties have named owners, defined actions, and an acceptable effect on production.