For decades, the SCADA system on a piece of pharmaceutical processing equipment came from the same OEM that supplied the equipment itself. The fluid bed came with the fluid bed's SCADA. The granulator came with the granulator's SCADA. Each one ran on a per-tag license, on hardware the OEM specified, and locked to a vendor whose interest in long-term support drifted as the next generation of equipment shipped.
That model is breaking down, and Ignition by Inductive Automation is the platform most pharma sites are moving toward when they replace it. Here's what's driving the shift and what to think about before you start one yourself.
What's wrong with the proprietary OEM model
Three things, mostly.
The first is licensing economics. OEM SCADA typically prices per tag, per client, per workstation — with seat licenses on top. A modest pharma line with a few hundred tags can run into five-figure annual maintenance even before you count the cost of adding clients. Across a facility with five or six OEM systems, the math gets painful fast.
The second is integration ceilings. OEM SCADA was designed to monitor one piece of equipment, not to talk to anything else in the facility. Getting a Glatt's process data into an enterprise historian, a vendor's BMS, or a lab LIMS typically requires custom interfaces and ongoing maintenance fees — and the OEM's interest in supporting those integrations declines steadily over the equipment's life.
The third is support cliffs. OEM SCADA runs on whatever Windows version was current when the equipment shipped. Ten years later, the OS is unsupported, the SCADA version no longer runs on supported OS versions, and the OEM's response is "upgrade your equipment." A perfectly functional fluid bed gets sold a $300K SCADA refresh because the original is no longer maintainable.
What Ignition does differently
Ignition's commercial model and architecture are the inverse of the OEM model:
- Unlimited tags, unlimited clients. One server license. Scale as your facility scales without per-tag economics.
- Vendor-neutral by design. Native drivers for Allen Bradley, Siemens, Modbus, OPC-UA, and most other protocols. The Glatt PLC, the ACG PLC, and the building BMS all show up in the same SCADA — under one tag tree, one alarm system, one historian.
- Modern stack. Java-based platform, web-deployed clients, runs on Linux or Windows. Doesn't go obsolete when one OS version sunsets.
- Active development. Inductive Automation ships meaningful updates every year. New modules — reporting, vision, sequential function charts, perspective — expand the platform's reach without disrupting installed projects.
The 21 CFR Part 11 question
The most common pharma question we get about Ignition is whether it can support 21 CFR Part 11 compliance. The short answer is yes, but the longer answer matters.
Ignition provides the technical capabilities required by Part 11 — secure user authentication, audit trail logging, electronic signatures, time-stamped records, role-based access. But Part 11 compliance is a property of how the system is configured and validated, not of the platform itself. The same is true of every OEM SCADA. Moving to Ignition doesn't make a system Part 11 compliant any more than staying on an OEM SCADA did. The validation work is comparable in both cases.
The Ignition projects we see passing FDA inspections cleanly all have one thing in common: the validation package treats Ignition as a configured application, not as a black-box vendor product. The audit trail configuration, the user access matrix, and the change management procedure are all defined and exercised as part of the OQ.
How a migration usually goes
A pharma SCADA migration is almost never a hard cutover. The typical path:
- Parallel build. Ignition project is built and connected to the same PLC tags as the existing OEM SCADA. Both systems run in parallel for weeks or months. Data is compared.
- Read-only validation. Operators start using Ignition for monitoring while the OEM SCADA remains the system of record. Validation activities focus on data integrity, alarm parity, and historian completeness.
- Cutover. Once Ignition has been validated as the system of record, the OEM SCADA is decommissioned. The PLC itself stays untouched throughout.
The PLC is the key. As long as Ignition is talking to the same PLC tags the OEM SCADA was talking to, the equipment doesn't know anything changed. Process control logic is unaffected. The migration is a SCADA migration, not an equipment migration.
When not to move
Ignition is a good answer when an OEM SCADA is approaching end-of-support, when license costs are growing faster than the value being delivered, or when integration across multiple OEMs is a strategic priority. It's not the right answer for equipment that's two years old, fully supported, and only ever needs to be monitored in isolation. The validation cost of a migration is real, and migrating on a schedule that the existing system would have outlasted doesn't make economic sense.
Key Takeaways
- OEM SCADA's per-tag licensing, limited integration, and OS-tied support cliffs are pushing pharma sites toward platform-based alternatives
- Ignition's unlimited-tag licensing and vendor-neutral driver library unify multiple OEMs under one SCADA — usually at lower long-term cost
- Part 11 compliance is a property of configuration and validation, not of the platform — the validation work is comparable across SCADA platforms
- Migration is almost always parallel-run with the PLC untouched; the equipment doesn't know the SCADA changed