Replacing a historian that has been running for 20 years feels like open-heart surgery. The PI Data Archive touches everything: control systems feeding it live data through dozens of interfaces, the AF model that every engineer has spent years building out, PI DataLink reports that half the organization relies on, and PI Vision screens that took months to configure. Shut any of it down incorrectly and you lose operational continuity.

So most PI customers do nothing. They pay the Flex Credits renewal, watch the bill go up, and defer the problem to the next budget cycle.

The headline is that the migration doesn’t have to work that way. The choice depends on your objectives (get more value out of PI, reduce costs, improve scale, leverage more data sources, etc.). Replacing a PI historian is not a cutover event. It’s a series of discrete, reversible, low-risk phases, each one delivering value independently, none of them requiring you to turn off PI before the next one is ready. You control the pace. You define the scope of each phase before you start it. And if anything doesn’t behave as expected, you roll back that step without touching the rest of the system.

We assume you found this post because you are actively trying to replace PI due to cost, performance, slow development, or other issues. Just know that there are great ways to make this painless and always under your control.

This is the migration strategy Transpara customers use. It’s built around how PI actually works and what the realistic risks are at each step.

One last note before we dive in: You don’t have to replace PI at all to take advantage of everything Transpara does. We work in tandem with it and we are fans of PI. We just know that there are a lot of people looking for something more modern, scalable and with better commercial terms.

First: What You’re Actually Replacing

Before any migration planning, it helps to be precise about what “replacing PI” means. The AVEVA PI System is a family of products, not a single one, and different parts of that family have different replacement paths, different timelines, and different risk profiles.

• PI Data Archive. The historian itself. This is where your time-series data lives. It’s what per-tag pricing is associated with. Replacing it with Transpara tStore (or any other historian) is the longest phase of the migration and usually the last step in the process.
• PI Asset Framework (AF). The asset model, templates, Event Frames, and AF Analytics. This is where your engineering team’s intellectual property lives. Replacing it with tModel (Transpara’s graph-based asset model) is typically mid-migration.
• PI Vision. The visualization layer. This is usually the first thing to replace and the one that delivers the fastest, most visible ROI. Transpara’s tView replaces it without touching the historian at all.
• PI DataLink. The Excel add-in. Transpara has a native Excel add-in that pulls from tStore, PI, and every other connected source. This coexists with DataLink during migration.
• PI Interfaces. The connectors to your control systems and DCS. These are the last components to migrate and require the most care. You take this last step once you are fully confident in the new platform and have tested everything extensively.

Most organizations don’t need to replace everything. Some replace PI Vision and leave PI Data Archive in place indefinitely. Some reduce their tag count to lower Flex Credits costs and keep the rest running. Some migrate completely over two to three years. The guide that follows covers the full path, but you can stop at any phase and you are always in control.

Before You Start: The Inventory You Need

A migration that skips the inventory phase runs into surprises that stall it. An afternoon of documentation work now prevents weeks of unplanned remediation later.

Tag inventory. Pull a full list of active tags from PI Data Archive. Note which ones are actually being read by applications versus which are archived but unused. Many PI deployments have accumulated tags over years that nothing actively queries. These don’t need to be migrated and shouldn’t consume your team’s time.

AF model(s). Understand the maturity of your AF structure: the number of element templates, the number of elements, which Event Frame definitions are in active use, and which analytics/calculations are still valid, up-to-date, and driving operational decisions. A mature AF implementation may have hundreds of templates and hundreds of thousands of elements. If you have a model you are happy with, this is easily brought into Transpara using the Remote Context Service feature of both Visual KPI and Transpara (even if you are keeping AF).

Interface inventory. List every PI Interface: what it connects to, which tags it feeds, how frequently it writes, and who owns the source system. This is your dependency map. Interfaces to legacy DCS platforms that no standard connector supports are the migration steps that require the most careful planning.

Downstream dependency inventory. Identify every application, report, dashboard, or integration that reads from PI. PI DataLink reports, custom PI SDK applications, PI Vision displays, third-party analytics tools with PI connectors, and anything reading via PI Web API. These represent the cutover commitments you’ll need to honor before retiring each PI component.

