The short answer is that a pilot is ready for production only when it has reduced uncertainty in the areas that would otherwise cause operational, quality, integration, or validation failure at scale. In regulated manufacturing, that threshold is usually higher than teams expect.
A good go or no-go review should be based on evidence, not enthusiasm. A pilot can look successful in one line, one shift, or one product family and still fail in production because master data is incomplete, edge cases were excluded, users were hand-held, integrations were manually patched, or change control was bypassed.
Process fit is proven. The pilot has covered the real workflow, including exceptions, rework, holds, approvals, and handoffs. If the pilot only handled the ideal path, that is not enough for production.
Operational performance is stable. The solution performs consistently across shifts, users, and normal production variability. You should see repeatable cycle time, error rate, transaction latency, and uptime results, not a one-time good week.
Data readiness is acceptable. Part masters, routings, BOMs, characteristics, reason codes, user roles, document versions, and equipment references are complete enough to run without constant manual correction. Many pilots fail at scale because the data cleanup work was deferred.
Integration reliability is demonstrated. Interfaces to MES, ERP, PLM, QMS, historians, identity systems, and reporting layers have been tested under realistic load and failure conditions. Manual workarounds that were tolerable in a pilot often become production bottlenecks.
Traceability and audit trails are fit for purpose. Records are attributable, time-sequenced, version-controlled, and retained appropriately for the process being digitized. If the production state weakens lineage or evidence quality compared with the current method, that is usually a no-go.
Validation and change control are complete where required. If the system affects product quality, release, inspection, training records, or controlled documentation, required validation activities and approvals must be complete before broader deployment. This depends on your quality system and use case.
User readiness is real. Training is complete, role-based access works, supervisors know how to manage exceptions, and support materials reflect the actual production workflow. Adoption risk is often underestimated when pilot users were selected for tolerance and enthusiasm.
Support ownership is defined. There is named ownership for application support, integration support, master data stewardship, incident response, backup and recovery, and change requests. A pilot can survive on project-team heroics. Production cannot.
Cybersecurity and access controls are acceptable. Authentication, authorization, logging, network placement, and technical data handling have been reviewed for the target environment. This matters even more when production rollout extends into OT-adjacent workflows or defense-related programs.
Rollback and business continuity are workable. If the rollout fails, the plant can recover without losing records, stopping critical operations for too long, or creating uncontrolled dual-process states. If there is no practical fallback, the deployment risk is higher than many teams admit.
Economics and capacity are credible. The expected benefit is realistic after support cost, validation effort, integration maintenance, licensing, and rollout labor are included. A pilot may show local gains that disappear once enterprise overhead is added.
The pilot depended on manual data fixes, project-team intervention, or vendor engineering support that will not exist in steady state.
Exception paths such as rework, deviations, nonconformance handling, or outside processing were excluded.
Core integrations are still batch-based, fragile, or unreconciled.
Validation evidence is incomplete, or change control has not caught up with the proposed production state.
There is no clear owner for support, administration, or future configuration changes.
KPIs improved during the pilot, but measurement conditions were not representative of normal operations.
The rollout requires replacing too many adjacent systems at once.
Use a small set of decision metrics tied to production risk, not just adoption or interface counts. Typical examples include:
Process completion rate without manual intervention
Exception rate and exception handling time
Transaction or synchronization success rate across connected systems
Record completeness and traceability gaps
User error rate by role and shift
Mean time to resolve incidents
Change turnaround time for controlled updates
Impact on throughput, queue time, scrap, rework, or release delays where relevant
The exact thresholds are site-specific. A high-volume line, an aerospace assembly environment, and a regulated batch process will not use the same tolerances.
In most plants, moving from pilot to production does not mean replacing the existing stack. It usually means proving that the new capability can coexist with legacy MES, ERP, PLM, QMS, document control, and local spreadsheets without breaking traceability or creating duplicate system-of-record confusion.
That is why full replacement strategies often fail. The qualification burden is high, the validation cost is real, downtime windows are limited, integration debt is already substantial, and asset lifecycles are long. A pilot that only works if three incumbent systems are retired is often not a production-ready pilot. A pilot that can coexist, exchange data cleanly, and improve one constrained workflow is more likely to scale safely.
A useful test is this: if the project team stepped away for 30 days, could plant operations, quality, and IT run the process, support the users, manage changes, and defend the records? If the answer is no, it is probably still a pilot.
So the key go/no-go criteria are not whether the pilot proved value in principle, but whether it proved control, repeatability, supportability, and acceptable risk in the real operating environment.
Whether you're managing 1 site or 100, C-981 adapts to your environment and scales with your needs—without the complexity of traditional systems.
