Modernizing Bailey INFI 90 Symphony HMIs Running on OpenVMS Alpha

Modernizing an HMI Without Replacing the Entire INFI 90 System

Many Bailey INFI 90 systems continue to operate reliably decades after their original installation. Their controllers, communication modules, termination units, and field I/O may still perform the required control functions.

The most immediate lifecycle problem is often located above the controller layer.

Operator stations may depend on aging AlphaStation hardware, unsupported graphics adapters, obsolete storage devices, and old OpenVMS Alpha software environments. Replacement parts become difficult to obtain, while experienced OpenVMS and Bailey Symphony engineers become less available.

The example considered here includes four AlphaStation 255 workstations. Each station runs OpenVMS Alpha and hosts Bailey Symphony operator interface functions for a Bailey INFI 90 distributed control system.

The objective is not necessarily to replace the entire DCS. A more practical objective is to remove dependence on aging AlphaStation hardware while preserving stable controllers, field wiring, I/O modules, control logic, and process operations.

That distinction changes the modernization strategy.

The project is primarily an operator-interface and computing-platform migration. It becomes a full DCS migration only when controller lifecycle, cybersecurity requirements, production objectives, or support conditions justify replacing the lower control layers.

There are several possible modernization routes. However, they preserve different parts of the existing system.

An Alpha emulator can preserve almost the complete software environment. An OpenVMS x86 migration preserves the operating-system family but requires application migration. An OPC-based HMI replacement preserves the controller layer while rebuilding the operator interface. An ABB evolution strategy can modernize the wider Symphony architecture in stages.

No route should be described as a simple PC replacement.

Figure 1. Three principal modernization routes can preserve different portions of the installed Bailey INFI 90 and Symphony investment.

Why Cloning the AlphaStation Disk Is Not Enough

Disk cloning is useful for preserving an installed OpenVMS Alpha environment. It can capture the operating system, application files, device configuration, user accounts, Bailey software, databases, graphics, and site-specific settings.

However, a disk clone does not convert Alpha software into x86 software.

The cloned operating system still contains Alpha processor instructions. Its kernel, boot loader, system libraries, applications, and hardware drivers were built for the Alpha architecture.

A standard modern PC uses an x86-64 processor. It also presents different storage controllers, network devices, interrupt structures, graphics hardware, firmware interfaces, and peripheral buses.

VMware, VirtualBox, Hyper-V, and conventional x86 hypervisors virtualize x86-compatible hardware. They do not normally translate Alpha processor instructions into x86 instructions.

Therefore, placing an OpenVMS Alpha disk image inside an ordinary x86 virtual machine does not make that image bootable.

The virtual machine may provide a virtual disk, virtual network adapter, and virtual graphics device. OpenVMS Alpha still expects an Alpha processor and supported Alpha-era devices.

This is why two concepts must remain separate:

Virtualization normally presents virtual hardware using the same processor architecture as the host.

Cross-architecture emulation reproduces another processor and hardware environment in software.

OpenVMS Alpha requires the second approach when the original Alpha binaries and operating system must remain unchanged.

Disk cloning is therefore viable in three limited situations.

The first is recovery onto the same AlphaStation model with compatible storage and peripherals.

The second is recovery onto another supported Alpha system after completing the required device and configuration changes.

The third is restoration into an Alpha emulator that reproduces a compatible AlphaServer or AlphaStation environment.

Cloning alone does not solve the architecture problem. The target environment must still understand and execute Alpha machine instructions.

Alpha Emulation Preserves the Largest Part of the Existing Investment

Alpha emulation is normally the least disruptive path when the existing Symphony software must remain operational without source-code changes.

An Alpha emulator runs on modern x86 hardware but presents a virtual Alpha system to OpenVMS. The original operating system and applications continue to see an Alpha-compatible hardware environment.

