inmation Software in 2026: Pros, Cons, and Where It Fits

Last Updated: 2026-05-18

If you searched inmation software pros and cons in 2026, you are almost certainly in one of three situations: you inherited an inmation deployment from a plant that adopted it in the 2017-to-2021 window, you are doing a vendor shortlist for a new industrial DataOps layer, or you are mid-way through a Honeywell System1 upgrade and trying to figure out what inmation became after the 2023 acquisition. This post is for all three. The short version: inmation was — and largely still is — one of the best object-modeled industrial data platforms ever shipped, but it lives a different life in 2026 than it did when most online reviews were written. Honeywell acquired inmation GmbH in 2023, folded the product into the System1 portfolio, and the product line continued as Honeywell System1 inmation through 2024 and 2025. The roadmap, pricing model, partner ecosystem, and integration story have all shifted in ways that materially affect whether you should buy it, keep it, or move off of it. This is a balanced, senior-practitioner pros-and-cons review with the 2026 alternatives mapped honestly.

Answer-first: In 2026, pick Honeywell System1 inmation when you already run a Honeywell DCS, when you need a single hierarchical object model across many plants, and when schema-on-read and Lua scripting are the features you cannot live without. Avoid it for greenfield Unified Namespace builds where MQTT and Sparkplug B are central, for OSIsoft-heavy estates where PI System is the path of least resistance, and for budget-constrained sites that need predictable per-tag licensing. The product is still strong; the constraints around it have tightened.

What inmation Software Is in 2026

Answer-first definition: inmation is a hierarchical, object-modeled industrial data platform that ingests, contextualizes, historizes, and serves time-series and event data from OPC UA, OPC Classic, MQTT, ODBC, files, and REST sources. Since the 2023 Honeywell acquisition it ships as Honeywell System1 inmation, retains the original “inmation” technology and feature set, and integrates more tightly with Honeywell Forge and the System1 control-system portfolio. It competes with AVEVA PI System, Cogent DataHub, HighByte Intelligence Hub, and Litmus Edge in different parts of the inmation industrial data platform market.

inmation GmbH was founded in 2013 in Aachen, Germany, by alumni of the OSIsoft PI ecosystem who wanted to fix what they saw as PI’s two weaknesses: a flat tag namespace and a closed, rigid data model. The original product, sometimes called inmation Influx (no relation to InfluxDB), shipped as a strict object hierarchy with first-class scripting, schema-on-read on top of a compressed historian, and an explicit goal of being the layer above many heterogeneous historians rather than another historian among them. The “system of systems” framing was always the marketing line, and for once the marketing matched the architecture.

Honeywell completed its acquisition of inmation in 2023 and aligned the product with Honeywell’s broader System1 condition-monitoring and data infrastructure portfolio. In 2024-2025 you saw the branding shift across release notes and the Honeywell Forge documentation: the product is now Honeywell System1 inmation, the support contract goes through Honeywell channels, and the partner program was rationalized inside Honeywell Connected Enterprise. The product itself — engine, object model, KPI engine, Web Studio, Web API — kept its technical identity. The roadmap, pricing, and field-engineering bench shifted.

In 2026, the product is mature and stable. It is not abandonware — Honeywell continues to release versions and patches — but it is no longer a startup-cadence product. Feature velocity has slowed to enterprise pace. The community channels that existed before 2023 (the inmation forum, independent consultancy network) have either dissolved or been re-platformed inside Honeywell-controlled spaces. That is not unusual for a post-acquisition product, but it is part of the honest 2026 picture.

Architecture and Capabilities

The architecture of inmation has been remarkably consistent across the major releases, and the 2026 product still follows the same skeleton. Figure 1 shows the reference architecture as it is typically deployed in 2026.

At the center is the object model. Everything in inmation is an object — a system, a server, a connector, an item, a calculation, a folder, a user, a permission. Objects sit in a strict hierarchy. A typical deployment looks like Enterprise > Region > Site > Area > Unit > Equipment > Item, with the same hierarchy applied uniformly across every plant. The hierarchy is not a tag-naming convention layered on top of a flat namespace (the PI System pattern); it is the data model. Permissions, scripts, calculations, and exports all attach to objects at whatever level of the hierarchy you choose. Once you internalize that, designing in inmation feels obvious; before that, it feels alien if you came from PI or a flat MQTT topic tree.

