Building an AI-Assisted Anomaly Investigation System on a 15-Year-Old .NET Platform

AI doesn’t work if your system stays silent. How we taught a 15-year-old manufacturing system to speak with artificial intelligence (and didn’t break everything).

When the Head of Quality at a major manufacturing plant decided to leverage AI to analyze line anomalies, he ran into a harsh reality: their core application had been running for roughly 15 years on C# and .NET Framework, with production data stored in Microsoft SQL Server and accessed through a mix of Entity Framework and ADO.NET. The project started with refactoring the parts of the system the AI layer would need to access.

Plant Shutdowns and the Head of Quality’s Headache

The Head of Quality logs into his system to gather context for troubleshooting. But instead of quick answers, he gets a headache. To understand what happened, his engineers spend hours manually piecing together events, digging through archives for similar incidents, and trying to ignore the fact that the system itself “forgets” half the details.

The Head of Quality had heard about artificial intelligence. So he decided: “We need an AI agent that can gather this context in seconds and generate hypotheses for my team.”

However, when we met with the Head of Quality and his IT team, we had to stop them and deliver an inconvenient truth: “Before we launch AI, we have to teach your old system to talk. And right now, it’s completely silent.”

The existing production application remained on C# and .NET Framework, backed by Microsoft SQL Server. The modernization focused on opening a controlled integration surface around anomaly handling rather than rebuilding the application. We introduced an ASP.NET Web API layer and exposed the required operations through REST endpoints hosted in IIS. Direct SQL access would have bypassed validation and quality rules accumulated inside the application over years. We traced the existing workflow first, identified the C# logic responsible for each operation, and separated the functionality the AI layer needed from the legacy UI. We kept existing Entity Framework and ADO.NET access paths where they already represented trusted production behavior.

How We Opened the Legacy System Without Changing Its Rules

• Step 1: Reconstructing the Real System Behavior. We started from the anomaly workflows engineers already trusted and traced each one through the .NET application. A user action could begin in the UI, continue through a C# handler or service, reach Entity Framework or ADO.NET, and finally execute against Microsoft SQL Server. We followed that chain to identify where validation happened, which routines controlled status transitions, which queries assembled incident context, and which downstream behavior depended on the result.
• Step 2: Finding the Safe Boundary for the API. For each candidate operation, we checked what depended on it, what it depended on, which shared state it touched, and which rules had to remain inside the legacy application. We then established an ASP.NET Web API contract, defined the REST operations hosted in IIS, and ensured the legacy application still enforced all business rules.
• Step 3: Capturing Legacy Behavior Before Refactoring It. Before extracting or exposing application logic, we created characterization and regression tests with NUnit / xUnit around the anomaly scenarios the plant already relied on. The tests captured observable behavior such as returned fields, validation failures, permitted status transitions, related records, and responses to incomplete data. We then ran equivalent scenarios through two execution paths: the existing .NET workflow and the new REST API. We investigated any differences before the endpoint became available to the AI layer.
• Step 4: Making the API the Control Boundary. The ASP.NET Web API became the only integration path between the AI layer and the legacy application. A Python service orchestrated the investigation workflow and used Azure OpenAI to reason over the structured context returned through the REST API. Azure OpenAI never needed direct access to Microsoft SQL Server or the internal .NET object model. The Python layer could request an anomaly record, retrieve related process context, and pull relevant historical cases only through approved endpoints. Azure OpenAI generated evidence-based hypotheses.
• Step 5: Reconstructing Context at the Time of the Event. An anomaly could be several hours or days old by the time an engineer investigated it, while the production state had already changed. We therefore tied retrieved facts to their source and timestamp and used historical values where the legacy system retained them. We also kept recorded observations, engineer hypotheses, and confirmed conclusions separate, so the agent could not present an old assumption as a fact.

Technical Results

• 100% of AI access went through the governed REST API. Azure OpenAI and the Python orchestration layer had zero direct access to Microsoft SQL Server or the internal .NET object model. Every request for anomaly data, process context, and historical cases passed through approved ASP.NET Web API endpoints.
• Legacy behavior was validated across two execution paths. NUnit / xUnit regression tests ran equivalent anomaly scenarios through the existing .NET workflow and the new REST API, exposing behavioral differences before the endpoints were released to the AI layer.
• 15 years of accumulated business logic stayed inside the production application. Existing validation rules, status transitions, Entity Framework paths, and ADO.NET behavior remained authoritative while the new API exposed only the operations required by the AI workflow.
• One reusable integration boundary replaced direct internal coupling. The ASP.NET Web API became the controlled interface for AI and future analytics capabilities, reducing the need to reopen legacy internals for every new integration.
• Historical context became time-aware and evidence-backed. Retrieved facts were tied to their source and timestamp, while observations, hypotheses, and confirmed conclusions remained separate so the AI workflow could distinguish evidence from prior assumptions.

Business Results

• ~80–95% faster automated context collection. The automated API pipeline gathers anomaly records, process data, and related cases in seconds to minutes, compared to the hours previously spent manually searching across system archives.
• Context gathering reduced from hours to minutes. Engineers can launch an investigation with pre-assembled historical evidence and process state, avoiding manual data assembly.
• ~50–70% reduction in overall manual investigation prep time. While context collection itself is automated almost instantly, overall engineer preparation time for an investigation (including initial review, hypothesis verification, and scope definition) is cut by more than half.
• Zero legacy-platform replacement required. The client introduced an AI-assisted investigation workflow while keeping the existing C#/.NET Framework application, Microsoft SQL Server database, and accumulated production rules.
• One API investment opened the legacy application to multiple future use cases. Future AI and analytics capabilities could reuse the same governed REST contracts instead of rediscovering internal dependencies and building new direct integrations.
• Lower change risk around a 15-year-old production core. Characterization and regression testing established a behavioral baseline before refactoring, while dual-path validation detected differences between the old workflow and the new API before AI integration.