Historian migrations carry a particular risk: the data you are moving is the only record of how the plant behaved. There is no second copy, no way to regenerate 1998 if something is lost, and the value of the archive is precisely its continuity.

LAMR plans and executes historian migrations and upgrades with that constraint treated as the governing requirement — not as a caveat in the risk register.

Migrations we handle

  • Legacy historian to AVEVA PI System. AVEVA Historian (Wonderware), Aspen InfoPlus.21, and older proprietary and DCS-resident historians.
  • PI version upgrades. Moving off out-of-support Data Archive and AF Server versions, including the intermediate hops that older estates require.
  • Infrastructure moves. Physical to virtual, on-premises to cloud-hosted, and data centre consolidation following reorganisation or acquisition.
  • Visualization upgrades. ProcessBook and legacy displays to PI Vision, with an honest assessment of what should be rebuilt rather than converted.
  • Estate consolidation. Merging separately grown site systems into one model and one set of naming conventions — usually the hardest and most valuable of these.

How we de-risk it

  • Audit first. We assess the source system before planning the move, so known defects are fixed rather than faithfully reproduced on new infrastructure.
  • Reconciliation, not assertion. Migrated history is verified statistically against the source — counts, value distributions and boundary samples — and you get the evidence, not an assurance.
  • Parallel running. Old and new operate side by side until the new system has earned trust, with a defined rollback point throughout.
  • Compression and exception review. Legacy settings are often inherited from hardware constraints that no longer exist. Migration is the moment to correct them deliberately, with the trade-off documented.
  • Interface rebuild. Connections are re-established and buffered properly rather than lifted, because an unbuffered interface loses data the first time the network hiccups.

What usually drives the decision

Migrations are triggered by supportability deadlines, hardware end-of-life, acquisition or divestiture, a move to cloud infrastructure, or a strategic programme — analytics, lakehouse integration, enterprise reporting — that the existing platform cannot carry.

Whatever the trigger, the outcome we aim for is the same: an unbroken archive on a supportable platform, with the model and data quality better than they were before, and your own team able to operate it.