Around the object model, the connector layer ingests data. OPC UA is the workhorse — including DA-over-UA wrappers for legacy OPC Classic sources — and in 2026 the OPC UA stack is solid, including secure transport, structured types, and historical access where servers support it. MQTT and Sparkplug B connectors exist and are usable, but their idioms do not map cleanly onto inmation’s object model: Sparkplug B’s birth-death-data semantics are translatable but you typically end up writing connector-side scripts to land messages into the hierarchy the way you want. ODBC, OLE DB, REST, and file-based connectors round out the ingestion surface. The connector model is one of inmation’s quiet strengths — you can write a custom connector in Lua against the connector SDK and it behaves like any other ingestion source.

The historian store is a compressed time-series store, conceptually similar to PI Archive in goals but with different internals. Compression is configurable per item or per object hierarchy node. Retention policies can be heterogeneous — keep one-second data for 90 days on one branch of the hierarchy and one-minute aggregates for ten years on another. Querying is via the object path plus a time range, with optional aggregation, and the historian engine pushes computation down rather than materializing everything client-side.

The KPI engine sits on top of the historian and exposes calculated values — moving averages, time-weighted averages, statistical baselines, alarm thresholds — as first-class items in the object model. KPI definitions live as objects; they are versioned, permissioned, and scripted the same way ingested items are. A KPI item looks identical to a raw item to the API consumer. This is what people mean when they say “schema-on-read in inmation”: you can redefine the KPI without rewriting the data on disk, and the new definition takes effect retroactively across historical reads. This is materially different from materialized-aggregate models in classical historians.

Scripting in inmation is via Lua, with a documented script API surface that covers most of the object model. You can write event-driven scripts that fire on item value changes, scheduled scripts that run every minute or hour, library scripts that other scripts import, and connector scripts that transform incoming data before it lands in the store. In 2026, the Lua surface is still the primary scripting story. There is an HTTP-callable “lambda” pattern documented for server-side compute, but it is layered on Lua underneath. Python and JavaScript hooks exist via external integrations, not as first-class engine scripting.

The Web API is a REST surface that mirrors the OPC UA information model. You can read items, write items, browse the hierarchy, subscribe to value changes via WebSocket, and execute scripts. The OPC UA northbound is also fully supported, so you can present inmation as an OPC UA server to downstream systems while it consolidates many heterogeneous sources upstream.

Web Studio, the browser UI, handles configuration, ad-hoc trending, dashboard authoring, and routine administration. It is functional rather than beautiful — closer in feel to engineering software than to a modern data-visualization tool — and most production sites pair it with Grafana, Power BI, or a Honeywell Forge dashboard layer for end-user reporting.

Finally, integration with Honeywell Forge is the 2024-2025 architectural addition that you cannot ignore in 2026. Forge can read from System1 inmation directly, treating it as an industrial data source for asset performance management, condition monitoring, and reliability workflows. If you are a Honeywell DCS shop, this is the strongest single argument for inmation today — Forge plus System1 inmation is a coherent stack out of the box in a way that grafting any other industrial data platform onto Forge is not.

Pros: Where inmation Still Wins

The pros below are the reasons inmation deployments survived the acquisition transition and are still the right choice for specific shops in 2026.

The object model is the headline strength. Once your hierarchy is right, every downstream artifact — calculations, dashboards, KPIs, exports, permissions — inherits structure automatically. Add a new pump under Site A > Area 12 > Pump P-401 and the standard set of KPIs that you defined on the Pump template apply immediately, with no per-tag configuration. Scale that pattern to twenty plants and the labor savings dwarf the license cost. PI System users typically achieve the same result through Asset Framework (AF), but AF is a layer on top of a flat tag store; in inmation it is the native model. The distinction matters when you do bulk operations, mass renames, or hierarchy refactors — these are first-class in inmation and laborious in PI AF.

Lua scripting plus schema-on-read is the second headline. The combination lets you change how data is interpreted after the fact. Found a bias in a sensor in 2023 that you want to retroactively correct in your reporting? Write a Lua function on the KPI; queries from any time range now reflect the correction without rewriting raw history. Need to compute a new performance index that did not exist when the data was ingested? Define it as a script-backed item; it materializes on demand. This is closer to a modern dbt-style transform layer than to a classical historian feature, and in industrial data it remains rare. Cogent DataHub does not do this. PI System’s AF analytics can approach the result but require eventing, materialization, and re-runs. HighByte does pipeline-time transforms but not retroactive schema-on-read. inmation’s combination here remains a differentiator.

