Moving a historian without losing the history
The data is the asset. The software is replaceable, and the migration is where decades of it are quietly lost.
Historian platforms are replaced every ten to fifteen years, for the usual reasons: the vendor ends support, the architecture no longer fits, or the site standardises on something else.
The software is the smaller part of the problem. The accumulated history — sometimes twenty years of it — is the thing that cannot be recreated, and migrations routinely end with a decision to leave it behind because bringing it forward proved harder than expected.
Decide what has to come across
Bringing everything at full resolution is expensive and frequently unnecessary. The categories deserve different treatment.
Attendance records can support staffing and training reviews when they are kept separate from competency evidence. Further details are available at this link.
A useful external reference for timing and synchronisation is NIST time and frequency services.
Data with a regulatory retention requirement must come across, or must remain accessible in the old system for the remainder of its retention period, which means keeping that system running.
Recent data — the last one to three years — is used operationally and should come across at full resolution.
Older data is mostly used for long-term trending and can often come across as aggregates rather than raw samples, at a fraction of the volume.
Data on tags that no longer exist is a candidate for archive rather than migration.
Test the extraction before committing
The critical unknown is whether the old system will give up its data in a usable form, and at what rate.
A trial extraction of one month for a few hundred tags answers both. It reveals the throughput, which determines how long a full extraction takes, and it reveals format problems while there is still time to plan around them.
Sites that skip this discover during the cutover window that the extraction will take six weeks.
If pulling a year takes four days, twenty years takes three months and cannot happen during a shutdown. That changes the whole approach.
Timestamps and time zones during migration
Migration is where time zone inconsistencies surface. A source system recording local time moved into a target recording UTC, without conversion, shifts everything by an offset that varies across daylight saving boundaries.
This is correctable if caught and extremely tedious if discovered a year later. Verify explicitly by comparing known events across the boundary.
Verify a sample properly
After migration, verification is normally a spot check that the data is present. Present is not the same as correct.
A proper verification compares values, not just existence: select periods, including at least one containing a known event, and compare the old and new systems point by point. Check aggregates over a month against the source system's own reporting.
Include boundary cases: the earliest data, the most recent, a period with a communication outage, a period spanning a daylight saving change.
Keep the old system available
Retiring the source system immediately after migration removes the ability to check anything. Keeping it available in read-only form for a defined period — six months to a year — costs little and provides a reference when a discrepancy is found.
It also covers the case where the migration turns out to have lost something that nobody noticed during verification, which is common enough to plan for.
Preserve the context as well as the values
Migrations tend to move the numeric data and lose the surrounding metadata: descriptions, units, the asset model, the calculation definitions, the batch context.
Migrated values without their descriptions are technically preserved and practically unusable, because nobody can find anything. The metadata should be treated as part of the migration scope rather than something to be recreated afterwards.
Take the opportunity to clean up
A migration is the natural point to remove tags for equipment that no longer exists, correct descriptions, apply a consistent naming convention going forward and set compression and retention deliberately rather than by default.
Doing it during the migration costs relatively little. Doing it afterwards means a fresh system inherits the accumulated disorder of the old one on day one.
Running both systems in parallel
A period during which the old and new historians both collect data provides a verification opportunity that does not exist afterwards: the same measurement, over the same period, in both systems, directly comparable.
A few weeks of parallel collection allows systematic comparison and catches configuration errors — wrong scaling, wrong compression, a tag mapped to the wrong source — while both references exist.
It costs a licence overlap and some server capacity, and it is substantially cheaper than discovering a systematic error six months after the old system was decommissioned.
Mapping the tag names
Migrations frequently involve a naming change, either because the new system imposes constraints or because the opportunity is taken to apply a convention.
The mapping between old and new names has to be preserved permanently, not just used during the migration. Every report, every historical reference, every document written over the preceding decade uses the old names, and without the mapping those references become untraceable.
What the migration reveals
Extraction from the old system tends to surface things nobody knew: tags with no data, tags collecting duplicates, periods with gaps nobody had noticed, sampling rates that were never what the documentation claimed.
Recording these findings is worthwhile beyond the migration itself. They are a description of how the previous configuration actually behaved, and several of them usually indicate practices that would otherwise be repeated in the new system.
Deciding what not to migrate
Migration scope discussions default to bringing everything, because deciding what to leave requires judgement and carries risk.
Explicit exclusions — data for decommissioned equipment, tags with no queries in five years, resolution beyond what the retention policy requires — reduce the effort substantially and are defensible when documented.
Where uncertainty exists, archiving the excluded data separately rather than discarding it provides a fallback at low cost, and it converts an irreversible decision into a reversible one.
Communicating the change to users
Historian users across the site have built queries, spreadsheets and reports against the old system, most of which the migration team does not know about.
Announcing the migration early, and asking users what they have built, surfaces dependencies that would otherwise break silently on cutover.
It also identifies the reports that matter, which is useful input to deciding what has to work on day one.