Products such as CHARON-AXP are designed for this purpose. The emulator replaces the physical Alpha processor, memory architecture, storage controllers, Ethernet adapters, and other supported devices with software-defined equivalents.

The x86 server runs Windows or Linux as the host environment. The Alpha emulator runs above that host. OpenVMS Alpha then runs inside the emulated Alpha system.

This approach is different from porting OpenVMS to x86.

The original OpenVMS Alpha installation remains an Alpha installation. The Bailey Symphony binaries remain Alpha binaries. The emulator translates or reproduces the required Alpha hardware behavior.

This can preserve:

• The installed OpenVMS Alpha operating system.

• Existing Bailey Symphony applications.

• Operator graphics and display databases.

• Alarm configurations and historical files.

• User accounts and command procedures.

• Existing site-specific utilities.

• Application interfaces that depend on the Alpha environment.

• Operator workflows that would otherwise require retraining.

The practical migration usually involves creating a verified image or backup of the original Alpha disks. That data is restored to virtual disk containers used by the emulator.

The emulator configuration must reproduce suitable CPU, memory, disk, network, and peripheral characteristics. The team may also need to map physical serial ports or network interfaces through the host system.

Alpha emulation can substantially reduce dependence on obsolete physical hardware. It can also simplify backup because virtual disk files can be copied using modern storage infrastructure.

However, the term “zero change” should be used cautiously.

The application code may remain unchanged, but the environment still requires engineering. Device mappings must be checked. Network interfaces must be configured. OpenVMS licenses and application licenses must be reviewed.

The emulator must also be tested with the Bailey communication interface used at the site.

A generic OpenVMS application may operate correctly while a specialized DCS interface fails because it depends on a particular network adapter, bus interface, serial device, or timing behavior.

The exact AlphaStation 255 configuration must therefore be inventoried before selecting an emulator profile.

The Bailey Communication Interface Is the Critical Emulation Test

The most important emulation question is not whether OpenVMS reaches the login prompt.

The important question is whether the emulated station communicates correctly with the Bailey INFI 90 system under full operating conditions.

The interface may depend on Ethernet, serial communication, a Bailey network interface, or specialized communication hardware. Site configurations can vary significantly.

Before committing to Alpha emulation, engineers should document:

• The physical network interface installed in each AlphaStation.

• The communication protocol used between Symphony and INFI 90.

• Device names assigned within OpenVMS.

• Network addresses and node definitions.

• Required DECnet, TCP/IP, LAT, or proprietary services.

• Serial-port settings where applicable.

• Any external licensing keys or hardware dongles.

• Redundancy and failover behavior between operator stations.

• Time synchronization requirements.

• Graphics and keyboard functions used by operators.

An emulator supplier may support common Alpha Ethernet and storage devices. That does not automatically confirm support for every proprietary Bailey interface.

If the existing HMI depends on a specialized physical adapter that cannot be virtualized, the emulator route may require an alternative communication gateway.

The project should therefore include a bench test using a cloned station and access to a representative Bailey network.

The test must include more than static tag reading. Operators should verify real-time values, commands, alarms, acknowledgement, trends, display navigation, printing, event handling, and station recovery.

Performance should also be tested during alarm bursts and high tag-update activity.

OpenVMS x86-64 Is a Different Migration Route

Modern OpenVMS is available for the x86-64 architecture. It can operate in supported virtualized environments on modern servers.

This creates an additional migration option that was not available during many earlier INFI 90 modernization discussions.

However, OpenVMS x86-64 does not directly run OpenVMS Alpha binaries as though they were native x86 applications.

The application environment must be migrated.

Source code may need to be transferred, reviewed, recompiled, linked, and tested for x86-64. Third-party libraries and layered products must also be available for the target version.

The central question is whether the installed Bailey Symphony software has an x86-compatible OpenVMS version.

If the software vendor never released that application for OpenVMS x86-64, moving the operating system alone does not preserve the HMI.