Hierarchy of systems — what the marketing has called “system of systems” since 2013 — is a real architectural feature. You can run multiple inmation cores federated under a parent core; the parent sees a unified hierarchy across the children, and applications written against the parent do not need to know which child holds which object. For multi-site enterprises with regulatory or latency reasons to keep data physically near the plant, federated inmation cores are a clean way to get one logical hierarchy across many physical stores. PI System achieves something similar via PI to PI interfaces but with more operational overhead.

OPC UA fidelity is high. The OPC UA stack supports structured types, historical access, secure transport, and method calls. For a 2026 site where ISA-95 modeling is a requirement and OPC UA is the lingua franca, inmation’s OPC UA fluency is better than what you typically get from MQTT-first platforms.

Stability and operational maturity. inmation has been in production at refineries, chemical plants, pharmaceutical manufacturing sites, and oil-and-gas upstream operations for over a decade. The engine is unfussy. Sites running it report 99.9-plus percent uptime over multi-year windows when sized and operated correctly. The runtime is not where outages come from.

Security model. Role-based access control attaches to objects, integrates with Active Directory or LDAP, supports audit trails out of the box, and aligns reasonably with IEC 62443 expectations for a Level 3-4 system. It is not flashy, but it is grown-up.

The Honeywell channel — if you are a Honeywell shop. The same property that hurts non-Honeywell sites helps Honeywell ones. If your DCS is Experion or your condition monitoring is System1, integrating inmation through the Honeywell Forge fabric is straightforward; you get a single support relationship and a single procurement vehicle.

Cons: What Hurts in 2026

The cons are real and have grown rather than shrunk since the acquisition.

Licensing reality. Honeywell System1 inmation licensing in 2026 is enterprise-flavored and notoriously hard to quote without engaging Honeywell sales. The pre-acquisition inmation model was already not cheap, with item counts, connector counts, and federated-core licensing all part of the cost stack. The post-acquisition model rolls the product into Honeywell’s enterprise commercial framework, which tends to favor large multi-year deals over single-plant pilots. Sites that want a 5,000-item proof-of-value pilot for a fixed predictable price find PI System, Cogent DataHub, and HighByte easier to procure. This is not unique to inmation — most industrial-grade data platforms have opaque enterprise pricing — but it is a real friction point in 2026 and worth being honest about.

Learning curve. The object model is powerful and unfamiliar. Engineers who came up on PI System spend several weeks unlearning flat-tag instincts. Lua is a small language but it is not Python or JavaScript; the talent pool of engineers who can write production Lua against the inmation script API is narrow. Training is available through Honeywell, but onboarding a new engineer to productive inmation development is realistically a one-to-three month process, not a one-week process.

Ecosystem narrowness. The PI System has thousands of integrators, hundreds of off-the-shelf connectors built by third parties, a deep community of trainers and consultants, and a published certification track. inmation never matched that ecosystem at peak, and the consolidation under Honeywell tightened the partner pool further. In 2026, if you ask “who can help me with my inmation deployment that is not Honeywell or its certified partners,” the answer is a much smaller list than the equivalent question for PI, AVEVA, or even HighByte.

MQTT and Sparkplug B are second-class citizens. inmation can talk MQTT — it has done so for years — but the architectural center of gravity is OPC UA and the strict object model. If your 2026 architecture is Unified Namespace with HiveMQ or EMQX as the broker and Sparkplug B as the wire protocol, you can wedge inmation into the picture, but it is wedged, not native. Tools designed for UNS from day one (HighByte Intelligence Hub, Litmus Edge, Cogent DataHub modern editions) fit a UNS architecture more cleanly.

Honeywell integration friction outside the Honeywell estate. The same Forge integration that helps Honeywell sites makes the product feel less neutral to non-Honeywell sites. If you run an Emerson DeltaV plant, a Yokogawa CENTUM plant, or a Rockwell PlantPAx plant, the System1 framing of inmation can feel like it is pulling you toward a Honeywell stack you did not buy. The product still works fine in those environments — the engine is the same engine — but the procurement story, the support story, and the roadmap story are harder to sell internally.

Slower feature velocity. Acquired products almost always slow down. Comparing the 2019-2022 release notes of inmation GmbH to the 2024-2025 Honeywell System1 inmation release notes, the cadence is markedly more enterprise-paced. Big features still ship, but the months-long iteration that defined the startup years is no longer the operating mode. Honeywell prioritizes integration into the larger System1 and Forge story over rapid standalone product innovation.

