How to Audit a Manufacturing IT Landscape: ERP, MES, Integrations, and Legacy Systems

A manufacturing IT audit usually seeks to answer two basic questions: what’s actually running on the floor and in the back office right now? And how does all of it talk to each other? To do that, most of the time you have to do technical forensics (opening config files and tracing batch jobs) and organizational archaeology (finding out why a spreadsheet from 2019 is still treated as absolute truth). 

Chudovo’s engineers already faced those challenges while conducting checks during a manufacturing IT infrastructure audit. In this walkthrough, we’ll discover how they navigated these systems, highlighting real-world examples and the common pitfalls uncovered along the way.

Where to Start

Manufacturing IT landscapes (at least most of them) span across: business platforms such as ERP and finance; production systems such as MES, SCADA, and historians; warehouse and logistics platforms; and custom applications built to fill gaps between them. To cover all those different domains, Chudovo’s team usually starts assessing the manufacturing IT landscape by drawing a current-state map. A rough first version usually looks like the diagram below:

To build this map, you can start with initial Interviews; however, engineers will have to verify it against application settings, server inventories, network rules, scheduled jobs, database connections, API gateways, monitoring tools, and source repositories. 

During a manufacturing software audit, it’s also useful to have a record with the most relevant information about it (such as its main purpose, owners, hosting location, version, support status, authentication method, production criticality, and dependencies). While doing this job, you might also find applications that remain operational even though nobody formally supports them, their source code is missing, or their vendor contract has expired. Network and database activity may also expose integrations that never appeared in the official documentation.

Inspecting Infrastructure and Plant Connectivity

The map only shows half of the picture. What’s next is to perform a conscious IT infrastructure assessment that records where each critical system runs. This must include its operating system, network zone, and connections to physical servers, virtual machines, cloud resources, or industrial PCs. Also, it’s important to trace the network paths between plant systems, offices, warehouses, and cloud services. An MES may have redundant application servers but still depend on one switch, DNS server, firewall, or VPN. 

Certificate and time-synchronization services can also stop authentication or event processing while every application appears to be running.

Another key part of any manufacturing IT infrastructure audit is to map IT/OT interfaces. This implies engineers have to review vendor VPNs, jump servers, support accounts, and firewall rules separately. On each check, it’s important to record who owns each connection, whether activity is logged, and how access can be revoked. Intrusive scanning or active PLC testing requires separate planning.

Dependencies Between Production and Business Systems

Dependencies do not always flow in one direction. For instance, a MES may receive work orders from an ERP and return production data for costing, while SCADA sends counts through MES or an undocumented side integration.  This workflow might not be evident or well-documented, so it can be missed in the audit report. For this reason, dependencies should always be traced in both directions. 

Another important thing is not to forget about the error path. A connection could go down at any time, and understanding whether production stops, continues temporarily, or creates data that must later be reconciled is key to determining how the system can recover from a big failure.

Reviewing the Integration Layer

In manufacturing environments, integration methods tend to accumulate. It happens one fix at a time, because a new integration is added while the old one is rarely removed. A mix of those methods could be easily found during a manufacturing system integration review: REST or SOAP APIs between newer systems, middleware platforms (MuleSoft, Boomi, or a homegrown message bus), direct database links (where one system reads or writes into another system’s tables), batch jobs (often overnight, moving CSV or fixed-width files between servers), and manual file exchanges (for instance, when someone exports a report and emails it, or drops it on a shared drive)

One useful starting point is the list of scheduled jobs, along with relevant metadata about each one of them (like the owner, trigger, input and output, credentials, downstream dependencies, retry behavior, last successful execution, and alerting setup).

Engineers must also inspect other background tasks such as Windows Task Scheduler, SQL Server Agent, Kubernetes CronJobs, and ERP schedulers. Middleware workflows also need to be considered, as well as any other external orchestration platform in scope. Once the definitions are collected, they need to be matched with scripts, execution logs, service accounts, and the systems they read from or write to.

Direct database links deserve special attention. If System A writes directly into System B’s database, upgrading System B stops being a deployment. It becomes a coordination problem.

Finding Unsupported Technology and Legacy Components

Manufacturing plants run equipment for decades. The software that controls that equipment often outlives its vendor support window by a wide margin. Given this difference in replacement cycles, legacy systems in manufacturing cannot be assessed by age alone. 

During an audit, you’re probably looking for:

• Operating systems past end of life (Windows Server 2008 or unsupported Windows Server 2012 installations).
• Database versions no longer patched.
• SCADA/HMI software tied to specific hardware (those that can’t be swapped without a full production line update)
• Custom applications with no remaining internal expert.

The replacement cycle for plant equipment is so much slower than office IT. It doesn’t make the environment necessarily good or bad. An audit should focus on identifying which systems can’t be touched without risk, and which ones are fine to leave alone for another cycle.

Data Flows, Duplication, and Inconsistency

Once the integration map exists, an audit needs to figure out where data actually lives and whether the same fact gets stored in more than one place. Customer records often live in both ERP and a CRM with no reconciliation process between them. When syncing only runs once a day, inventory counts differ between WMS and ERP. Product master data gets maintained separately in MES and ERP, and drifts out of sync over months.