Site-developed programs may be portable when their source code and build environment remain available. Closed commercial applications cannot normally be rebuilt without vendor support.

This route may still be practical for custom data servers, historians, utilities, reports, and integration applications that run beside the Symphony HMI.

It is less likely to preserve an old proprietary Symphony operator environment without a supported application release.

An OpenVMS x86 migration assessment should identify:

• Every installed executable and layered product.

• Available source code and build procedures.

• Compiler and runtime dependencies.

• Database products and file formats.

• Proprietary communication libraries.

• Graphics or windowing-system dependencies.

• License availability for x86-64.

• Required changes caused by architecture differences.

• Performance and timing assumptions.

This route has stronger long-term potential than moving from Alpha to another discontinued hardware architecture. It can place compatible OpenVMS workloads onto supported x86 virtualization infrastructure.

It should nevertheless be described as an application migration project, not a disk-cloning project.

Why an Itanium Migration Is Usually a Transitional Option

OpenVMS was also released for HPE Integrity servers using the Itanium architecture.

Migration tools and engineering methods exist for moving some Alpha applications to OpenVMS Integrity. This once provided a supported path away from aging Alpha hardware.

Today, however, Itanium hardware is itself a legacy platform.

A move from Alpha to Integrity may remove one obsolete hardware dependency while creating another. Suitable servers, parts, storage interfaces, and specialist expertise will continue to become less available.

Itanium can still be relevant when a site already owns supported Integrity infrastructure. It may also be relevant when a required layered product exists for Integrity but not for x86-64.

For a new modernization project, it should generally be evaluated as an intermediate compatibility route.

The business case must explain why moving to Integrity is preferable to Alpha emulation, OpenVMS x86 migration, or HMI re-platforming.

OPC Re-Platforming Preserves the Control Layer

OPC re-platforming replaces the operator-interface layer while keeping the existing INFI 90 controllers and field I/O.

A communication server connects to the Bailey system and exposes process tags to a modern HMI or SCADA platform.

The new HMI handles displays, alarms, trends, security, operator commands, reports, and workstation services.

This route removes dependence on the original Symphony operator application. It also avoids the need to run OpenVMS Alpha on the new operator stations.

The architecture commonly includes:

• Existing Bailey INFI 90 controllers and I/O.

• A compatible Bailey communication interface.

• An OPC DA, OPC UA, or vendor-specific data server.

• A modern HMI or SCADA platform.

• Operator and engineering workstations.

• Optional historian, reporting, and alarm-analysis services.

A field example referenced in the source material used a RoviSys OPC server with GE CIMPLICITY. The reported system operated successfully, but the project required reconstruction of operator displays and animation logic.

This example should not be interpreted as an automatic product recommendation for every INFI 90 installation.

The selected server must support the specific Bailey network, communication modules, controller generation, tag count, update rate, redundancy requirements, and command functions at the site.

The same applies to the HMI platform.

GE CIMPLICITY is one possible enterprise HMI/SCADA platform. Other systems may also be viable when they provide the required OPC connectivity, graphics, alarms, scripting, redundancy, security, and lifecycle support.

Figure 2. An OPC-based migration preserves the INFI 90 control layer while replacing the legacy Symphony operator environment.

OPC Connectivity Does Not Convert Existing Screens

An OPC server provides data connectivity. It does not normally convert old HMI displays into a new HMI format.

The original Symphony screens may contain static graphics, dynamic symbols, color changes, numerical values, bar graphs, alarm indicators, navigation buttons, command controls, trends, and custom function templates.

These elements must be recreated in the target HMI.

Simple displays can be redrawn directly. Complex displays may contain hidden scripts or expressions that are not immediately visible.

Engineers must understand how every animated object obtains and processes its data.

A valve symbol may not simply follow one output tag. Its color and position may depend on open feedback, closed feedback, command state, interlock status, communication quality, and equipment mode.