Documentation and community drift. The pre-acquisition inmation documentation was strong and the customer-facing forum was active. In 2026, the official documentation is still good but more dispersed across Honeywell channels, and the independent community discussion has thinned. New engineers find fewer “how did you solve this” blog posts than they would for PI or even Cogent DataHub.

Cloud-native posture is incomplete. inmation can be containerized and run in a cloud VM, and it can export to Snowflake, BigQuery, or S3 via its export and connector framework. What it is not is a SaaS, multi-tenant, cloud-native platform. If your 2026 strategy is “no on-premise industrial data plane, push everything to a managed cloud service,” inmation is not the right primitive. AVEVA CONNECT, AspenTech AIoT Hub, and Cognite Data Fusion are closer to that model.

Alternatives Compared (2026 Versions)

The alternatives map below reflects the 2026 versions of competing products as they actually exist. Figure 2 shows the decision tree we walk customers through.

AVEVA PI System and AVEVA Data Hub (formerly OSIsoft PI). The default historian for the global process industries. In 2026, AVEVA’s CONNECT data platform sits on top of PI as a cloud-native layer, exposing PI data and AF assets to broader enterprise analytics. PI’s strengths are ubiquity, ecosystem depth, mature Asset Framework, and a global pool of engineers who know it. Weaknesses are the flat tag model under AF, classical historian internals, and a procurement model that has its own enterprise friction. The inmation vs PI System decision in 2026 usually comes down to whether you value AF’s familiarity and the ecosystem (PI wins) or the native hierarchical object model and Lua scripting (inmation wins). Where the customer is undecided and Honeywell-neutral, PI is usually the safer bet because of the ecosystem.

AVEVA PI Data Infrastructure (CONNECT). The cloud-native posture AVEVA has built around PI. If you already run PI on premise and your strategic direction is “expose PI to the cloud without ripping out the historian,” CONNECT is the path. It is not a direct inmation competitor — it is a layer above PI — but it changes the inmation Influx vs AVEVA conversation because AVEVA now has a cloud face that inmation does not natively match.

Cogent DataHub. The pragmatic OPC bridging and tag-relay product. Cogent’s strength is simplicity: bridge OPC sources, expose them as one consolidated namespace, push to historians or MQTT brokers, and get out of the way. It is not a hierarchical object model; it is not a historian. For sites that need plumbing more than a platform, Cogent is the right call and inmation is overkill.

HighByte Intelligence Hub. The 2026 darling of Unified Namespace builds. HighByte is the modeling and pipeline layer that sits between brownfield sources and an MQTT broker plus a cloud historian. It models payloads, transforms data in flight, and outputs to UNS topics, Kafka, Snowflake, AWS, or wherever. It does not historize; you pair it with a historian or a cloud time-series store. If your 2026 architecture is UNS-centric and your historian is downstream, HighByte fits the slot inmation cannot fit cleanly.

Litmus Edge. Edge-heavy modeling and analytics. Strong for sites where you want to contextualize, run analytics, and make decisions at the edge before publishing to the enterprise. inmation lives in the data center; Litmus lives on the edge node. They overlap less than the market sometimes implies — most customers end up with both, not one instead of the other.

A summary view, treated as engineering judgement rather than vendor claims:

Product	Best at	Weakest at	Pricing flavor	UNS fit
Honeywell System1 inmation	Hierarchical object model, Lua schema-on-read, multi-plant federation	Cloud-native posture, predictable per-tag pricing, UNS-native deployments	Enterprise, Honeywell channel	Possible, not native
AVEVA PI System	Ubiquity, AF maturity, ecosystem and integrators	Flat tag store under AF, procurement complexity	Enterprise	Possible via PI to MQTT
AVEVA CONNECT	Cloud face for existing PI estates	Not a standalone historian	Subscription	Layered above PI
Cogent DataHub	OPC bridging and tag relay	Not a historian, no object model	Per-license, predictable	Reasonable as MQTT bridge
HighByte Intelligence Hub	UNS modeling and in-flight transforms	Not a historian, no time-series store	Per-instance, transparent	Native
Litmus Edge	Edge analytics and modeling	Not a central historian	Per-edge, per-asset	Native at edge

