Why GLPI fits GLPI for manufacturing sites and what changes on the plant floor
GLPI can hold IT asset, rack and change records for a plant, provided OT systems stay outside its direct management. Most manufacturers run plant networks, PLCs, HMIs and historians that IT and OT teams each describe differently, so no one has a single accurate record of what is connected, where it sits and who approved the last change. GLPI addresses the record-keeping side of that problem. It is an open-source IT service management platform for tickets, assets, CMDB, contracts and data center infrastructure, distributed under the GNU General Public License version 3, and it can store the IT side of a plant with the same structure used for head-office equipment. It does not secure industrial control systems, and it should not be presented to plant engineers as an OT security control.
Once records live in GLPI, several things change. Network gear on the shop floor, such as managed switches and industrial firewalls, can be discovered and inventoried through SNMP using GLPI Agent and the GLPI Inventory plugin, which replaces spreadsheets maintained by hand. Server rooms and plant cabinets can be modeled as racks, enclosures and connections, so a technician can see what sits in a given cabinet before opening it. Changes to production-adjacent systems can be routed through tickets with approvals, giving the maintenance and quality teams an audit trail. Each of these depends on decisions made before the first scan: which VLANs and subnets are in discovery scope, which device classes are excluded, and which team owns each record. Confirm those boundaries with plant engineering and the OT security owner before any discovery job runs against controller networks.
Which manufacturing requirements shape a GLPI build
This table maps the standards and regulations that apply to plants and industrial sites to what each one means for GLPI asset records, change records and access. Read each row as a question to answer for your own sites, with the build decision that follows from it. GLPI supports the evidence and workflows; it does not certify compliance with any of these requirements.
| Requirement | What it asks for | What it means for GLPI |
|---|---|---|
| ANSI/ISA-62443-2-1-2024 (asset owner program) | Asset owners need a documented security program for their industrial automation and control systems, including roles, procedures and ongoing maintenance. | Define who owns each OT asset record and which entity or location it belongs to. Use GLPI's ticketing and change workflows as the program's operating record, and confirm with your auditor which evidence they accept. |
| ANSI/ISA-62443-3-2-2020 (security risk assessment) | Asset owners assess security risk when designing systems, grouping assets into zones and conduits. | Record zone and network segment as asset attributes or custom fields so risk assessments can be filtered and reproduced. Keep assessment outputs linked to the affected assets rather than in a separate spreadsheet. |
| ISA-62443-3-3-2013 (system requirements and zones) | System requirements and target security levels are set per zone, so zone membership must be known and traceable. | Model zones and security levels in GLPI through locations, groups or custom fields. Confirm that SNMP discovery places shop-floor devices into the correct zone before anyone relies on the data. |
| NIST SP 800-82 Rev. 3 (OT security scope) | Covers ICS, SCADA, DCS, PLCs, building automation and physical access control, with performance, reliability and safety treated as security concerns. | Scope GLPI records to include PLCs, HMIs and controllers, not only IT endpoints. Tag safety-relevant assets so change tickets reflect the reliability and safety constraints of the process. |
| NIS2 Annex II (manufacturing sector and incident timelines) | Manufacturing in NACE divisions 26 to 30 is a critical sector. In-scope entities report significant incidents with an early warning within 24 hours, a notification within 72 hours and a final report within one month. | Configure ticket categories and SLA or escalation rules for security incidents so the 24-hour, 72-hour and one-month steps can be tracked. Confirm with counsel whether your sites are in scope and which entity reports. |
| Regulation (EU) 2023/1230 Annex III, 1.1.9 (remote connection, from 14 January 2027) | Machinery must be protected so that connecting another device or a remote device does not lead to a hazardous situation. | Record every remote access path, vendor connection and connected device against the machine it touches. Use change records to approve each new connection and keep the approval attached to the asset. |
| Regulation (EU) 2024/2847 (CRA, Article 14 reporting) | Manufacturers must report actively exploited vulnerabilities and severe incidents for products with digital elements, with Article 14 obligations applying from 11 September 2026. | Keep firmware and software versions on each product record current so exposure can be identified quickly. Create a dedicated ticket path for vulnerability reports and link them to the affected asset and product model. |
| Change control for production systems (asset owner practice) | Changes to control systems need planned, approved and recorded modifications that do not disrupt production. | Use GLPI change records with approvals and linked assets. Keep production freeze windows and emergency change routes documented, and confirm how your plant handles changes that the process owner must authorize. |
Which GLPI modules and settings matter on a manufacturing site
Network discovery is where a manufacturing deployment is most likely to cause harm. GLPI Agent performs network discovery and inventory, and the GLPI Inventory plugin handles SNMP discovery of switches, access points, printers and other network gear. On a plant floor, a broad scan can overload legacy controllers or trigger faults in devices never designed to answer unexpected queries, so discovery should be scoped deliberately from the start.
- Named discovery ranges: Define the IP ranges and VLANs each scan may touch, and keep shop-floor segments out of general office scans.
- Conservative SNMP settings: Confirm community strings or SNMPv3 credentials, polling frequency and timeouts with the people who run the production network.
- Explicit exclusions: Exclude PLC, drive and safety network addresses unless engineering has approved a specific read-only query.
- Staged rollout: Start with one line or cell, review results and only then extend the ranges.
- Agent placement: GLPI Agent runs on Windows, macOS and Linux, so confirm which hosts on the OT side can run it and who signs off on installing it.
Before enabling any scan on a production segment, ask the plant engineering team and the equipment vendors to confirm which protocols and query rates their devices tolerate.
Manufacturing sites often run a server room or small data center for MES, historians, SCADA servers and file services, sometimes with racks that sit close to production. GLPI's data center infrastructure features let you record racks, enclosures, rooms and the devices installed in them, so that a technician can find where a server or network switch physically sits when something fails.
- Location hierarchy: Model the site, building, room and rack levels so that the plant layout matches how technicians walk the floor.
- Device placement: Record each server, switch and panel with its rack position, power connections and network ports where the team needs them.
- Ownership fields: Assign each rack and device to the IT team or the operations team that maintains it.
- Change history: Keep placement changes linked to tickets so that moves and replacements leave a trail.
- Scope limits: Decide whether PLC cabinets and control panels are recorded as racks or as separate assets, and document the choice.
Confirm with your plant team which cabinets are considered part of the IT inventory and which belong to controls engineering, since the answer determines who maintains the records.
Standard GLPI computer and network types do not describe most production equipment well. PLCs, operator HMIs, industrial PCs and motion controllers each carry firmware versions, vendor support status and an owning production line that matter for maintenance and incident response. Custom asset types let you capture those fields as first-class records instead of free text in comments.
- Dedicated types: Create separate asset types for PLCs, HMIs and industrial PCs so that reports and filters stay accurate.
- Engineering fields: Add fields for firmware or program version, vendor support end date, line or cell, and the controlling engineer.
- Relationships: Link each HMI or industrial PC to the PLCs it supervises and to the production line it serves.
- Import discipline: Load existing lists from engineering spreadsheets with a mapping reviewed by controls engineers before import.
- Data ownership: Record who may edit firmware fields, since engineers and IT staff may hold different responsibilities for the same device.
Ask the controls team which fields they already track in their own engineering records, so GLPI does not become a second copy that drifts out of date.
Changes to production systems are constrained by production schedules, quality requirements and safety reviews. A GLPI change record can hold the approval chain, the planned maintenance window and the rollback plan, which gives operations, quality and IT one place to agree on what happens and when. This does not replace the site's own management-of-change process, but it can record evidence that the process was followed.
- Approval steps: Configure approvers for production owners, controls engineering and quality, so that IT cannot close a change alone.
- Maintenance windows: Tie changes to calendars that reflect planned shutdowns, and block changes during active production runs.
- Rollback fields: Require a documented rollback or recovery step before a change can move to the implementation stage.
- Linked assets: Connect each change to the PLCs, HMIs or servers it touches, so the impact is visible.
- Records kept: Keep closed changes and their approvals for the retention period your quality system requires.
Ask your quality and operations leads which changes must be approved before they can be scheduled, since that list drives the approval design.
A multi-plant company usually needs one GLPI entity per plant or site, with profiles that decide what each group can see and change. OT engineers, plant IT staff and central IT often require different views, and mixing them in one profile tends to expose records that should be restricted. Authentication sources and authorization rules determine who lands in which entity and profile.
- Entity per plant: Use entities to separate plant inventories, tickets and contracts while keeping central reporting available.
- Profiles by role: Give OT engineers rights over asset types and change approvals for their own plant only, and keep central IT on broader read access.
- Directory mapping: Map directory groups to profiles and entities through authorization rules, and test each rule with a sample account.
- Admin separation: Keep configuration rights for discovery and agents with a small named group.
- Review cycle: Recheck access when engineers change roles or leave a plant.
Before granting access, confirm with each plant which engineers are permitted to view or edit production asset records.
GLPI holds the inventory and the change records, while monitoring tools watch whether devices are up and performing. Linking the two lets a monitoring alarm open a ticket against the right asset, and lets engineers see recent changes when an alarm fires. The integration should be designed so that monitoring probes do not add load to fragile OT devices.
- Asset matching: Use consistent identifiers such as serial numbers or hostnames so alarms map to the correct GLPI record.
- Ticket creation: Route alarms from plant monitoring into the plant's entity, with priorities agreed with operations.
- Probe limits: Confirm polling intervals with the monitoring owners and the device vendors before enabling checks on controllers.
- Change correlation: Show recent approved changes on an asset record so that engineers can connect a fault to a recent update.
- Ownership of alerts: Agree whether alerts go to plant operations, controls engineering or IT on-call.
Check with the monitoring team and the controls vendors which polling methods are permitted on production controllers before building any integration.
How a plant-by-plant GLPI rollout runs
The sequence moves from agreed scope and asset ownership to a proven pilot, then to the remaining sites and a handover, so each plant adds inventory without disrupting production. Durations depend on site count and scope, so confirm them in a written scope before work starts.
Agree scope and asset owners with OT and IT
Before any tool is configured, plant operations, OT engineering, IT and the GLPI owner agree which sites, asset classes and data fields are in scope, and who owns each asset record, including PLCs, HMIs, switches and industrial PCs. Production change authority and the freeze calendar are recorded here too. The step closes with a signed scope document that names an owner for every asset class and an escalation contact for each plant. Ask your provider to confirm durations in that written scope, since they depend on site count and scope.
Inventory existing sources and spreadsheets
The team collects every current record: spreadsheets, CMDB exports, procurement lists, vendor asset lists, and hand-kept rack diagrams. Each source is tagged with its owner, last update date and known gaps, then mapped to GLPI itemtypes and fields. Duplicates across sources are flagged for a decision rather than merged silently. The output is a source register and a field mapping sheet that OT and IT have both reviewed. Without this register, later imports tend to multiply records instead of correcting them.
Map the network passively before active discovery
Before any SNMP scan reaches shop-floor equipment, the team observes traffic passively from a mirror or tap, or uses switch and firewall data the plant already has, to learn which devices talk, on which VLANs and at what rate. Controllers and safety systems are identified and marked as do-not-probe unless the asset owner approves. The output is a reviewed device list, a set of approved target ranges, and a documented list of devices that will be inventoried by agent or manually instead. This step protects control systems from unexpected polling.
Run the pilot at one plant
With the approved target ranges and mapped fields, the team configures GLPI discovery and inventory for one plant only, including agent deployment on approved Windows, macOS and Linux hosts. Import rules are tested on a copy of the data, and results are compared with the register by an asset owner. Discrepancies are logged with a decision (correct, accept or exclude). The pilot is complete when the asset owner signs off on record accuracy and the team has confirmed that no production system was affected during discovery.
Test change workflows against the freeze calendar
The team builds the change process in GLPI for production systems, with approval steps, risk classification, linked assets and a calendar that blocks changes during the plant's production freeze windows. Test cases cover an emergency change, a standard change, a rejected change and a change that touches a shared network segment. Each test is run with the people who will approve in production. The output is a test record showing expected and actual behavior for each case and a list of corrections made before go-live.
Roll out to remaining sites in waves
The approved pilot pattern is repeated site by site, in the order agreed during scoping. Each wave uses the same source register, mapping, discovery ranges and change templates, with only site-specific values changed, such as entity, location and VLAN ranges. Each site has its own asset owner sign-off before the next wave starts. The output is a per-site record of inventory completeness, open discrepancies and any change to the approved discovery ranges, kept in the project log.
Hand over maintenance and document the operation
The final step transfers day-to-day ownership to the internal team or a retained support arrangement. Documentation covers the discovery schedule and approved ranges, agent deployment, update and backup procedures for GLPI, the change calendar and who maintains it, and the review cadence for asset owners. The handover is complete when named staff have run one discovery cycle and one change through the process without support, and the asset owners have accepted the runbook.
Compliance drivers for manufacturers and what GLPI records can support
Manufacturing sites face overlapping obligations on asset inventory, incident reporting, product security and machine safety. GLPI can hold the inventory, change and contract records that support several of these, but it does not make a site compliant on its own, and the policies, risk assessments and regulated-process controls must come from the business.
IEC 62443 asset inventory and program evidence
The ISA/IEC 62443 series sets security requirements for industrial automation and control systems, and ANSI/ISA-62443-2-1-2024 addresses security programs for asset owners. GLPI can hold a register of PLCs, HMIs, historians and industrial network gear with location, firmware, owner and support status. Check that every zone and conduit has a record and that changes to those assets go through a ticket. The risk assessment, zone design and security program remain the asset owner's responsibility.
NIS2 incident reporting clocks
For in-scope manufacturing entities, NIS2 Article 23(4) requires an early warning within 24 hours, an incident notification within 72 hours and a final report within one month. GLPI ticket timestamps, assigned owners and linked assets can show when an incident was logged and who acted on it. Confirm with counsel which entities fall in scope and whether your national transposition adds requirements. Fines of at least EUR 7 million or 1.4% of worldwide turnover apply to important entities under Article 34(5).
CRA obligations for product manufacturers
Regulation (EU) 2024/2847 applies to products with digital elements from 11 December 2027, and Article 14 reporting of actively exploited vulnerabilities has applied since 11 September 2026. Manufacturers that ship connected equipment can use GLPI to track product versions, vulnerability tickets and the customers or sites running each release. The reporting process, vulnerability handling and conformity work belong to the manufacturer. Confirm which of your products are in scope before relying on any record.
Machinery Regulation remote connection requirement
Regulation (EU) 2023/1230 applies from 14 January 2027 and requires machinery to be protected so that connecting another or remote device does not create a hazardous situation. GLPI can record which machines have remote access paths, the service contracts that allow remote connection and the change tickets that altered them. The risk assessment and the technical protection measures must be designed and documented by the machine manufacturer or integrator.
NIST SP 800-82 Rev. 3 OT guidance
NIST SP 800-82 Rev. 3, published in September 2023, covers operational technology including SCADA, DCS, PLCs and building automation, and it weighs performance, reliability and safety alongside security. GLPI can serve as the OT asset source for network discovery through SNMP and agent-based inventory, which supports the monitoring and architecture work the guide describes. Verify that discovery settings do not disrupt sensitive controllers, and have OT engineers approve scan schedules before they run.
21 CFR Part 11 for regulated plants
Pharmaceutical and medical device plants that create electronic records under 21 CFR Part 11 must control access, audit trails and electronic signatures for those records. GLPI can show equipment and calibration records, change approvals and who authorized a change. GLPI is not validated for Part 11 use by default, so the business must assess whether its ticket or asset data falls under the rule and define the validation, audit trail and signature controls itself.
How change management for production systems stays separate from IT tickets
A production change should be modeled as its own record type, linked to the assets it touches, not as a generic ticket. In GLPI, the practical pattern is to link each change to the affected assets (PLCs, HMIs, historians, network switches and the racks that hold them) so that a change against a line controller is visible from that controller's record. Each change should carry a risk classification agreed with the OT owner, the named approver from operations or engineering, and a planned window that respects the freeze periods the plant has set for shift handovers, quality batches and campaign runs. Confirm with your OT team which asset classes need the highest classification and whether any change must be blocked outright during a freeze. Keep the approval step separate from the IT service desk queue so that a helpdesk agent cannot close an OT change on their own authority.
GLPI workflows must not be the only control for safety-related changes. A ticket can record that a change was approved, but it cannot prove that a safeguard, interlock or safety function still works after the change. The Machinery Regulation, Regulation (EU) 2023/1230, applies from 14 January 2027 and adds an essential requirement (Annex III, 1.1.9) that machinery must not be put into a hazardous situation when another device or remote device is connected. IEC 62443 expects asset owners and product suppliers to run coordinated engineering processes for system design, risk assessment and maintenance. The safety validation, functional test and sign-off should therefore live in your engineering and safety management process, with the GLPI change record referencing those documents rather than replacing them.
Evidence retention is the part auditors will test, so define it before the first change is raised. Decide which fields, attachments and status transitions must be kept, who can alter a closed change, and how long records stay available. Where a change touches systems under a validated quality regime, such as those covered by 21 CFR Part 11, the audit trail and electronic signature requirements need a separate assessment. Ask your compliance lead to confirm the retention period and the controls over record edits, and test them with a sample change before you rely on the workflow in production.
What manufacturers ask before hiring help with GLPI
What drives the cost of a GLPI project for a manufacturing site?
The cost follows the written scope, and the main drivers are the number of sites, the asset volume, how much OT integration is needed and how many change workflows must be designed. Expect one-time work for requirements, installation, hardening, discovery tuning, import rules, change workflow design and handover, plus recurring costs for hosting, backups, upgrades and any support retainer. If you use GLPI Network, the subscription is a separate recurring cost. The published self-hosted subscription tiers run from 100 euros per month (Basic, up to 10 agents and 500 assets) to 4,500 euros per month (Enterprise), according to the GLPI Network subscriptions page. Ask any partner for a quote that separates one-time and recurring items and states which sites and asset classes are included.
How long does a GLPI rollout across plant sites take?
Duration depends on the number of plants, how many shop-floor assets must be discovered and classified, how far the change process has to be designed, and how quickly your OT and network owners can approve access. A single site with a clear asset list is much shorter than a multi-site rollout that needs SNMP profiles agreed per network segment. Staged rollouts, starting with IT assets and one pilot plant before the others, reduce risk and let you tune discovery before it reaches production networks. Ask for a timeline with milestones per site, and confirm which dependencies sit with your team, such as change windows and access approvals.
What does the work need from plant IT and OT staff?
The project needs named owners on both sides. IT provides hosting, identity, network segments and the database and web server layout. OT staff confirm which networks and devices are in scope, which production systems must not be touched, and which change windows are acceptable. Plant engineers should review asset classes, locations and naming, because they know which equipment is critical. Expect to provide:
- Network diagrams and VLAN or segment ownership for each plant
- A list of device types, vendors and existing spreadsheets or CMDB extracts
- Approved SNMP credentials and a list of devices that must be excluded
- Named approvers for change requests affecting production systems
Can an internal IT team deploy GLPI for a plant without outside help?
Yes, a capable internal team can deploy GLPI, and the platform is open source under the GNU General Public License version 3, so there is no license fee for the core product. The harder part is the manufacturing-specific work: safe discovery on production networks, OT change control, and records that match how plants operate. Check whether your team has experience with PHP and MariaDB or MySQL administration, web server configuration, LDAP or SSO integration and GLPI upgrades. Many organizations split the work, keeping day-to-day administration in house and buying a fixed-scope design, build and handover for the plant-specific parts.
Can GLPI scan PLCs and other shop-floor devices safely?
GLPI's network discovery can use SNMP to identify network gear, but scanning industrial controllers needs deliberate limits. Unplanned polling or broad scans can disrupt fragile devices, so discovery should start with read-only queries, narrow IP ranges, low rates and devices that your OT owner has approved. Some controllers do not respond well to SNMP at all, and those are often better recorded manually or from engineering documentation. Standards such as the ISA/IEC 62443 series and NIST SP 800-82 Rev. 3 treat availability and safety as primary concerns for OT, so test discovery in a lab or on a non-production segment first. Confirm each device class with the vendor before enabling any scan.
What should a partner's written scope for a plant GLPI project contain?
A written scope should name every site, network segment and asset class in or out of scope, and list the deliverables with acceptance criteria. It should describe the GLPI version and the database and web server layout, the discovery method and the devices excluded from scanning, and the change workflow design with approval roles. It should also cover data migration sources, backup and restore tests, handover documentation, training, and the upgrade path to GLPI 11 or 12 where relevant. Finally, it should say who owns each dependency, what is one-time and what recurs, and how changes to scope are priced. DeployOpen plans and delivers most engagements on a fixed scope agreed in writing before work starts.
Which GLPI version should a plant start on today?
Start from the version your upgrade plan supports, and confirm the requirements before building. The GLPI 12.0.0 release was published on October 7, 2026, according to the GLPI releases page, and the README lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later for the main branch. GLPI 11.0 documentation lists PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6. Plants with long validation cycles often need to know whether plugins they depend on have been certified for the chosen release. Ask your partner to test plugins and integrations against the target version before the production cutover.
What to confirm with your OT vendors and engineers before scanning
Before any active SNMP polling reaches shop-floor equipment, get written answers from each controller vendor on whether SNMP queries are supported, which community strings or SNMPv3 credentials they accept, and how much polling load the device tolerates. Many PLCs, HMIs, drives and safety controllers were designed for fixed, low-rate traffic, and a discovery sweep that looks harmless on an office network can slow a controller or trigger a fault. Ask the vendor to name the supported MIBs and polling intervals in writing, and record the answer against the asset record so that the GLPI Agent or GLPI Inventory plugin configuration later reflects the vendor's limits rather than the defaults. Where a vendor does not support SNMP at all, the device should be recorded from documentation and engineering drawings instead of being probed.
Agree maintenance windows with the production and controls engineering teams before the first scan. Confirm which lines can tolerate a brief network disturbance, who holds the authority to stop a scan, and how a scan is paused if a cell reports a communication problem. Confirm network segmentation with the people who own the OT zones: which VLANs or zones the GLPI server and any collector sit in, which firewall rules permit SNMP and which ports are open, and whether traffic from an IT-zone scanner into an OT zone is permitted at all under the site's own segmentation policy. Decide who owns the SNMP and device credentials, where they are stored, and who rotates them. Those answers determine whether discovery runs from inside the cell zone, from a dedicated collector or not at all.
Settle the change approval path for safety-relevant devices before any record is edited. Ask the safety and controls engineers to list which devices are part of a safety function, and agree that edits to their firmware, IP address, model or location fields in GLPI go through the same review as a physical change. Assign a named approver, usually from controls or safety engineering, and make the GLPI change record reference the engineering change that justifies the update. Confirm with the vendor and the site engineers which fields are authoritative for each device so that a discovered value never silently overwrites a value engineering has validated. Document these decisions in writing before the pilot, because they define which discovery results GLPI accepts automatically and which ones wait for a human decision.
Keeping the GLPI platform current on a plant schedule
This sequence moves a manufacturing GLPI instance from one release to the next without losing asset records, configuration or access. Each step ends with a check, so the site knows what it can roll back to and when production change windows can be used.
Agree the upgrade window with production
Operations, maintenance and the plant change board agree a window in which GLPI can be taken offline or restricted, and confirm that no production freeze, shift handover or audit visit falls inside it. The IT lead records the target version, which may be an 11.0.x release or the GLPI 12.0.0 release that became available on October 7, 2026, and confirms the owners who approve go or no-go. Done when the window, the target version and the rollback decision-maker appear in the change record.
Read the release notes and check requirements
The platform engineer reads the release notes for the target version and compares them with the current PHP, database and web server versions on the instance. GLPI 11.0.0 was released on October 1, 2025, and the installation documentation lists its prerequisites, including PHP 8.2 or later and MySQL 8.0 or MariaDB 10.6. Plugins are checked against the new version, and any that do not yet support it are listed as blockers. Done when a written compatibility list is signed off by the application owner.
Back up database, files and config keys
Before any file is replaced, the team takes a database dump, a copy of the GLPI files directory and a copy of the config directory, including the
glpi.keyandglpicrypt.keyfiles. The keys matter because encrypted fields in the database cannot be read without them. Backups are stored outside the GLPI host, and a restore is tested on a separate system. Done when the restore test has opened a recent ticket and an asset record.Stage the new version on a copy of production
The team builds a staging instance on separate hardware or a separate virtual machine, restores the production database and files into it, and applies the new application files there first. Staging also uses a copy of the web server layout, so the document root and URL rewriting behave as they do in production. Plugins, LDAP links and inventory agent endpoints are tested against the staging host. Done when the staging instance loads and the plugin list matches production.
Run the database update and reactivate plugins
On staging, the engineer runs
php bin/console db:updatefrom the GLPI installation root and reads the output for errors. Since GLPI 11.0, plugins are suspended when a new version is detected, so each one is reactivated by hand and checked against its own documentation, starting with inventory and any manufacturing-specific plugins. The same steps are then repeated on production during the approved window. Done when the console reports a clean update and every required plugin is active.Verify inventory, rack and change records
The operations team checks sample records that matter on the plant floor: a PLC or controller asset, a rack and its connected devices, an open change request and a recent inventory run from GLPI Agent. They compare these with values held before the upgrade. Any missing field or broken relation is logged as a defect before users are allowed back on the system. Done when the sample checklist is signed off by the asset owner and the change manager.
Close the change and set the next review
The change record is updated with the final version, the backup reference, the rollback point and the verification results. The team also decides when the next release will be reviewed, taking into account GLPI 12.0.0 and any follow-on 11.0.x fixes. Done when the change is closed in GLPI itself and the next review date is entered in the maintenance calendar.
How DeployOpen scopes and delivers GLPI for manufacturing sites
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For GLPI on manufacturing sites, we start from a written scope that separates plant networks, data center records and change control, then build and hand over a deployment your own team can run.
How we scope
- We confirm which plants, sites and network segments discovery may reach, and who approves each SNMP scan.
- We agree in writing which asset types, rack records and change workflows the GLPI instance will cover.
- We list the identity sources, database hosting and web server layout your IT and OT teams require before build starts.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work begins.
How we build
- We install GLPI on servers you control, with the web server document root set to the public directory as the installation docs require.
- We configure SNMP discovery and GLPI Agent deployment against an agreed list of shop-floor device classes and VLANs.
- We design change management and ticket workflows so production system changes carry approvals and evidence trails.
- We test discovery scope, import rules and role-based access with your plant and IT staff before go-live.
How we hand over
- We document the network ranges, credentials, discovery schedules and rack record conventions the team will maintain.
- We provide runbooks for the GLPI update procedure, including backups of the database, files and the config directory with its key files.
- We walk your administrators through plugin reactivation steps and the checks to run after each GLPI version change.
- We deliver the written configuration record so your auditors or internal reviewers can trace how assets were discovered.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We can plan GLPI 11 and 12 upgrade work as a separate scoped engagement, with plugin compatibility checked first.
- We can run periodic security testing of the GLPI deployment and its exposed services, scoped in writing.
- Ask any proposal to confirm which vendor-supplied GLPI features and plugin licenses are required for your site.