A motor symbol may use separate tags for start command, running feedback, stopped status, trip, local control, maintenance state, permissives, and alarm inhibition.

Moving only the visible graphics can therefore create an HMI that looks correct but behaves incorrectly.

The migration team must document the functional meaning behind each display element.

This work includes:

• Mapping every dynamic object to its data source.

• Recreating animation expressions.

• Verifying command confirmation and security.

• Rebuilding navigation and display hierarchies.

• Recreating alarm classes and priorities.

• Confirming engineering units and decimal precision.

• Rebuilding historical and real-time trends.

• Testing invalid, uncertain, and failed communication states.

• Reproducing operator messages and guidance.

• Replacing unsupported fonts and symbols.

The effort is therefore determined by display complexity, not only by display count.

A Modern HMI Should Not Blindly Copy Every Legacy Display

Manual recreation creates an opportunity to improve the operator interface.

Legacy HMI graphics often use bright colors for normal equipment, dense process diagrams, decorative piping, and inconsistent alarm indications.

These conventions may have been reasonable when the original system was developed. They are not always ideal for current control-room practices.

A modernization project should review:

• Display hierarchy.

• Alarm visibility.

• Navigation consistency.

• Equipment state presentation.

• Use of color.

• Trend accessibility.

• Operator response requirements.

• Screen resolution and workstation layout.

• Accessibility and readability.

Normal operating conditions should remain visually quiet. Strong colors should identify abnormal states that require attention.

Operators should be able to move from a plant overview to an affected unit, equipment faceplate, trend, alarm history, and diagnostic display without excessive navigation.

However, excessive redesign can create another risk.

Operators may have used the original screens for many years. Changing every symbol, color, and navigation path during the same project can increase training requirements and cutover risk.

A balanced approach retains familiar process relationships while improving alarm presentation and navigation.

Tag Extraction Must Be Treated as an Engineering Work Package

The source material raises the possibility of exporting Bailey tag data to CSV. It does not provide a confirmed universal procedure.

There should therefore be no assumption that one export command will produce a complete, clean HMI database.

Possible sources of tag information include:

• Symphony configuration databases.

• Existing display definitions.

• Controller configuration and engineering records.

• Bailey communication-server databases.

• OPC server browse functions.

• Alarm configuration files.

• Historical databases.

• Printed or archived tag lists.

• Site engineering spreadsheets.

OPC browsing can provide a practical starting point after the server establishes communication with the Bailey system.

It may expose tag names, item identifiers, descriptions, quality, and current values. Some servers also support exporting the browsed namespace.

However, an OPC namespace may not include every field needed by the new HMI.

Alarm priorities, engineering limits, display groupings, operator notes, command security, and equipment relationships may be stored elsewhere.

Some OPC servers expose tags using generated names that differ from the original Symphony names.

The project should build a controlled tag master containing at least:

• Original tag name.

• New HMI tag name.

• OPC item identifier.

• Description.

• Data type.

• Read or write permission.

• Engineering units.

• Scaling information.

• Alarm limits and priority.

• Update rate.

• Associated display.

• Validation status.

• Test result.

This master becomes the reconciliation record between the legacy and new systems.

Tag Count Is Not the Only Communication Requirement

A successful browse test does not prove that the OPC architecture can support the complete HMI.

Engineers must evaluate active tag count, requested update rate, change frequency, alarm activity, command traffic, and server redundancy.

A system may contain tens of thousands of configured tags. Only a portion may be active on operator displays at one time.

The server and HMI should be tested under realistic conditions.

Important performance checks include:

• Time required to open a complex display.

• Delay between a field change and HMI animation.

• Alarm delivery during event bursts.

• Trend collection at the required sampling rate.

• Command execution and feedback time.

• Recovery after network interruption.

• Failover between redundant servers.

• Behavior after controller restart.

• Quality status during communication failure.

• CPU, memory, and network loading.

Commands require particular attention.