Chudovo’s team uses a simple audit technique. It consists of picking five or six critical data entities (such as material master, work order, inventory location, customer, and supplier) and tracing where each one gets created, updated, and read across the landscape. 

For example, the following query compares inventory snapshots exported from ERP and WMS:

SELECT
    COALESCE(erp.material_id, wms.material_id) AS material_id,
    erp.quantity AS erp_quantity,
    wms.quantity AS wms_quantity,
    COALESCE(erp.quantity, 0) - COALESCE(wms.quantity, 0) AS difference
FROM erp_inventory_snapshot erp
FULL OUTER JOIN wms_inventory_snapshot wms
    ON erp.material_id = wms.material_id
  AND erp.location_id = wms.location_id
WHERE COALESCE(erp.quantity, 0) <> COALESCE(wms.quantity, 0);

Authentication, Permissions, and System-to-System Access

Access control is a good example of how manufacturing environments are often years behind office IT. Audits commonly find one service account being used for multiple integrations; because of this, nobody can tell which job made a given change. The use of a generic account to log in to the plant floor terminal (which sessions stay open indefinitely with no expiration time) is another example of what’s wrong.

Centralized identity providers connecting ERP, MES, and WMS logins are the exception, not the rule. API keys sometimes get hardcoded into scripts, sitting in plain text on a shared drive for anyone to find. 

What to do first? Map who, or what, can reach each system, and through which credentials. Weak access boundaries create security risks. They also make modernization harder: touching a system with unclear access boundaries makes testing slower, and rollback plans riskier.

Single Points of Failure

Critical processes that quietly depend on a single server, script, or person are easy to find in many manufacturing landscapes. A single on-premises database server running both MES and the historian, a VPN tunnel that all plant-to-cloud traffic funnels through, or one integration developer who built the middleware layer years ago (and never wrote a word of it down) are just a few examples. What matters here is what happens if some of these processes fail, or if the person is not reachable. If production “just stops working,” you need to put that finding at the top of the list.

Deployment, Monitoring, Backup, and Disaster Recovery

This part matters just as much as the integration diagrams, sometimes more. The purpose here is to check how code and configuration changes get deployed to production, and whether anyone wrote that process down. 

Also,you have to check whether monitoring exists for critical integrations, or whether failures only surface when someone notices missing data three days later. 

Backup frequency deserves its own analysis, and more importantly, whether anyone has actually tested a restore is something you definitely should ask. Whereas it is common to find solid backup policies for ERP, usually zero backup plans for MES or the historian database exist. 

Technical Debt that Blocks Modernization

Audit evidence usually shows those systems that a modernization project needs to touch first are those that carry most of the technical debt. Common examples are direct database integrations that block ERP replacement, since the new ERP won’t expose the same tables; hardcoded credentials block identity consolidation; and undocumented batch jobs block cloud migration because nobody can confirm what breaks if the job stops running on the old server.

These blockers need to be explicitly named. Don’t let them disappear into a general risk section where nobody reads them twice.

Ranking Findings

Priority should not only be determined by technical severity. Each finding should also be evaluated against its operational context and supported by evidence. 

A useful approach is to have a practical risk register that records each affected system with some metadata, such as technical cause, upstream and downstream dependencies, business owner, and available workaround. Once all the findings are in place, engineers can give a score that determines the order in which they will be tackled. To do so, they can rely on different factors like production impact, failure likelihood, detection and recovery, dependency breadth (i.e., systems, sites, production lines, and teams affected), supportability (vendor support, documentation, and available internal expertise), and modernization impact (whether the issue blocks an ERP, MES, or infrastructure change).

Modernization Roadmap

A useful roadmap can be divided into four phases: 

Stabilize

The first step is about fixing recovery gaps, expiring certificates, unsupported components with immediate exposure, fragile jobs, and unmonitored production-critical integrations.

Document and Isolate

Here you assign owners, restrict unnecessary access, document operational procedures, and contain systems that cannot yet be replaced.

Decouple

It implies replacing direct database access and point-to-point scripts with supported APIs, queues, or middleware boundaries where the change provides a clear migration benefit.

Modernize

This is the last step and involves migrating ERP, MES, infrastructure, and custom applications in dependency order, then retiring temporary bridges and duplicated data stores.

Several roadmap items may depend on the same technical change. An ERP audit might show that the replacement platform is ready, for example, while undocumented database consumers still make the cutover unsafe. Those consumers must be identified and redirected before the old ERP can be retired.

Manufacturing legacy modernization rarely fits into one large release. Plants have maintenance windows, production targets, vendor constraints, and equipment that may remain operational for years. A good roadmap should account for those limits and define a safe intermediate state after every phase, not only the intended end state.

Wrapping Up

Reading old scripts takes time. Asking about undocumented systems takes patience. Mapping dependencies that nobody wrote down takes both, usually more than anyone budgeted for. That’s most of what a manufacturing IT infrastructure audit actually involves. The final deliverables should include a verified system and dependency map, an application and infrastructure inventory, an integration catalog, a production-impact risk register, and a prioritized list of remediation and modernization work.

The payoff is a modernization plan grounded in what’s actually there, not in what the org chart assumes is there. ERP replacement, MES upgrades, and legacy system modernization all rest on this audit stage. It’s usually what decides whether the project succeeds or stalls six months in.