Compliance and data retention requirements. Some industries have specific requirements for how long operational data must be retained and in what format. If PI is your system of record for compliance purposes, understand those requirements before modifying it.

Visualization requirements. Understand what existing displays need to be kept as is, or those that can be improved via better visualization, KPIs, etc. Even if you plan to keep some PI Vision graphics, you can embed those in Transpara screens to keep the best of both worlds.

The Migration at a Glance: Where Everything Lives

Before the phase-by-phase detail, here is the whole journey on a single screen. At every stage, one question tells you exactly where you stand: where does each part of your operation actually live? Track four things, your data interfaces, your time-series data, your asset model, and your calculations, and the migration stops looking like one risky cutover and starts looking like four deliberate moves you make on your own schedule.

Every move is independent and reversible. You can sit at any sequence for as long as it serves you, and many customers do. Data moves into tStore only when there is a good reason to move it, and your model and calculations follow only when you are ready.

For the engineers who want the component-level view, each sequence switches on a specific set of platform parts. Sequence 1 reads in place through the PI Interface, the AF Interface, and the AF Remote Context Service (RCS). Sequence 2 adds the PI Extractor and tStore while still reading the model through the AF Interface, AF Data Reference, and RCS, and it brings tModel and tCalc online against that live AF model. Sequence 3 adds the AF Extractor so tModel and tCalc hold the model and calculations outright, with the PI Extractor still feeding data and tView driving the dashboards. Sequence 4 replaces the PI-specific connectors with Transpara’s own Interfaces and Extractors, leaving tStore, tModel, tCalc, and tView running with no PI components in the path at all.

Sequence	Data interfaces	Data	Model + model data	Model equations	What moves, and where it maps in this guide
1	PI	PI	AF	AF	Starting point. Everything stays native to PI and AF, read in place. Maps to Phase 1, where you deploy Transpara alongside PI and change nothing in it. This is how it works with Visual KPI as well.
2	PI	tStore	AF	AF	Your tag data now lives in tStore, pulled across by the PI Extractor. Your model and calculations stay in AF. Maps to Phase 2.
3	PI	tStore	tModel	tCalc	Your asset model moves into tModel and your calculations into tCalc. Data still originates from PI. Maps to Phases 3 and 4.
4	tSystem	tStore	tModel	tCalc	Transpara’s own interfaces and extractors (tSystem) connect directly to your control systems. PI leaves the data path entirely, and you can retire it. Maps to Phase 6.

Phase 5 does not get its own row because it does not change where anything lives. It redirects the applications that read your data, the DataLink reports, the custom scripts, the dashboards, from PI to Transpara. Your data, model, and calculations stay exactly where Sequence 3 put them.

The Phase-by-Phase Migration Strategy

Each phase below is independent. You can complete Phase 1 and stop for six months before starting Phase 2. Every step is designed to be testable and rollback-safe before you proceed.

Phase 1: Deploy Transpara Alongside PI

What happens: You install Transpara in the same network environment as your existing PI Server. Nothing changes about PI. No tags move. No interfaces change. Transpara connects to PI Data Archive and PI AF using AVEVA’s published AF SDK, the same read interface that PI Vision and PI DataLink use.

What this gives you: Transpara’s tView starts generating real-time KPI dashboards from your PI data. Operators, managers, and executives who currently have no access to PI Vision get mobile-friendly, color-coded operational views immediately. The visualization ROI from Phase 1 alone typically justifies the Transpara investment in the first quarter.

Technical notes:

• Transpara authenticates to PI using your existing PI trust or PI identity credentials. Your PI security model carries through unchanged.
• The Remote Context Services (RCS) component reads your AF hierarchy and maps it into tModel. Your existing AF element structure, templates, and attributes are preserved. You don’t rebuild the model from scratch. This stays in sync with AF, so any changes you make on the AF side are reflected in Transpara automatically.
• KPIs you define in tStudio (or in AF using the RCS) reference PI tags through the AF SDK in real time. Data is read from PI on demand, not stored in Transpara (yet).
• Your PI admin sees Transpara as a read-only client to PI. Nothing in PI changes.
• This isn’t just about PI. You can also add as many other data sources as you want, giving you a single, real-time operating view of all data, without the need to centralize or migrate any of it.