Reading values through OPC may be relatively straightforward. Writing values safely requires access control, command validation, feedback confirmation, and correct handling of communication failures.

The team should test every operator command type, not only one representative tag.

ABB Symphony Plus Provides a Broader Evolution Route

An OPC replacement is not the only route for an installed Bailey system.

ABB continues to position Symphony Plus as an evolution platform for older Bailey, INFI 90, Harmony Rack, and Symphony installations.

A phased ABB modernization may preserve sections of the installed control and I/O architecture while introducing newer operator, engineering, network, controller, or I/O components.

This route can be attractive when the organization wants a vendor-supported lifecycle strategy rather than an independent HMI replacement.

The project may modernize the operator environment first. Controllers and I/O can remain in service until their lifecycle or operational value justifies replacement.

Later phases can address communications, controllers, engineering tools, and field interfaces.

The exact migration architecture depends on the installed system generation.

Bailey INFI 90, INFI 90 OPEN, Network 90, Harmony, Symphony, and Symphony Plus installations do not all use the same interfaces.

Module names and network terminology must be verified from site drawings and hardware inventories.

Organizations maintaining the existing control layer can also review available ABB Bailey INFI 90 and Network 90 components when planning spare coverage, lifecycle support, and phased modernization.

This internal link is relevant because modernization projects often require the old system to remain operational during engineering, testing, and staged cutover.

Maintaining suitable spare controllers, communication modules, power supplies, and I/O modules can reduce risk during that transition.

A Custom or Open-Source HMI Is Possible but Requires Ownership

A custom HMI can be developed using open-source or commercial software frameworks.

The source material mentions a VMS-resident server with a Qt-based modern client. Architectures of this type can separate the server-side data connection from the operator client.

This route can provide flexibility and avoid dependence on one HMI vendor.

It can also become a long-term software-development commitment.

The organization must own or maintain:

• The communication server.

• Tag database.

• Client application.

• Graphics framework.

• Alarm processing.

• Historian integration.

• User authentication.

• Cybersecurity updates.

• Deployment and version control.

• Documentation and training.

Qt, Python, C++, web technologies, or other frameworks can produce capable industrial interfaces. The difficulty is not drawing a process graphic.

The difficulty is creating a dependable operator system that behaves correctly during communication failures, server restarts, alarm floods, user changes, and abnormal plant conditions.

A custom platform should be selected only when the organization has a sustainable engineering team or a reliable long-term integrator.

Licensing Can Determine Whether a Technical Route Is Practical

Legacy industrial software often uses licensing mechanisms tied to hardware identifiers, Ethernet addresses, license databases, dongles, or vendor-issued authorization keys.

A cloned system may boot correctly but refuse to start the Symphony application because the virtual hardware identity changed.

The migration inventory should include:

• OpenVMS operating-system licenses.

• Bailey Symphony application licenses.

• Database licenses.

• Network and communication licenses.

• Emulator licenses.

• HMI and OPC point-count licenses.

• Historian licenses.

• Redundancy options.

• Engineering-client licenses.

• Runtime-client licenses.

Written confirmation should be obtained before choosing the final platform.

Technical compatibility without legal license availability does not create a deployable solution.

Cybersecurity Must Be Designed Into the Replacement

Old AlphaStation systems were frequently installed before modern industrial cybersecurity practices became standard.

They may operate on isolated networks with limited remote access. Replacing them with Windows servers, modern SCADA clients, OPC servers, and Ethernet infrastructure changes the attack surface.

The new architecture should define separate control, server, engineering, and enterprise network zones.

Firewalls should permit only required communication paths. Remote access should use managed authentication and recording.

Operator accounts should follow role-based permissions. Engineering functions should not be available from every HMI client.

OPC write access should be restricted to the tags and stations that require it.

The design should also address:

• Operating-system patching.

• Antivirus or application control.

• Backup and recovery.

• Time synchronization.

• Security logging.