A pragmatic 2026 pattern in many large industrials is inmation or PI as the central historian, HighByte as the UNS modeling layer, and Litmus on the edge — not a single-vendor stack, but a coherent multi-vendor architecture where each product plays the role it is good at.

Migration Patterns

Migration to or from inmation is more common in 2026 than it was three years ago, and there are honest patterns worth describing.

Migration to inmation typically happens in two contexts. The first is consolidation: a multi-site enterprise has different historians at different plants — PI here, a homegrown SQL store there, a Wonderware Historian (now AVEVA Historian) at a third — and wants one logical hierarchy across all of them. inmation as the parent of federated cores, with the existing historians left in place upstream where they make sense, is a defensible pattern. The second context is a Honeywell-led plant upgrade where System1 inmation is the bundled choice. The procurement path is simpler and the integration with System1 condition monitoring is the value proposition.

Migration approach for an enterprise consolidation:

1. Inventory existing data sources and historians. Tag counts, retention requirements, who consumes the data, what calculations exist and where they live.
2. Design the target object hierarchy in inmation. This is the single largest design decision and the most common place migrations stall. Get it right with a small cross-plant working group before writing connectors.
3. Stand up a non-production inmation core. Connect one plant’s OPC UA estate as a proof of value. Replicate three to five key calculations as Lua scripts or KPI objects. Validate retroactive corrections work as advertised.
4. Migrate plant by plant. Run inmation in parallel with the existing historian for at least one full reporting cycle (typically one quarter). Cut over when the parallel period reconciles.
5. Decommission legacy historians or leave them as cold archives. Many sites keep the old store read-only for regulatory retention rather than reformatting all historical data.

Migration off inmation in 2026 happens for two reasons: a strategic move to a Unified Namespace architecture where MQTT and Sparkplug B are the spine, or a corporate consolidation onto a different historian (often PI) after a merger. Migration off is harder than migration to, primarily because the Lua-script-and-object-model abstractions do not translate cleanly to a flat-tag world. Practical advice:

1. Export the object hierarchy as a structured document. inmation’s Web API supports this.
2. Map the hierarchy onto the target platform’s modeling primitive — PI Asset Framework templates, HighByte data models, or a UNS topic structure — and accept that some flattening is unavoidable.
3. Translate the Lua KPIs into the target platform’s analytics primitive (AF Analytics, HighByte transformations, dbt-style models in a cloud warehouse). Plan months, not weeks, for this.
4. Bulk-export historical data via Web API or direct historian export. Compressed time-series exports to Parquet are usually the most portable target.
5. Run both stacks in parallel for one reporting period, the same way you would for an into-inmation migration.

The honest answer for most existing inmation customers in 2026: if the deployment is working and the Honeywell relationship is fine, do not migrate. Migration cost is real and the receiving platform will not have all of inmation’s strengths. If the deployment is misaligned with where the enterprise is going strategically (cloud-native, UNS-first, non-Honeywell), the migration cost is worth eating.

Trade-offs, Gotchas, and What Goes Wrong

Hierarchy design debt is the most common failure mode. A site rushes the initial hierarchy, gets six months in, and discovers that the wrong level of the hierarchy holds permissions or calculations. Refactoring is doable but not free. Budget two-to-four weeks of design work up front; it will save quarters later.

Lua scripting can become tribal knowledge. A senior engineer writes the calculations, leaves the company, and the scripts become unmaintainable. Treat Lua scripts like code: store them in a version-controlled repository outside inmation, code-review them, document them. The script API surface in inmation supports export and import; use it.

Performance tuning is platform-specific. The historian compression defaults are fine for many workloads and pathological for some. High-frequency sensors with fast-changing signals can blow out store size if compression is misconfigured. Audit per-object compression settings during the first month of production.

OPC UA connector restarts on configuration changes. Some configuration changes to OPC UA connectors require a restart, which means a brief data interruption. Schedule those changes in maintenance windows; do not assume zero-downtime config changes.

Honeywell support tickets follow Honeywell SLA cadences, not startup cadences. Set expectations with internal customers accordingly. P1 tickets get fast response; P2 and P3 follow enterprise channels.

Cloud bursting is not native. Plans that involve “the inmation core will live in the cloud during peak load” need careful design. The product runs in a cloud VM, but it is not an elastically scaling SaaS.

Practical Recommendations

If you are evaluating inmation in 2026 from a standing start, take this path:

