The case for centralizing vision AI infrastructure across a manufacturing facility is clear. Shared compute reduces hardware cost. Central model management reduces retraining effort. A unified data layer makes cross-zone quality intelligence possible. The governance architecture that regulatory audits require becomes manageable rather than chaotic.

The obstacle is not the case. The obstacle is the transition.

A manufacturing plant running production cannot stop its quality inspection systems while a new centralized platform is built and deployed. Every day of downtime in a quality-critical inspection system is a day of either manual inspection fallback or unverified production output. Neither is acceptable in a plant operating under IATF 16949 or customer-specific quality requirements.

The manufacturers that have successfully built centralized vision AI platforms in live production environments have not solved this by accepting downtime. They have solved it by sequencing the build so that new infrastructure is added alongside existing systems rather than replacing them. Here is what that sequencing looks like.

The Core Principle: Add Before You Replace

The most important design decision in a centralized vision AI platform build is to add the centralized layer before migrating any existing applications to it.

This sounds obvious. In practice, most platform projects are planned the other way around. The team designs the target architecture. They plan the migration of existing applications to that architecture. They discover during migration that the existing applications are more complex to move than anticipated. Production risk forces them to pause. The project stalls.

The approach that avoids this starts with the centralized management layer as a standalone addition to the existing infrastructure. It runs in parallel with all existing applications. No application migrates until the central layer is proven stable. The first migration happens with the application that carries the least production risk. Success on the first migration builds the organisational confidence and the technical knowledge to move the next one.

The existing applications continue to run throughout this process. Production inspection does not stop. The new platform is built around them.

The Four Phases of a Non-Disruptive Centralisation Build

Phase 1: Infrastructure assessment and shared compute deployment

Before any software or AI work begins, the physical infrastructure needs to be assessed and upgraded where necessary.

Network connectivity between manufacturing zones is the most common physical constraint. Edge devices in multiple zones need reliable, low-latency connectivity to the central management layer. In older facilities, the network infrastructure may not have the capacity or the reliability to support this. Identifying and addressing these gaps before deploying the platform prevents the most expensive type of failure: discovering the constraint after the platform is deployed and expected to be operational.

The shared compute infrastructure, GPU servers or cloud GPU allocation, is then deployed in the plant's IT environment. It is sized to serve all planned applications at full utilisation, with headroom for growth. It does not yet serve any applications. It is infrastructure waiting to be connected.

The key point is that nothing changes in the production environment during this phase. The existing vision AI applications continue to run exactly as before. Phase 1 is additive, not disruptive.

Phase 2: Central management platform and data layer

With shared compute in place, the central management platform is deployed. This is the software layer that will handle model versioning, deployment management, performance monitoring, and the unified data collection from all applications.

58% of AI vision installations run entirely at the edge, with another 27% using hybrid edge-cloud configurations. The architecture for the central management platform needs to reflect this reality. The management functions run centrally. The inference functions run at the edge, close to the production line, where latency requirements demand it.

The central data layer is also established in this phase. This is the unified repository where inspection results from all applications will eventually flow. It is built with the schema and the governance architecture required to store IATF-compliant inspection records across all manufacturing zones consistently.

Again, nothing in production changes. The central management platform is running. The data layer is ready. No applications have been connected to either yet.

Phase 3: First application migration

The first application to migrate to the central platform is the proof of concept that determines whether subsequent migrations happen quickly or slowly.

Choose the first application carefully. It should be significant enough that its successful migration demonstrates real value. It should be simple enough that the migration itself carries manageable risk. And it should be operated by a team that is technically capable and willing to work collaboratively through the process.

The migration follows a specific sequence. The existing application continues to run in parallel during migration. The new version of the application is deployed to the central platform. Both run simultaneously and their outputs are compared. When the central platform version matches or exceeds the existing application's performance on identical inputs, the cutover happens. The existing standalone installation is retained as a fallback for a defined period. Only when the central platform version has run stably in production for that period is the standalone installation decommissioned.

This parallel running approach eliminates the risk of a direct cutover. If the central platform version behaves unexpectedly, the fallback is available without interrupting production inspection.

The first migration also generates the reusable components that make subsequent migrations faster. The integration patterns for connecting edge devices to the central management layer. The data pipeline configuration for sending inspection results to the unified data layer. The model deployment workflow for pushing models from the central platform to edge devices. Each of these is built once for the first migration and reused for every subsequent one.

Phase 4: Progressive migration of remaining applications

Each subsequent application migration follows the same parallel running and cutover approach as the first. The pace of migration is determined by production schedules, application complexity, and the organisational capacity to manage migrations alongside normal operations.

Manufacturers who have progressed from single-line applications to multi-site rollouts in days instead of months have done so by building the migration pattern in Phase 3 and then executing it repeatedly in Phase 4. The first migration is the hardest. Each subsequent one is faster because the infrastructure is already there and the team has done it before.

The pace recommendation for most manufacturing environments is one application migration per month during the consolidation phase. This allows the team to learn from each migration, address any issues before the next one, and maintain the bandwidth to manage their normal operational responsibilities alongside the migration work.

What Good Looks Like at Each Stage

The risk with a phased build is that "phased" becomes a euphemism for indefinite. Clear milestones at each phase prevent the project from drifting.

At the end of Phase 1, shared compute infrastructure is deployed and network connectivity between all planned zones has been assessed and upgraded where necessary.

At the end of Phase 2, the central management platform is running, the unified data layer is accepting test data, and the model deployment workflow has been tested end to end with a non-production model.

At the end of Phase 3, one application is fully migrated and running stably on the central platform for a minimum of 30 production days, with inspection results flowing to the unified data layer and the standalone fallback decommissioned.

At the end of Phase 4, all planned applications are migrated, the unified data layer contains complete inspection records for all zones, and the governance documentation required for IATF 16949 compliance is being generated automatically by the platform.

Integrated deployments document 4 to 6 times greater ROI than standalone deployments on equivalent hardware. That return is not realised until Phase 4 is complete. The phases are not optional. They are the path to the return.

The Team Structure That Makes This Work

A centralisation project of this scope requires a team structure that bridges the IT organisation, the plant operations team, and the quality function. These three groups have different priorities and different risk tolerances.

The IT organisation owns the infrastructure and the platform. Their primary concern is reliability and manageability.

The plant operations team owns production continuity. Their primary concern is that quality inspection does not fail during the transition.

The quality function owns inspection standards and compliance documentation. Their primary concern is that the new platform meets IATF and customer-specific requirements.

Without explicit coordination across these three groups, the project stalls at Phase 3 because operations will not accept the first migration without quality sign-off, and quality will not sign off without IT's confirmation that the platform is stable. Building the decision-making structure for these handoffs before Phase 3 begins prevents them from becoming blockages.

The forward deployed engineering model applies directly here. An engineering team working inside the client's actual manufacturing environment understands these organisational dynamics from direct observation. They can design the handoff process for each migration based on how the specific plant's operations, IT, and quality functions actually work, not based on how an organisational chart suggests they should work.

Vishleshan AI's forward deployed engineering (FDE) approach to centralized vision AI platform builds works inside the client's manufacturing environment from the start of Phase 1 through the completion of Phase 4. We design the infrastructure, manage the migration sequencing, and build the cross-functional coordination that keeps production running throughout the build. Book a Consultation