• Removable-media controls.

• Vendor remote support.

• Certificate management for OPC UA.

• Account lifecycle management.

Cybersecurity controls must not prevent operators from responding during plant events. The design should balance protection with availability and deterministic operation.

The Migration Should Begin With an Evidence-Based Inventory

Before selecting a route, engineers should document the existing system in detail.

The inventory should include all four AlphaStations and identify whether their configurations are truly identical.

Record:

• AlphaStation model and processor configuration.

• Memory capacity.

• Disk type and logical volumes.

• OpenVMS version and patch level.

• Installed Bailey software versions.

• Layered products and databases.

• Graphics hardware and display resolution.

• Network adapters.

• Serial interfaces.

• Bailey communication hardware.

• Node names and addresses.

• Startup command procedures.

• License files.

• Backup procedures.

• Operator-station redundancy.

• Connected printers and external devices.

• Historical and alarm data retention.

The team should also collect screenshots of every display. Dynamic states should be captured when possible.

Record normal, stopped, running, alarmed, inhibited, local, manual, automatic, and communication-failed states.

This evidence is essential when the new screens are tested.

A Bench System Is Mandatory

No modernization route should be tested for the first time on the live production system.

A bench environment should reproduce enough of the installed architecture to validate communication and operator functions.

For an emulator project, the bench should contain a cloned OpenVMS Alpha environment and the proposed emulator configuration.

For an OPC project, it should include the selected communication server, HMI software, representative graphics, and access to a safe Bailey test node or simulated data source.

The bench test should verify:

• System boot and application startup.

• Communication with the Bailey system.

• Total accessible tag count.

• Read and write operations.

• Tag scaling and engineering units.

• Alarm generation and acknowledgement.

• Trend collection.

• Display animation.

• Command security.

• Printer and report functions.

• Server restart behavior.

• Network failure behavior.

• Redundancy and failover.

• Backup restoration.

• Operator response time.

The test results should be witnessed by operations, control engineering, maintenance, and cybersecurity representatives.

Parallel Operation Reduces Cutover Risk

The original AlphaStations should remain available during the initial deployment of the replacement system.

The new HMI can operate in parallel while engineers compare values, alarms, trends, and commands.

Parallel operation allows mismatches to be identified before the legacy station is removed.

The team should reconcile:

• Displayed process values.

• Status indications.

• Alarm priorities.

• Alarm timestamps.

• Command results.

• Trend values.

• Equipment mode.

• Communication quality.

• Security permissions.

Not every difference represents an error. The new system may use improved scaling or alarm presentation.

Every difference should still be explained and approved.

The legacy stations should remain recoverable until the new HMI passes a witnessed site-acceptance test and an agreed operational period.

Choosing the Correct Migration Path

Choose Alpha emulation when:

The existing Symphony application must remain unchanged. Source code is unavailable. Operator graphics are complex. Retraining must be minimized. The Bailey communication interface can be supported by the emulator architecture.

Choose OpenVMS x86 migration when:

The required applications are available for x86-64 or can be rebuilt. Source code and engineering knowledge remain available. The organization wants to retain OpenVMS while moving to a supported x86 environment.

Choose OPC re-platforming when:

The INFI 90 controller and I/O layers remain dependable. The organization wants a modern HMI platform. Engineering resources are available to rebuild and validate displays, alarms, tags, and command logic.

Choose an ABB evolution route when:

The organization wants a broader vendor-supported modernization program. Future phases may include operator systems, engineering tools, network interfaces, controllers, and I/O.

Choose a custom HMI when:

The organization has specialized requirements and can support long-term software development, testing, cybersecurity, and lifecycle maintenance.

Retain the existing system temporarily when:

The migration interfaces remain unclear. Backups are incomplete. Licensing is unresolved. Tag databases are unavailable. Bench testing cannot yet reproduce the Bailey communication path.

A Practical Phased Modernization Plan

