After many conversations with PI users globally, one pattern keeps coming up: the issue is not whether historian data exists, but how easily teams can use it somewhere else.
Over the past year, my team and I have had many conversations with PI System users around the world.
Utilities. Renewable energy operators. Manufacturers. Energy companies. Industrial software teams. Some were formal evaluations. Some were technical discovery calls. Some were with partners who have worked around PI environments for years.
I have not counted every call, and this is not a formal survey. But between customer, prospect, and partner conversations, we are getting close to a hundred PI-related discussions globally. At that point, certain patterns become hard to ignore.
One of the clearest patterns is this:
Most teams are not saying PI failed.
Actually, it is usually the opposite.
PI has been the standard for a reason. It has been running inside industrial environments for years, sometimes decades. Engineers trust it. Operators know it. Many companies have built tags, asset structures, calculations, dashboards, reports, and daily workflows around it.
That is exactly why the conversation is so interesting.
The issue is not that PI does not work.
The issue is that the world around PI has changed.
Historian data is no longer used only for trends, reports, and troubleshooting inside the plant. Today, the same data is expected to support cloud analytics, AI/ML workflows, fleet-level monitoring, digital twins, modern dashboards, regulatory reporting, business intelligence, and external data sharing.
That creates a very practical question:
How hard is it to get the data where it needs to go?
For many PI users, that is where the pain starts.
Export is not the same as mobility
Let’s be fair.
The issue is not that PI data cannot be exported. It can.
AVEVA has PI data access technologies. PI Web API is described as a RESTful interface that gives client applications read and write access to AF and PI data over HTTPS. PI SQL Client provides SQL-based access through JDBC and ODBC drivers. AVEVA also offers PI Integrator for Business Analytics to prepare PI System data for reporting, advanced analytics, BI tools, and cloud platforms.
So I would not describe the problem as “PI data cannot get out.”
That is too simplistic.
The better way to say it is this:
For many PI users, lock-in is not about whether data can technically leave PI. It is about how much licensing, integration work, specialized tooling, and architecture effort are required before that data becomes easily usable somewhere else.
That distinction matters.
Export means there is a path.
Mobility means the data can be accessed, shared, queried, streamed, replayed, and reused without every new use case becoming a separate project.
That is what more industrial companies are asking for now.
Lock-in is not always a closed door
When people hear “vendor lock-in,” they often imagine a hard wall: no API, no export, no way out.
In historian environments, it is usually more subtle than that.
The door may exist. But it may be heavy.
Every new analytics project may require another connector.
Every cloud initiative may require another architecture discussion.
Every dashboard modernization effort may require another mapping exercise.
Every AI workflow may require another extraction process.
Every external integration may require another commercial or technical review.
That is still lock-in.
Not because the data is impossible to move.
But because moving it is slow, specialized, expensive, or dependent on tools and people that only exist around one ecosystem.
Public AVEVA community discussions have described PI System Access licensing as covering runtime use of several PI Data Access methods, including AF SDK, PI OLEDB, PI ODBC, PI JDBC, PI Web Services, and PI OPC DA/HDA. AVEVA documentation for PI Integrator also describes licensing in terms of output streams and specific software package agreements.
That does not mean there is a simple “fee to move data out.”
The issue is more practical:
Can teams use the data somewhere else without turning data access into a project of its own?
That is the friction customers keep describing.
The pain shows up when teams try to do something new
Historian lock-in does not always feel painful when everyone is doing the same things they have always done.
It shows up when the business asks for something new.
A renewable energy operator wants to combine plant historian data with weather, market, and performance data.
A utility wants to make operational data available to central analytics teams.
A manufacturer wants to connect production data with quality, maintenance, and enterprise systems.
A data science team wants historian data in a cloud platform.
An AI project needs historical data, live values, asset context, alarms, and events in one workflow.
None of these requests are unusual anymore. They are becoming normal.
But in many environments, the answer still becomes:
We need another connector.
We need another license discussion.
We need another middleware layer.
We need another custom integration.
We need another team that understands how the old environment was built.
That does not mean the project is impossible.
It means the data is not as mobile as the business now expects it to be.
And that gap is becoming more visible.
A modern historian should not become another data trap
This is where I think the historian category is changing.
A historian still needs to do the basics extremely well: collect data reliably, store it efficiently, query it quickly, and support the operational workflows engineers depend on.
But that is no longer enough.
A modern historian also needs to make data easier for other systems to consume.
Sometimes that means SQL access.
Sometimes it means APIs.
Sometimes it means connectors.
Sometimes it means downstream systems should be able to subscribe to the data they need, similar to how teams already think about MQTT or Kafka-style data flows.
Not because the historian needs to replace MQTT or Kafka in every architecture. That would be the wrong argument.
The point is simpler:
Operational data platforms should be designed to share data cleanly from the start.
At TDengine, this is one reason we think about subscription-style access as part of historian architecture. Applications should be able to consume selected operational data as it arrives, and in some cases replay the data they need. TDengine documentation describes Kafka-compatible subscription concepts, MQTT subscription support, and data publishing patterns for Kafka.
But the product detail is not the main point.
The architectural principle is the point:
Historian data should not become a dead end.
This is really about data ownership
The more PI users we speak with, the more I think the historian conversation is becoming a data ownership conversation.
Who controls the data?
How easily can teams use it?
Can operations, engineering, IT, analytics, and AI teams all work from the same reliable foundation?
And one day, if the company decides its existing historian is no longer the right platform for the next stage, can it actually move on?
That is the real test.
Not whether data can technically be exported in some form. Most systems can do that.
The question is whether a company can move its historical data, real-time data flows, metadata, context, and downstream integrations without turning the decision into a massive, expensive, high-risk program.
If leaving a platform is so difficult that the business effectively has no practical choice, then the data is not as free as it should be.
This does not mean every company needs to replace its historian.
Many will continue running existing systems for years.
But companies should have the option.
They should be able to use their data in new applications, new analytics platforms, new AI workflows, and, if needed, new historian architectures.
The data itself should not be the thing that holds them back.
Moving data should not be the hardest part
Industrial data is becoming more valuable, not less.
AI will only make this more obvious. AI is not useful just because a company has years of historian data. It becomes useful when that data is accessible, contextualized, timely, and connected to the workflows where people actually make decisions.
That is why data mobility matters.
It is not only about today’s dashboard or tomorrow’s cloud project.
It is about making sure operational data remains usable across whatever tools, teams, and architectures come next.
PI became the standard because it solved a real industrial problem.
But the next problem is different.
Industrial companies now need historian data to move more freely: from plant systems to cloud platforms, from engineering workflows to AI applications, from local sites to global fleets, and from one generation of tools to the next.
PI works.
For many teams, moving the data is the hard part.
Related reading: TDengine vs. PI System: A Modern Historian Alternative
Watch a demo: Take your data from PI System into TDengine Historian