1. Decide first whether you are a Honeywell shop or a Honeywell-neutral shop. If Honeywell, inmation is on the shortlist by default. If not, justify the shortlist on technical grounds (hierarchical object model, Lua, schema-on-read) and confirm the procurement appetite for enterprise commercial terms.
2. Run a paid pilot of at least one plant, three months minimum, before committing enterprise-wide. The object model is too important to validate on a vendor-led demo.
3. Pair the pilot with a Unified Namespace question: is your strategic architecture UNS-first? If yes, plan how inmation, HighByte, and an MQTT broker coexist rather than assuming inmation will be the whole answer.
4. Treat Lua scripts as code from day one. Version control, code review, documentation.
5. Budget for training. Three months of ramp time per engineer is realistic.

If you are running inmation today, treat it as a long-term asset, instrument it like any production platform, and plan around the slower 2026 feature cadence rather than expecting startup velocity.

FAQ

Is inmation still a product in 2026? Yes. Honeywell acquired inmation GmbH in 2023 and the product is sold and supported as Honeywell System1 inmation in 2026. The technical core — the object model, KPI engine, Lua scripting, Web API — is preserved, and Honeywell continues to release updates and patches. What changed is the commercial model, support channels, and partner ecosystem, which now sit inside Honeywell Connected Enterprise rather than the original inmation GmbH organization.

What are the main pros and cons of inmation software? The pros are a hierarchical object model that scales cleanly across many plants, Lua scripting with schema-on-read for retroactive corrections and KPIs, federated multi-core deployments under one logical hierarchy, mature OPC UA support, and tight integration with Honeywell System1 and Forge. The cons are enterprise-flavored Honeywell licensing, a learning curve around the object model, a narrower ecosystem than the PI System, second-class Sparkplug B fit for UNS architectures, and a slower post-acquisition feature cadence.

How does inmation compare to OSIsoft AVEVA PI System? PI System has a larger ecosystem, more available integrators, and a more familiar tag-plus-AF model for engineers coming from a traditional historian background. inmation has a native hierarchical object model rather than AF layered over a flat tag store, plus Lua scripting and schema-on-read as first-class features. In 2026, choose PI when ecosystem and ubiquity matter most; choose inmation when modeling power and federated multi-site deployment matter most, especially in Honeywell DCS shops.

Does inmation fit a Unified Namespace architecture? It can participate in a UNS but is not UNS-native. inmation supports MQTT and Sparkplug B connectors, but the architectural center of gravity is OPC UA and a strict object hierarchy rather than an MQTT topic tree. For greenfield UNS builds in 2026, HighByte Intelligence Hub or Litmus Edge are more natural modeling and pipeline layers, with inmation or PI as a downstream historian.

Is inmation the same as InfluxDB? No. inmation is an industrial data platform with a hierarchical object model and a built-in compressed time-series store; it was sometimes informally called inmation Influx in older materials, but it has no relationship to InfluxData’s InfluxDB. The two products solve different problems — InfluxDB is a general-purpose time-series database; inmation is a contextualized industrial data platform with built-in historization.

What does inmation cost in 2026? Honeywell does not publish list prices for System1 inmation. Pricing depends on item counts, connector counts, federated-core configurations, and the broader Honeywell commercial relationship. Expect enterprise-grade quotes with multi-year terms. Small pilots at five-figure annual cost are possible but require active engagement with Honeywell sales; predictable per-tag pricing is not the model.

Further Reading

• Industrial IoT pillar — architecture, platforms, and DataOps — the broader IIoT landscape this product sits inside.
• Unified Namespace architecture with HiveMQ and Sparkplug B in 2026 — the UNS architecture pattern referenced throughout the alternatives section.
• SCADA vs OPC vs IoT platform vs historian — comparison 2026 — context on where industrial data platforms like inmation sit relative to SCADA and OPC.
• Brownfield IoT and legacy machine connectivity playbook 2026 — practical patterns for connecting the legacy sources that feed an inmation deployment.

External references worth bookmarking:

• Honeywell System1 inmation product information on Honeywell Forge — Honeywell Connected Enterprise documentation portal.
• AVEVA PI System product page — aveva.com operations control and PI System sections.
• Cogent DataHub product page — cogentdatahub.com.
• HighByte Intelligence Hub product page — highbyte.com.
• Litmus Edge product page — litmus.io.
• ARC Advisory Group industrial data infrastructure market reports — arcweb.com for vendor-neutral context on the industrial data platform market.