A utility company contracted an IT services company to specify and deploy industrial servers into high voltage substations across their network. The IT team specified a particular Intel server motherboard, a reasonable choice by enterprise IT standards. We quoted it, they ordered, and the rollout began. Eighteen months later, Intel discontinued the board.
The utility was mid-way through a multi-year deployment across dozens of substations. The original servers, already installed, had been tested, validated and documented against that specific hardware configuration. The replacement motherboard meant redoing all of that testing and documentation, a significant cost that had nothing to do with the hardware price and everything to do with the operational context, that the IT specification had not accounted for.
At that point, we recommended switching to an industrial-grade server motherboard from Advantech, with the same core features: IPMI out-of-band management, VMware certification, ECC memory support. The critical difference was a platform lifecycle commitment of up to 15 years, backed by an embedded Intel Xeon CPU with a similarly long production roadmap. We were then able to build identical servers for years without the customer having to repeat their validation process.
This isn’t a story about IT getting it wrong. It’s a story about applying the wrong procurement logic to the target environment.
The line between IT and OT
IT and OT have fundamentally different relationships with hardware.
In enterprise IT, a three to five year refresh cycle is normal and often desirable. Hardware is standardised across the organisation, refreshed on a predictable schedule, and the cost of transition is managed through established processes. The assumption is that hardware will be replaced regularly, and the systems running on it are designed to migrate across platforms.
In operational technology, hardware supports process control, SCADA, monitoring, and safety systems that are validated against a specific configuration and expected to run for a decade or longer. Changing the hardware isn’t just a procurement exercise. It triggers retesting, revalidation, updated documentation, and in regulated industries, formal change management processes. The cost of a platform change often exceeds the cost of the hardware by a large margin.
These are not competing philosophies. They are rational responses to different operating requirements. The problems start when one is applied where the other belongs.
Where enterprise logic breaks down
When IT procurement standards are applied to OT hardware without adaptation, several common issues emerge.
- Short platform lifecycles. Enterprise server and PC platforms are refreshed every one to two years. For an IT department replacing office desktops, this is irrelevant. For an OT environment where the same hardware needs to be available for spares and fleet consistency over many years, it creates a rolling obsolescence problem. The substation server project is a clear example: a mainstream Intel board that was a perfectly good product, but with a lifecycle that didn’t match the deployment timeline.
- Standardisation without context. IT departments naturally want to standardise on a single hardware platform across the organisation. This reduces support complexity and purchasing cost. But a PC that works well in an air-conditioned office doesn’t survive on a factory floor or inside a switchboard in a remote substation. Wide operating temperature range, fanless operation or over-provisioned and filtered cooling, wide voltage DC input, and industrial-grade components are not optional extras in these environments. They are baseline requirements.
- Refresh cycles that disrupt stable systems. A policy of replacing all PCs every four years makes sense for office productivity. Applied to a SCADA server that was validated against a specific hardware and software combination, it forces a revalidation cycle that costs far more than the hardware and introduces risk to a system that was running reliably.
- Vendor preferences that exclude industrial suppliers. Enterprise procurement often channels purchasing through preferred vendors who supply commercial IT equipment. Industrial hardware from specialist manufacturers may not appear on the approved vendor list, not because it’s unsuitable, but because nobody in the procurement chain has evaluated it for OT requirements.
Where IT involvement adds value
This isn’t an argument for excluding IT from OT decisions. IT teams bring genuine expertise in areas that OT environments increasingly depend on.
- Cybersecurity. OT networks that were once completely isolated are increasingly connected to corporate networks or the internet for remote monitoring and data collection. IT teams understand network security, patching strategies, and access control in ways that many OT engineers don’t. Their involvement in securing OT networks is valuable and increasingly necessary.
- Backup and recovery. IT disciplines around scheduled backups, offsite storage, and documented recovery procedures are directly applicable to OT systems, and are often neglected in OT environments. An IT team that helps implement proper backup practices for SCADA servers and HMI configurations is adding real value.
- Network architecture. As OT systems become more connected, the network design and management expertise that IT teams provide becomes important. Segmentation, monitoring and bandwidth management all benefit from IT input.
The goal is not to keep IT out. It is to make sure that OT requirements are understood and weighted appropriately in decisions that affect operational hardware.
What good collaboration looks like
The organisations that get this right tend to share a few characteristics.
- OT engineers are involved in hardware specification. The people who understand the operating environment, the software dependencies and the validation requirements have input before a purchasing decision is made, not after.
- Platform lifecycle is a specification criterion. When selecting hardware for OT environments, the expected availability of the platform is evaluated alongside price, performance and features. A product that will be discontinued in 18 months isn’t suitable for a five-year rollout, regardless of how good its specifications look today.
- Procurement understands the total cost of a platform change. The hardware cost is visible. The retesting, revalidation, documentation and change management costs are often invisible to procurement but very real to the engineers responsible for the systems. Making these costs explicit changes the procurement calculus.
- Spares planning is part of the initial specification. We have supplied SCADA servers for solar farms and battery energy storage systems where individual sites came back years later needing spare units. Because the original specification used hardware with a long production lifecycle, those spares could be built to the same configuration without revalidation. If the original hardware had been a short-lifecycle commercial platform, those spares would have required new hardware, new testing, and potentially new software configuration.
How ESIS can help
We work with both OT engineers and IT teams to specify industrial hardware that meets the operational requirements of the site while aligning with broader organisational standards where possible. We understand the lifecycle, environmental, and validation constraints that differentiate OT from enterprise IT, and we can help both sides of the conversation find practical common ground!
If you are specifying servers, industrial PCs, or panel PCs for operational environments and want to ensure the hardware selection accounts for long-term availability, environmental conditions and total cost of ownership, we can help.
Contact us to discuss your requirements.
