The pattern is familiar to anyone who has worked in industrial technology adoption. A pilot programme delivers impressive results. Workers take to the technology quickly. Error rates fall. Productivity improves. The business case looks compelling. Leadership approves the next phase.
And then, somewhere between the controlled conditions of a pilot and the messy reality of a full-scale deployment, the programme stalls.
This is the AR pilot trap. And it catches more organisations than most would care to admit.
Why Pilots Succeed and Deployments Fail
The conditions that make an AR pilot successful are often the same conditions that make scaling it difficult. A well-run pilot is managed closely: a small, motivated user group, curated content, dedicated support, and careful measurement of outcomes. These conditions are not representative of a production environment.
In a production environment, you are dealing with the full population of workers — including those who are not early adopters, not particularly comfortable with technology, and not motivated by being part of a pilot programme. You are dealing with content that needs to be maintained, updated, and extended across multiple workflows, product lines, and locations. You are dealing with device management, software updates, and integration with enterprise systems that were never designed to support AR.
Most importantly, you are dealing with the absence of the special attention that characterised the pilot. The programme is no longer new. The executive sponsor has moved on to the next initiative. The vendor is focused on the next customer.
This is where AR deployments succeed or fail. Not in the technology — which is now mature enough for industrial deployment — but in the programme design.
The Five Determinants of Scaling Success
Based on programmes that have navigated this transition successfully, five factors consistently distinguish those that scale from those that stall.
Content architecture, not content volume
The instinct when scaling is to create more content. More work instructions, more training modules, more procedures. This is almost always wrong. The priority is a content architecture — a system for developing, reviewing, publishing, and retiring content — that can be maintained by the organisation without specialist support.
Organisations that succeed at scale treat AR content like they treat any other piece of operational documentation. It has an owner, a review cycle, a version history, and a governance process. Organisations that fail treat AR content as a project deliverable rather than a living operational asset.
Device management as infrastructure, not afterthought
Managing a fleet of twenty smart glasses in a pilot is manageable through informal processes. Managing a fleet of two hundred devices across multiple sites requires enterprise device management — software distribution, remote configuration, security policy enforcement, usage monitoring. This infrastructure needs to be designed before scale-up, not retrofitted after.
Integration with existing systems
The most common technical barrier to scaling AR is integration with existing enterprise systems — particularly ERP, asset management, and document management platforms. In a pilot, content is often manually maintained and distributed. At scale, this is not viable. The AR platform needs to receive content from authoritative sources automatically — work orders from ERP, drawings from document management, asset data from CMMS.
Resolving these integrations after a pilot has been approved for scale is expensive, slow, and disruptive. Designing for them from the outset is a structural advantage.
Change management as a programme workstream, not a communication plan
The difference between a change management plan and a change management programme is the difference between informing people that change is happening and actively enabling them to succeed in a changed environment. AR adoption at scale requires structured training, floor-level champions, clear feedback mechanisms, and a visible improvement cycle that demonstrates to workers that their input is heard and acted on.
Organisations that treat change management as a communication plan — a series of announcements and training sessions — consistently underestimate the complexity of embedding new technology into entrenched operational culture.
Measurement frameworks aligned to operational outcomes
Pilot metrics are often technology metrics: usage rates, session durations, error rates in controlled conditions. Operational metrics are different: maintenance cost per asset, first-time fix rates, training time to competency, unplanned downtime incidents. The transition from pilot to production requires a transition in measurement — from demonstrating that the technology works to demonstrating that it delivers operational value at scale.
A Note on Timing
One of the most underappreciated aspects of AR scaling is the importance of timing decisions about scope expansion. The temptation, after a successful pilot, is to expand aggressively — more workflows, more sites, more use cases simultaneously. This almost always produces worse outcomes than a deliberate, sequenced expansion that consolidates each new scope before adding the next.
The organisations that scale AR most successfully are those that resist the pressure to scale fast in favour of scaling right — building the operational muscle, the technical infrastructure, and the organisational capability that makes each subsequent expansion faster and more reliable than the last.
Immersive Realities supports organisations at every stage of AR adoption — from use case prioritisation through to enterprise scale. Get in touch to discuss your programme.