Planning a Historian Migration Without Losing the Archive
Historian migrations carry a risk that most IT migrations do not. The data being moved is the only record of how the plant behaved. If part of 1998 is lost, there is no second system to recover it from and no process that can regenerate it. The value of the archive is precisely its continuity.
That single constraint should govern the plan rather than appear as a line in the risk register.
Audit the source before planning the move
The most expensive migration mistake is faithfully reproducing existing defects on new infrastructure. Broken buffering, orphaned tags, analyses that fail silently, compression settings nobody has reviewed in fifteen years — all of it migrates perfectly well if you do not look first.
Auditing before planning routinely changes the scope, usually by revealing that some of what was going to be moved should be fixed or retired instead.
Reconcile, do not assert
“The migration completed successfully” is a statement about a process, not about data. Migrated history should be verified against the source statistically — value counts per tag per period, distribution comparisons, boundary samples at archive edges — and the evidence handed over.
Edges are where problems concentrate. Check the first and last values of each archive partition, daylight-saving boundaries, and leap days. If something has gone wrong with timestamp handling, that is where it shows.
Run in parallel until the new system has earned trust
Parallel running is sometimes treated as an optional luxury. It is the only practical way to discover the differences that matter: an interface that behaves subtly differently, a calculation that rounds another way, a display that was quietly reading from somewhere unexpected.
Keep a defined rollback point for the whole period, and agree in advance what evidence would trigger using it. Deciding that under pressure is how bad calls get made.
Rebuild interfaces rather than lifting them
Interface configuration is where migrations lose data after go-live. An interface that was never buffered correctly on the old system will not start buffering correctly because it was copied to a new one. Treat the migration as the opportunity to re-establish connections properly, with buffering verified by actually interrupting the link and confirming recovery.
Decide deliberately about compression
Legacy exception and compression settings usually reflect storage constraints that no longer exist. Migration is the natural moment to revisit them — but deliberately, class by class, with the reasoning recorded. Changing them silently means a discontinuity in the data at the migration boundary that will confuse somebody in three years.
Convert displays only where conversion helps
Automatic conversion of legacy displays is attractive and often the wrong answer. Many were built around the constraints of the old tool, and a mechanical conversion carries forward a layout nobody liked. It is frequently cheaper to rebuild the twenty displays people actually use, properly and template-driven, than to convert four hundred and support the result.
What good looks like at the end
An unbroken archive on a supportable platform, with reconciliation evidence you could show an auditor, a model and data quality better than they were before, interfaces verified under failure, and your own team able to operate it. How we run migrations.