Phase 1: Preserve the existing environment.

Create verified image backups of every AlphaStation. Record hardware, software, network, licensing, and startup details. Test restoration wherever possible.

Phase 2: Identify the communication architecture.

Document exactly how each Symphony station communicates with INFI 90. Confirm whether the interface can be emulated or replaced by a supported server.

Phase 3: Build a proof of concept.

Test one cloned station on an Alpha emulator or connect one OPC server to a representative Bailey node.

Phase 4: Create the tag master.

Reconcile controller tags, OPC item identifiers, engineering units, commands, alarms, and display usage.

Phase 5: Rebuild representative displays.

Select several screens containing different animation, alarm, command, and trend requirements.

Phase 6: Complete bench acceptance.

Test full tag loading, communication failure, server restart, alarm bursts, command behavior, and backup restoration.

Phase 7: Deploy in parallel.

Operate the new and old HMIs together. Compare values and operator responses.

Phase 8: Conduct witnessed cutover.

Use an approved test procedure. Keep the AlphaStations available as fallback.

Phase 9: Retire legacy hardware gradually.

Do not destroy the original images, configuration records, licenses, or hardware until long-term acceptance is complete.

Frequently Asked Questions

Can an OpenVMS AlphaStation disk be cloned directly to a modern PC?

No. The image contains Alpha machine code and expects Alpha-compatible hardware. A modern x86 PC cannot boot it directly. The image must be restored onto compatible Alpha hardware or an Alpha emulator.

Can VMware or VirtualBox run OpenVMS?

They can run supported OpenVMS x86-64 releases. They do not convert an old OpenVMS Alpha installation into an x86 application. OpenVMS Alpha requires Alpha emulation.

Can the original Symphony displays be preserved?

They can usually be preserved when the complete Alpha environment runs under a compatible emulator. They normally require manual recreation when moving to another HMI platform.

Does an OPC server automatically export every Bailey tag?

Not necessarily. OPC browsing may provide a useful namespace, but alarm configuration, display relationships, commands, descriptions, and engineering metadata may require additional extraction and reconciliation.

Is GE CIMPLICITY the only replacement HMI?

No. It is one possible platform and appears in the field example provided with the source. The final selection should depend on communication support, redundancy, licensing, cybersecurity, engineering resources, and operator requirements.

Is migrating from Alpha to Itanium still worthwhile?

It may be justified when required software is available only for Integrity systems or when existing Integrity infrastructure is already supported. It is generally a transitional route rather than the strongest long-term modernization strategy.

Can the INFI 90 controllers and I/O remain installed?

Yes, when they remain reliable and the selected communication architecture supports them. HMI modernization can be completed separately from controller and I/O replacement.

Should the old AlphaStations be removed immediately after cutover?

No. They should remain available as a tested fallback until the new operator environment passes functional, performance, and operational acceptance.

The Correct Solution Depends on What Must Be Preserved

The main technical error in many legacy HMI plans is treating the operator station as an ordinary PC.

An AlphaStation running OpenVMS Alpha and Bailey Symphony is a complete hardware and software environment. Its processor architecture, operating system, communication interfaces, application binaries, licenses, graphics, and control-system connections are interdependent.

A disk clone preserves data. It does not translate that environment to another architecture.

Alpha emulation provides the most direct route when the complete Symphony installation must survive unchanged.

OpenVMS x86-64 provides a modern operating-system path when applications can be migrated or rebuilt.

OPC re-platforming provides a practical route when the INFI 90 control layer remains valuable but the operator layer should be replaced.

ABB Symphony Plus evolution can provide a broader staged strategy when the organization wants to modernize beyond the HMI.

The final decision should follow a verified inventory, communication-interface study, licensing review, proof of concept, bench test, and witnessed operational acceptance.

There is no zero-effort swap. There are, however, several controlled migration paths that can protect the existing process-control investment while removing dependence on aging AlphaStation hardware.