A legacy SCADA assessment should not begin with a product shortlist. It should begin with the decision the evidence must support: retain the current environment, extend selected functions, upgrade along a supported path, or replace components in controlled stages.
Age alone cannot answer that question. An older installation may remain manageable when backups are tested, source files are complete, support is available, and dependencies are understood. A newer system may carry more operational risk if it depends on undocumented scripts, shared accounts, fragile interfaces, or a recovery procedure that nobody has rehearsed.
The assessment must connect technical findings to operating consequences. It should show what can fail, which process or team would be affected, how the plant would detect the failure, how recovery would work, and who owns the response. The output is not just a score. It is a documented decision and a prioritized modernization backlog.
Start with the decision the assessment must support
Define the available paths before collecting data. A retain decision means the existing system can meet current requirements with controlled risk and a funded lifecycle plan. An extension adds functions such as browser access, consolidated history, or integration while selected control components remain stable. An upgrade follows a supported path within the platform family. Replacement moves functions to a different target architecture.
Legacy SCADA assessment: A structured evaluation of operational continuity, supportability, recovery, security, dependencies, data, operator fit, and lifecycle cost used to select a justified modernization path.
Research on industrial legacy modernization indicates that business continuity, operational stability, and risk shape legacy status more than technical age alone. The direct study concerned enterprise software, so it does not set SCADA replacement criteria. It does support a useful rule: judge the system by its operational condition and constraints, not by an arbitrary birthday. [1]
Write the assessment question in neutral language. “Which path provides an acceptable balance of continuity, support, change risk, and lifecycle cost?” is better than “Why must this system be replaced?” A predetermined conclusion encourages teams to collect feature gaps while overlooking viable controls or phased options.
Identify operational and recovery risks before scoring features
Start with the processes that depend on SCADA. Record required monitoring, commands, alarm response, reporting, historical evidence, operating modes, and recovery times. Then identify what happens when a server, network path, interface, historian, identity service, or engineering workstation becomes unavailable.
Recovery evidence: Demonstrated proof that configurations, applications, credentials, and data can be restored within approved operating limits using available people, procedures, and infrastructure.
A backup file is not recovery evidence. The assessment should establish when each critical component was last restored, where compatible hardware or virtual infrastructure is available, how credentials are recovered, and whether the team can rebuild communications and trust relationships. Test results, elapsed time, exceptions, and corrective actions are stronger than a procedure marked “reviewed.”
OT security guidance from NIST says controls must account for performance, reliability, and safety, and it warns against applying its recommendations as a generic checklist. Use that guidance for implementation practice, not as an international normative substitute. Security and recovery findings must be interpreted through plant risk, operating authority, and the applicable IEC requirements. [6]
Assess architecture, assets, and hidden dependencies
Use two linked inventories. The asset inventory covers PLCs, remote units, servers, operator stations, engineering workstations, network equipment, software, firmware, accounts, certificates, time sources, and responsible owners. The application inventory covers tags, calculations, screens, alarm rules, scripts, trends, reports, historian flows, interfaces, and custom objects.
Dependency map: A traceable model showing which assets, application objects, identities, interfaces, data flows, and operating procedures rely on one another to deliver a required function.
A flat asset register will not show that a production report depends on a calculation script, an obsolete database driver, a shared service account, and a time source on another network. Research on large industrial application modernization found that structural analysis, architectural layers, and inter-component dependencies were necessary inputs before transformation. SCADA has different object types, but the same discovery principle applies.
Protocol discovery needs more detail than a name. Record transport, versions, addressing, update behavior, write permissions, quality and timestamp handling, redundancy, diagnostics, and failure behavior. Peer-reviewed work on legacy PLC retrofit began by assessing native communications, compatible protocols, and feasible extension options. This does not prove that every device can be retained, but it shows why interface evidence should precede connector selection. [3]
Score supportability, security, integration, and operator fit
A useful score explains risk instead of hiding it. Rate each dimension using documented thresholds and attach evidence. Supportability can cover vendor status, spare availability, engineering tools, source files, specialist dependence, and time required to make a controlled change. Recovery can cover backup completeness, restore testing, compatible infrastructure, and achieved recovery time.
Security scoring should reflect architecture and responsibilities. IEC 62443-2-1 recognizes that IACS lifespans can exceed twenty years and that unsupported legacy components may lack native capabilities. That does not remove the asset owner’s obligation to manage risk. The assessment should identify unmet requirements, compensating measures, residual exposure, owners, and replacement triggers. [7]
Integration scoring should examine semantic quality as well as connectivity. Two systems may exchange values while disagreeing about units, timestamps, equipment identity, quality, or operating state. Operator fit should cover navigation, alarm behavior, command confirmation, degraded modes, response workload, and training. Industrial research also identifies data availability, knowledge management, stakeholder integration, complexity, and training as real adoption concerns. [5]
Do not assign universal weights. A loss of historical reporting may be critical at one regulated plant and inconvenient at another. A remote-access limitation may be acceptable at a staffed site but untenable across unmanned facilities. Document the reason for each weight and have operations, automation, maintenance, OT security, IT, and management review it.
Choose retain, extend, upgrade, or replace with thresholds
Retain when requirements are met, risks are controlled, recovery is proven, and support actions are funded. The decision should include review dates and triggers. Extend when the control foundation is stable but higher-level visibility, data, or integration needs improvement. Peer-reviewed industrial cases show that legacy PLCs can sometimes be integrated incrementally when communication and physical-interface constraints are understood. [3]
Upgrade when a supported path can reduce risk without preserving unacceptable architectural limitations. Verify compatibility through object inventories and tests rather than product-family assumptions. Replace when critical recovery, security, support, performance, or integration gaps cannot be reduced economically within the existing environment.
Compare every path under the same scope and time horizon. Include the current system’s maintenance, extended support, manual work, specialist dependence, recovery exposure, and constrained change capacity. A fully engineered target should not be compared with an artificially zero-cost status quo.
Have something in mind to discuss?
We're here to help you find the answers. Let's talk.
Convert the assessment into a modernization backlog
Turn each finding into an action with a risk, owner, dependency, evidence requirement, due date, and decision trigger. Some actions will reduce current-state risk, such as testing restores, separating accounts, preserving source files, or documenting interfaces. Others prepare modernization, such as normalizing tag metadata, retiring unused screens, rationalizing alarm rules, or defining historical-data retention.
Sequence work by operational dependency. An interface cannot be migrated reliably before its source and consumers are known. A target platform cannot be accepted before performance, failure, and recovery criteria exist. Training cannot be finalized before operating roles and screen behavior are stable.
Keep three lists: immediate controls, modernization prerequisites, and target-state work packages. This distinction prevents a large replacement project from becoming the only response to risks that need treatment now. It also allows management to approve staged funding while preserving a coherent architecture.
Clear next steps you can take with CENTO
Start by comparing the assessment with the live guide to digital twin cross-system integration. Use it to test whether a coexistence layer could connect SCADA, MES, ERP, historians, and legacy controllers while the plant keeps viable control functions in place. This keeps a narrow technical finding from driving a replacement decision before the integration path is understood.
Use the live guide to OPC UA industrial data integration when documenting candidate interfaces. The inventory should still connect PLC interfaces, tags, displays, alarms, history, reports, users, and custom logic to owners and acceptance methods. That baseline supports vendor discussions without assuming that one protocol resolves every migration dependency.
CENTO’s official documentation describes browser access and integration with existing SCADA, MES, and ERP environments. Teams can review CENTO SCADA as a possible CENTO coexistence or target layer, then verify protocol details, control boundaries, user roles, recovery behavior, and migration evidence against site requirements.
Use industrial system integration to examine how existing data sources could be connected without assuming immediate control-layer replacement. A guided CENTO demonstration should use representative tags, alarms, roles, and failure cases from the assessment. Launch the demo or contact the team for a walkthrough focused on the plant’s documented risks.
Frequently asked questions
What is the purpose of a legacy SCADA assessment?
The assessment determines whether the current environment should be retained, extended, upgraded, or replaced. It connects technical condition to operational continuity, recovery, security, support, integration, data, operator needs, and lifecycle cost. Its output should be a justified decision and a prioritized backlog, not only a maturity score.
Does an old SCADA system always need replacement?
No. An older system may remain viable when requirements are met, risks are controlled, recovery is tested, and support actions are funded. Replacement becomes more credible when critical support, recovery, security, performance, or integration gaps cannot be contained economically. Age should trigger investigation rather than dictate the answer.
Which assets should the assessment include?
Include PLCs, remote units, servers, operator and engineering stations, network equipment, software, firmware, accounts, certificates, time sources, and owners. Add application objects such as tags, screens, alarms, scripts, trends, reports, historian flows, interfaces, and custom components. Dependencies between these items are often more important than the count.
How should SCADA risk be scored?
Define evidence-based thresholds for operational continuity, supportability, recovery, security, maintainability, integration, data continuity, and operator fit. Weight them according to plant consequences and applicable requirements. Avoid universal scoring weights because the same technical weakness can have very different safety, production, or compliance effects at different facilities.
What is the difference between extending and replacing SCADA?
Extension adds selected functions while preserving viable legacy components, such as retaining PLC control while adding a supported historian or supervisory layer. Replacement transfers functions to a different target environment. An extension still needs documented interfaces, failure behavior, security responsibilities, lifecycle ownership, and acceptance tests.
What should happen after the assessment?
Convert findings into immediate controls, modernization prerequisites, and target-state work packages. Assign owners, dependencies, evidence, deadlines, and decision triggers. Then build the migration inventory, define target architecture and acceptance criteria, compare lifecycle scenarios, and prepare an RFP only after the organization understands the scope it needs suppliers to address.
Sources
- Tobias Böhm, Jens Guan Su Tien, Mohini Nonnenmann, Tom Schoonbaert, Bart Carpels, Andreas Biesdorf. “Model-Driven Legacy System Modernization at Scale.” ACM ReCode '26 author manuscript. 2026.
- “Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators.” CISA and international partners. 2025.
- Eduardo Vieira do Nascimento, Vinicius dos Santos, Rafael Vidal Aroca. “An applied approach for integrating legacy PLC-based systems into Industry 4.0 environments using low-code platforms.” The International Journal of Advanced Manufacturing Technology. 2026.
- Hamood Ur Rehman, Jack C. Chaplin, Leszek Zarzycki, Mark Jones, Svetan Ratchev. “A level-based classification of technical enablers for the realisation of self-configuration in production systems.” The International Journal of Advanced Manufacturing Technology. 2025.
- Fabian Bermpohl, Simon F. Schäfer, Oliver Neumann, Eckart Reihlen, Thomas Dickopf, Thomas Gebel, Thomas Neuhäuser, Rüdiger Daub. “Industrial study on holistic digital factory models.” Production Engineering. 2025.
- Keith Stouffer, Michael Pease, CheeYee Tang, Timothy Zimmerman, Victoria Pillitteri, Suzanne Lightman, Adam Hahn, Stephanie Saravia, Aslam Sherule, Michael Thompson. “Guide to Operational Technology (OT) Security, SP 800-82 Rev. 3.” National Institute of Standards and Technology. 2023.
- “IEC 62443-2-1:2024 — Security program requirements for IACS asset owners.” International Electrotechnical Commission. 2024.
- “IEC 62443-3-3:2013 — System security requirements and security levels.” International Electrotechnical Commission. 2013.