Risk level: Very low. Transpara is additive. Removing it at this stage requires only uninstalling the software.

When to move to Phase 2: When you’re confident in the connection stability, the model looks right, and your team is using tView in production.

Phase 2: Mirror PI Data Into tStore

What happens: You activate Transpara’s extractors to begin pulling PI tag values into tStore, Transpara’s time-series historian. The extractors run continuously, keeping tStore synchronized with PI Data Archive in real time. They also backfill historical data from PI into tStore, so tStore builds up a complete historical record matching what PI holds.

During this phase, both PI and tStore hold the same data. Your existing PI applications continue reading from PI exactly as before. Transpara applications can now read from either PI or tStore, and you can compare the two to verify data fidelity, scale, performance and more before making any cutover commitments.

What this gives you: A verified, production-tested mirror of your PI historian. At the end of Phase 2, tStore holds your full tag history, stays synchronized with PI in real time, and has been validated against PI’s own data. You can make the next migration decisions from a position of verified confidence rather than assumption.

Technical notes:

• Extractors are distinct from interfaces. Interfaces read data from a source in place, without storing or migrating it. Extractors pull data from a source and write it into tStore, either as a primary data source or for other reasons (e.g. analytics or performance cache).
• The PI extractor uses the AF SDK to read tag values and writes them into tStore with identical timestamps and data quality flags. Compression algorithms handle storage efficiency.
• Backfill duration depends on your tag count, data density, and available network bandwidth. For large PI deployments or many years of history, backfill may run for days. During this time, both systems are fully operational.
• You choose which tags to mirror and which to leave PI-only. Tags you’re considering decommissioning don’t need to be extracted.

Risk level: Low. PI continues running unchanged. tStore data can be validated against PI before any cutover.

When to move to Phase 3: When backfill is complete, data fidelity has been verified, and you’re ready to start migrating the model layer.

Phase 3: Migrate the AF Model to tModel

What happens: You transition from using RCS to read the AF model passively to fully migrating the AF structure into tModel. The graph-based tModel becomes the authoritative asset model for Transpara. Your existing PI AF stays in place and continues to be the data source for anything still reading from PI directly.

What this gives you: tModel now holds your full asset hierarchy, element templates, attributes, and relationships. Because tModel is a graph database rather than a relational model, it can represent relationships between assets across PI and non-PI sources in a way that AF cannot. This is where you start adding non-PI data sources to the same model: ERP data, LIMS results, IoT sensor feeds, and anything else that belongs in your operational picture alongside PI tags.

Technical notes:

• The Transpara RCS automates the initial import. It reads your AF element structure, templates, and attributes and maps them into tModel’s graph structure. Relationships are preserved as graph edges rather than relational foreign keys.
• When ready, tModel becomes Transpara’s authoritative model. AF remains unchanged and continues serving any applications still pointed at it.
• You do not need to migrate every AF template at once. Start with the element types and process areas you actively use in tView. Migrate the rest as your team verifies each section.
• AF Event Frames become first-class events in tModel. They can drive tCalc calculations, tView alerts, and dashboards exactly as they do in PI today.

Risk level: Low to medium. The AF model is being read and copied, not modified. AF continues to function for any application still using it.

When to move to Phase 4: When your tModel accurately reflects the AF structure and you’ve verified that tView dashboards built from tModel are correct.

Phase 4: Migrate AF Calculations to tCalc

What happens: You migrate your AF Analytics calculations, Performance Equations, and any custom logic that currently runs inside AF into Transpara’s tCalc engine. Each calculation is migrated, tested against the PI/AF result, and validated before the AF equivalent is retired.

tCalc is event-driven rather than schedule-based. Calculations trigger on data events, which makes them more responsive than AF’s polling-based execution for high-frequency process data. Python extensibility means any logic that was difficult to express in AF’s syntax can be rewritten cleanly.

