CitectSCADA has been the dominant SCADA platform across Queensland coal mining and sugar processing for twenty years. It is running in nearly every coal preparation plant, at most bulk export terminals, and across most of the major sugar mills in the state. It is also a platform that AVEVA, which acquired Citect in 2017, has been progressively retiring in favour of PlantSCADA.
For sites running CitectSCADA, the migration to PlantSCADA is not optional indefinitely. Understanding what the migration involves, what changes, and what to plan for makes the difference between a managed transition and an expensive emergency.
What PlantSCADA actually is
PlantSCADA is not a rewrite of CitectSCADA. It is a re-branded and extended version of the same core engine, with a modernised development environment, enhanced graphics tools, expanded I/O driver support, and a new HTML5-based web client called Citect Anywhere that replaces the legacy Citect WebClient.
For a CitectSCADA project, this means the migration is an evolution, not a rebuild. Most of the project structure (pages, tags, equipment, trends, reports, alarms) carries across with relatively minor rework. The project opens in PlantSCADA’s development environment (formerly Citect Studio, now Plant SCADA Studio), and the compilation and runtime behaviour are recognisable to anyone who has worked in Citect.
That said, ‘relatively minor rework’ on a large site with thousands of pages, tens of thousands of tags, and complex multi-project structures can represent months of engineering effort.
What the migration process looks like
Phase 1: Backup and discovery
Before any migration work begins, a full backup of the production CitectSCADA project is taken, ideally using Citect Environment Manager, which creates a structured archive of all project files including include projects. The current CitectSCADA version is identified, and the server architecture (roles of each server: Primary I/O, Standby I/O, Primary Alarms, Standby Alarms, Display, Report) is documented.
Phase 2: Version conversion
PlantSCADA Studio can open CitectSCADA projects from version 7.x onwards and perform an automatic conversion. The conversion tool updates the project file format, migrates deprecated functions and parameters where possible, and flags items that require manual attention. The conversion report is the starting point for the remediation work.
Phase 3: Remediation and testing
The remediation phase addresses the items flagged by the conversion: deprecated Cicode functions, graphics that need updating for the new graphics engine, I/O device configurations that need reviewing for the updated driver library, and parameter files (Citect.ini) that have changed defaults or deprecated settings.
This phase also addresses the visual differences between the old and new graphics engines. PlantSCADA uses a vector-based graphics engine that renders existing CitectSCADA bitmap-based graphics. Sites that have invested heavily in custom graphics may find this phase is the most time-consuming.
Phase 4: Simulation and FAT
A virtualised test environment, a set of VMs replicating the server architecture of the production system, allows the migrated project to be fully tested before touching the production system. I/O communications can be simulated, alarm and trending behaviour validated, and operator displays checked for accuracy.
Phase 5: Production cutover
Production cutover is planned for a scheduled maintenance window. The approach depends on the site’s risk tolerance: some sites run the migrated PlantSCADA system in parallel with the production CitectSCADA for a period before cutting over; others perform a direct cutover. Either way, having a tested rollback plan, the ability to return to the production CitectSCADA system if the cutover encounters problems, is essential.
Citect Anywhere
One of the most significant features added in PlantSCADA is Citect Anywhere, an HTML5 gateway that allows operators and engineers to view and interact with the SCADA system from any web browser, without requiring the legacy Citect client software to be installed.
For sites where remote SCADA access is required, such as operations staff viewing process data from an office or engineers accessing the system during off-site support, Citect Anywhere delivered through a DMZ architecture provides a genuinely secure, client-software-free remote access solution. The gateway server lives in the DMZ; the SCADA servers remain in the OT network; and no direct connection is needed from the remote client to the OT network.
Common complications
The complications that most consistently require additional effort in CitectSCADA to PlantSCADA migrations:
- Cicode libraries: custom Cicode functions written for site-specific purposes may use functions or syntax that has been deprecated or modified. A full audit of the Cicode library is required.
- Third-party include projects: many Citect installations use vendor-supplied include projects (from PLC vendors, OEM equipment suppliers, or system integrators). These need to be either updated to PlantSCADA-compatible versions or replaced.
- Licensing: CitectSCADA licences are not directly transferable to PlantSCADA. AVEVA’s licence migration programme exists but requires engagement with the AVEVA sales team. Allow time for this.
- Multi-project structures: large sites with multiple include projects, cluster configurations, and redundant server sets require careful mapping of the existing architecture before migration begins.
About the author
Dennis Murphy RPEQ has worked with CitectSCADA and PlantSCADA across Queensland coal mining, sugar processing, and bulk handling operations for over fifteen years. Contact: [email protected]