Why 60% of Industrial IoT Deployments Stall After the Pilot Phase

Walk into most industrial facilities that ran an IoT pilot in the last three years and you'll find the same thing: a gateway box collecting dust on a shelf, a few sensors still blinking, and a project champion who got reassigned to something else. The pilot data was good. The ROI case looked solid. But nothing shipped.

This isn't a niche problem. Industry surveys consistently put the percentage of IIoT pilots that never reach full production somewhere between 55% and 70%. We've worked with enough facilities to have our own view of why, and it almost never comes down to the technology failing.

The Pilot Is Designed to Succeed, Not to Scale

A well-run pilot picks a specific machine in a specific area with a sympathetic operator and a clear metric. That's the right way to run a pilot. But it also means every hard problem gets deferred.

In a twelve-sensor proof of concept on a single Modbus TCP network, you don't hit protocol fragmentation. You don't run into the IT security team's objections to outbound MQTT traffic. You don't have to figure out how to handle the 47 different timestamp formats coming off legacy PLCs. You just hook up the sensors, point them at a time-series database, and call it done.

Then you try to expand to 400 sensors across three buildings and six different equipment vendors. That's when the real work starts — and most organizations weren't ready for it.

The Data Integration Problem Nobody Planned For

In a typical brownfield manufacturing facility, sensor data arrives in at least four or five distinct formats. You'll have Modbus RTU on older PLCs, OPC UA on newer CNC machines, proprietary serial protocols on HVAC units, BACnet on building systems, and maybe a mix of HART and 4-20mA analog inputs on process instrumentation. Each has different polling semantics, different timestamp resolution, and different error handling behavior.

During a pilot, engineers manually configure the mappings and write normalization code specific to the machines in scope. That work isn't documented, isn't reusable, and doesn't transfer to the next building. When the deployment team shows up to expand Phase 2, they start from scratch.

We've seen facilities spend eight to twelve weeks just building a data normalization layer before a single dashboard can go live. If that work isn't part of the platform from day one, it becomes a custom engineering project that the IT department didn't budget for and OT doesn't have the skills to maintain.

Network Architecture Gets Decided Twice

Pilots typically run on a separate VLAN or even on the deployment team's mobile hotspot. That's fine for testing. It becomes a problem when IT realizes the production expansion requires persistent outbound connections from the OT network, and their security policy explicitly prohibits that.

Getting a firewall exception for MQTT over port 8883 to an external broker sounds like a minor IT ticket. In a mid-size manufacturer with a mature IT security team, that ticket can take three months to resolve. In critical infrastructure — utilities, water treatment, chemical plants — the process involves written risk assessments, change control boards, and sometimes regulatory review. We've seen this single issue hold up production deployments for six months.

The organizations that move through pilots quickly into production have typically resolved this architectural question before the pilot ends: where does the data boundary between OT and IT sit, who owns the integration point, and what egress is permissible. That conversation needs to happen with IT security in the room, not after the pilot results deck is done.

Sensor Density Changes Everything

A twelve-sensor pilot generates maybe 50,000 readings per day. That's nothing. A production deployment of 800 sensors sampling at 1Hz generates 69 million readings per day. The storage, query performance, and alert evaluation infrastructure that worked in the pilot will fail under that load — often badly.

Time-series databases like InfluxDB and TimescaleDB handle high-cardinality sensor data well, but they require schema design and retention policy decisions that aren't obvious upfront. If the pilot team stored everything in a relational database with a naive schema, the production team inherits a rewrite. If nobody thought about data retention, the storage costs balloon within 90 days.

Alert evaluation is its own problem. Evaluating 800 threshold rules in near-real-time on a single-node setup requires a very different architecture than running twelve rules in a pilot. We've seen facilities deploy pilots that trigger alerts via simple Python scripts polling a database every 30 seconds. That doesn't survive scaling.

The Organizational Gap

Technical issues are fixable. The harder problem is organizational. Pilots are owned by someone — usually a forward-thinking maintenance manager or an OT engineer who cares about the problem. Production deployments require ownership from IT, OT, finance, and operations simultaneously. When the pilot champion moves on or gets busy, there's often no one holding the thread.

The facilities that go from pilot to production fastest tend to have two things: an executive sponsor who treats the IoT program as a capital project with a budget line, and a defined RACI between IT and OT for ongoing operations. Without those, every decision — from which sensors to deploy next to who pays for the gateway hardware — requires a new round of negotiation.

What Actually Works

From where we sit, the pilots that transition to production share a few characteristics. The integration architecture handles at least the four or five protocols present in the facility before the pilot ends, not after. The network path for sensor data to reach the analytics layer is formally approved by IT security, not assumed. And the pilot scope includes at least one full maintenance cycle so the team can demonstrate ROI with real downtime prevention data, not just dashboard screenshots.

The technology is not the bottleneck. Industrial IoT hardware is reliable, connectivity options are mature, and the analytics tools exist. What stalls deployments is underestimating the integration and organizational work that sits between twelve sensors and eight hundred.