What this gives you: Your calculated KPIs and other calculations now run in tCalc, pulling from tStore data rather than PI Data Archive. You’re no longer dependent on AF Analytics for your core calculations. Any new calculations you build going forward can leverage Python, integrate with AI models, and reference data from any source in your environment.

Technical notes:

• Migrate calculations in groups by process area or template type, not all at once. Test each group against the AF result before deactivating the AF equivalent.
• Some AF calculations reference PI-only data during transition. These continue to work via the PI interface until the underlying tags move to tStore in a later phase.
• AF Performance Equations can generally be rewritten directly in tCalc’s no-code interface for simple expressions, or in Python for complex logic.
• The RCS can assist with automated mapping of AF calculation templates to tCalc equivalents for common patterns.
• Do not retire an AF calculation until the tCalc equivalent has been running in parallel and verified for a defined period, typically two to four weeks depending on your confidence threshold.

Risk level: Medium. This is where most of the intellectual property of your PI deployment lives. Work methodically through calculation groups with explicit validation criteria before retiring each one.

When to move to Phase 5: When tCalc covers all active calculations and tStore holds verified data for all tags feeding those calculations.

Phase 5: Redirect Downstream Applications

What happens: You update applications that currently read from PI to read from tStore or from Transpara’s query layer instead. This includes PI DataLink reports, any custom applications using the PI SDK or PI Web API, third-party tools with PI connectors, and any remaining PI Vision displays.

This is the phase that requires coordination with the most stakeholders. Every team that has a PI DataLink report, a custom script using the PI SDK, or a PI Vision display needs to know what’s changing, when, and what the equivalent is in Transpara.

What this gives you: Transpara becomes the primary data layer for operational data. PI Data Archive is still running, but nothing reads from it. At this point, you’re paying for PI but not using it. That’s the economic trigger for the next phase.

Technical notes:

• The Transpara Excel add-in is a direct replacement for PI DataLink. It reads from tStore, tModel, and any other connected source using the same formula-based interface engineers are already familiar with.
• Custom applications using the PI SDK or PI Web API can be migrated to Transpara’s query layer. The specifics depend on what those applications do. Some can be redirected to tStore’s REST interface. Others may require rewriting.
• Third-party analytics tools with PI connectors can typically be redirected to tStore via its published APIs.

Risk level: Low risk but medium-high effort for individual applications, manageable in aggregate when phased by application group. Keep PI running in parallel until every downstream dependency has been verified on Transpara.

When to move to Phase 6: When all downstream applications have been verified on Transpara and no production reads are still going to PI.

Phase 6: Retire the PI Interfaces and Decommission PI Server

What happens: You replace PI Interfaces, the connectors from your control systems and DCS to PI Data Archive, with Transpara Extractors pointed directly at those same sources. Instead of data flowing to PI and then being read by Transpara, data flows directly into tStore.

Once the Extractors are running and verified, PI Data Archive has no live data flowing into it and no applications reading from it. You can decommission the PI Server at your discretion.

What this gives you: Zero dependency on AVEVA PI. No Flex Credits. No per-tag licensing. No PI admin overhead. Your tags and your history exist in tStore on infrastructure you control, priced on a model that doesn’t penalize you for tag count.

Technical notes:

• The priority order for Interface migration is: start with sources where Transpara has a well-tested direct extractor, and leave the most complex or non-standard interfaces for last.
• For proprietary DCS connections where no standard extractor exists, you have options: use the existing PI Interface as a bridge temporarily (read from PI into tStore while you build the direct path), replace with OPC-UA, MQTT, or Modbus where the DCS supports these, or commission a custom extractor for specific legacy sources (although Transpara supports hundreds already).
• Historical data from before the extractor cutover date already lives in tStore from Phase 2. There is no gap in history at the handoff point.
• PI Data Archive can be kept in a read-only state for a defined period after the extractors are running, giving you a rollback option if any interface produces unexpected data. When you’re satisfied, shut it down.

Risk level: The highest of any phase, concentrated in the interface-to-source migration step. Mitigate by migrating interfaces one at a time, running PI and the Transpara extractor in parallel until you verify data parity, and maintaining the rollback option until you’re confident.

What You Keep, and What Changes

At the end of a full migration, here’s the honest accounting:

What stays the same for your operations team: They still see process data, KPIs, trends, and dashboards. The data is the same data. The only difference is that it now comes from a modern platform with better, more flexible visualizations and the ability to use it on their phones or any other device.

What stays the same for your engineering team: The asset hierarchy and process structure carries forward from AF into tModel. Calculations that run in AF Analytics run in tCalc. Excel reports that use DataLink use the Transpara add-in. The intellectual work your team has put in over the years doesn’t disappear.

What changes: PI Vision screen-building becomes optional. KPI-centric views generate automatically or via drag and drop. Every operator and manager who previously had no access to PI data now has a real-time view on any device. Calculations that required specialized AF knowledge can now be built and maintained by any engineer who knows Python. And you stop receiving Flex Credits renewal invoices.

What you need to plan for: The PI admin skill set that manages your current deployment is specialized. That expertise is valuable during the migration and for maintaining tStore and tCalc afterward. The learning curve is real, though much shorter than the PI learning curve was. Transpara has no customers that require a dedicated full-time Transpara administrator, even on global deployments.

Frequently Asked Questions

How long does a full migration take? For most enterprise PI deployments, a full migration from first deployment to PI decommission takes 4 to 36 months. The range is wide because the pace is entirely customer-controlled. Organizations under active Flex Credits pressure tend to move faster through Phases 2 through 4. Organizations with complex, non-standard PI Interfaces to legacy hardware take longer on Phase 6. Most customers start seeing ROI within the first 30 days of Phase 1.

Do we have to migrate all our tags? No. A tag audit typically reveals that a meaningful percentage of tags in any long-running PI deployment are no longer actively read by anything. These don’t need to migrate. You pay for them in Flex Credits today; you don’t have to bring them forward. The migration is a natural opportunity to rationalize your tag inventory and only carry forward what earns its keep.

What happens to our 20 years of PI history? Your historical data backfills into tStore during Phase 2. The backfill process reads historical PI data and writes it into tStore with full fidelity, including timestamps and data quality flags. At the end of Phase 2, tStore holds your complete history going back as far as PI does. Nothing is lost.

What if we have a custom PI Interface to a legacy system? Custom or non-standard PI Interfaces to proprietary hardware are the most complex piece of any migration. You have three options: use the existing PI Interface as a temporary bridge while you build a direct Transpara path, migrate the source system to a standard protocol (OPC-UA, MQTT, Modbus) that Transpara supports natively, or work with Transpara to develop a custom extractor for the specific source. None of these require shutting down PI before the replacement is ready.

Can we migrate just PI Vision and keep PI Data Archive? Yes, and this is the most common first step. Phase 1 of this guide delivers exactly that: tView running on top of your PI data, giving your operators and managers modern mobile dashboards without touching anything in PI. Many customers stay at this configuration indefinitely because it solves their most urgent problem, better operational visibility, without requiring any data migration.

What does Transpara tStore replace technically? tStore replaces PI Data Archive as a time-series historian. It runs on the battle-tested foundation of PostgreSQL/TimescaleDB (but productized for industrial use and supportability by Transpara), operates on Linux via Kubernetes, and provides horizontally scalable, high-availability storage for industrial time-series data. It is a more modern and flexible version of PI. It includes all the fundamental historian capabilities: compression, interpolation, historical playback, and high-frequency data storage.

What is the rollback plan if something goes wrong? Each phase of this migration is designed with an explicit rollback. In Phases 1 through 4, PI continues running unchanged. Transpara is additive. If something doesn’t work as expected, you remove or revert the Transpara component without touching PI. In Phase 5, you maintain PI in parallel until every downstream application is verified. In Phase 6, you keep PI Data Archive in read-only mode until you’re satisfied with the extractor output. A full cutover only happens when your team has verified the replacement at each stage.

How Transpara Can Help

If real-time operational visibility is a challenge you’re facing, you’re not alone. At Transpara, we help teams like yours gain clarity from complex systems without the need to centralize or overhaul your data stack.
Learn more about Transpara
Browse our documentation
Contact us