Renaming Historian Tags Without Losing Three Years of Trend

The trend goes flat at 21:40 on a Tuesday

An operator pulls up a twelve-month trend of a surge tank level, because a supervisor wants to know whether the level swing has always been this bad or whether it started after the pump rebuild. The trend draws a clean line from today back to the middle of March, and then nothing. Flat, empty, gone. The instrument has been in service since 2019.

Nothing failed. Three months earlier the site finished a naming cleanup and TK101_LT_PV became Area1.Tank101.Level.Percent. The rename worked. Current data is fine. The archive is fine — every one of those 2019 samples is still on disk. They just aren't reachable from the name the operator is now typing into the search box.

That is the whole problem in one paragraph. A historian rename is not a cosmetic edit and it is not a configuration change. It is a data migration, and the thing being migrated is the ability to find your own history.

Find out what your historian thinks a tag is

Before anything else, answer one question: when the archive stores a sample, does it store the tag name or a numeric identity that happens to have a name attached?

The answer decides everything else, and it varies by product more than people expect.

PI Data Archive keys archive events to the integer PointID, not to the tag string. Rename a point and the history follows it — the archive doesn't care what you call it. What breaks instead is everything holding the name: PI AF attributes with a PI Point data reference, PI Vision and ProcessBook displays, DataLink spreadsheets, and any custom client that resolves by name at query time. The data survives, the references don't.

Ignition's tag historian goes the other way. Historized values land in sqlth_data_* partition tables keyed to an id from sqlth_te, and sqlth_te is where the tagpath lives. Rename a historized tag and Ignition stamps the old sqlth_te row with a retired timestamp and inserts a new row for the new path. Both halves of the history exist, both are queryable, but no single tag path spans the cutover. Stitching them means an offline UPDATE on sqlth_te — against a backup, with the gateway's history quarantine drained first — not a change you make on a live Tuesday afternoon.

Anything that treats the name string as the identity turns a rename into a delete plus a create, whether or not the UI says "rename."

Do not take the vendor manual's word for it, and definitely don't take mine. The test costs ten minutes on a development historian: write a few known values, wait for them to archive, rename the point, then query a window that starts before the rename and ends after it. Whatever comes back is the behaviour you are planning around.

Three models, and the one I default to

Model	What happens	Where it fits	What it costs you
Alias only	New display name resolves to the existing point; storage identity untouched	Cosmetic cleanup, or when integrations are out of your control	Tools that expose internal names still show the old one, so you now maintain two vocabularies
Rename in place	Point identity kept, name changed, samples stay attached	Historian keys on a point ID and audits the rename	Every consumer keying by name breaks at once
New point plus bridge	New tag starts collecting, old tag goes read-only	Site-wide standard change, or historian consolidation	Trends and reports need explicit stitching across the cutover timestamp

I default to rename-in-place when the historian keys on a point ID, and to new-point-plus-bridge when it doesn't — because on a name-keyed historian, "rename in place" is the new-point model with the old point silently deleted, which is the same work with none of the safety.

The alias-only model is more useful than it looks for a first pass. It gets operators the readable names on their screens today and lets you sequence the integration work over the next few months instead of in one change window. The price is real, though: two names in circulation means the next engineer has to learn both, and if you never finish the migration you've made the namespace worse, not better.

The dependency hunt

Do not open the point configuration first. Open the list of everything that reads the old names, because that list is always longer than the tag list.

The mechanical part is easy. Export the point list, take the column of old names, and grep the reports share, the SCADA project export, the scripts directory, and the MES config repo for each one:

grep -rIl -F -f old_tag_names.txt /mnt/reports /srv/scada-export /opt/mes/config

On the last one of these I ran, forty-odd files came back — and about a third of them were spreadsheets nobody had opened in two years but that a scheduled task still refreshed every Monday morning.

The part grep won't find is what actually bites:

Saved operator trend groups. These often live in a client profile or a per-user workspace, not in the project you export. An operator with six years of saved trends is a walking dependency list, and the only way to enumerate them is to ask.
Calculated tags and event frame templates whose inputs are name-resolved. These fail quietly — the calculation doesn't error, it just flatlines.
Alarm-to-trend navigation. The jump from an alarm in the summary to the related trend is usually built on a name substitution, and it breaks in exactly the situation where someone needs it.
Scheduled exports running under a service account with its own cached query definition or its own credentials, which means it doesn't break when you test as yourself.
Printed material. P&IDs, FAT reports, the loop folder, the SOP taped to the panel. You cannot update these in a change window, which is the argument for keeping the old name discoverable rather than erasing it.

For each dependency record one of three dispositions: updated automatically, updated by hand, or cannot be updated. That third category is the one that dictates how long you keep the old-name alias alive.

Are you renaming it, or changing what it means?

Rename projects surface every other problem with a point, and the temptation to fix them all in the same change is strong. Fix them — but not in the same line of the change record.

Going from TK101_LT_PV to Area1.Tank101.Level.Percent is a rename. Going from percent of span to millimetres in the same step is a data meaning change, and it makes every historical query that crosses the cutover return two different physical quantities under one name. Same for anything that alters what gets stored: exception and compression deviation, digital state sets, bad-quality handling. If you recreate a point rather than rename it, compression settings come back as the point-class defaults, not as whatever the previous engineer tuned them to — so the new tag records a different number of events per hour than the old one, and any high-resolution comparison across the boundary is comparing two different sampling regimes.

Worth doing while you have the point list open anyway: check that the new names are actually consistent with the standard you claim to be adopting. If the instrument numbering follows ISA-5.1 and the asset hierarchy follows the equipment model in ISA-95 / IEC 62264, say so in the naming convention document and hold the new names to it. A "standard" that lives only in the lead engineer's head produces a second cleanup project in four years.

Cutover

Small rename, a handful of tags, low integration surface: a reviewed spreadsheet and a maintenance window is enough. Site-wide: this needs a scheduled change with a rollback.

Freeze the old-to-new mapping. No additions after this point — additions are the next change, not this one.
Back up historian point configuration, the historian's own configuration database if it has one, and every report definition you're about to touch.
Check for collisions against retired names as well as active ones.
Apply aliases, renames, or new points per the chosen model.
Update the collector or OPC source mapping before anything reloads. A collector still pointed at the old name will helpfully recreate the old point for you.
Confirm current data is arriving with good quality on the new name.
Query old ranges through the tools operators actually use — not the admin console.
Run the production reports over a period that crosses the cutover timestamp.
Hold rollback ready until the first full operating shift has signed off.

Step 7 has a trap worth naming. Interpolated queries lie. Ask a historian for interpolated values across a hole and it will draw you a straight, plausible line from the last sample before the gap to the first one after it, and your verification screenshot will look perfect. Verify with a recorded/raw query — RecordedValues rather than InterpolatedValues on PI, the raw retrieval mode on whatever you're running — so a gap shows up as a gap.

And record the cutover instant in UTC. Your historian, your report engine, and your MES will not all agree about local time across a DST boundary, and a mapping table that says "14 March, 21:40" is ambiguous by exactly the amount that makes it useless.

Keep the old names findable

Erasing the old name from everything is the aggressive option and it is almost always wrong. Somebody will be standing at a panel six months from now reading a name off a 2019 loop drawing.

Store the previous name in the point description, an extended attribute, or a dedicated alias field. Keep a read-only old-name alias for at least one full maintenance cycle — a turnaround, an annual shutdown, whatever the site's real period is, not thirty days because thirty days is a round number. Put the change reference in the point configuration comment. Export the cross-reference to CSV and keep it in the turnover package, not in someone's home directory.

One rule with no exceptions attached: never reuse a retired historian tag name for a different physical measurement. Reuse makes 2019 tank level data look like 2026 flow data, and the day that matters will be an incident investigation or a quality hold, where "the tag name was reused" is not an answer anyone wants to write down.

What usually goes wrong

The failures are boringly consistent, and none of them are historian engine failures:

A report file is updated but its scheduled service account keeps a cached query with the old name.
A calculated tag holds an old input reference and flatlines the moment the source point is retired — no error, no alarm, just a straight line nobody notices for a week.
The new tag reads correctly but with different compression settings, so a comparison against last year's run shows a difference that is entirely an artefact of sampling.
A dashboard shows live data and returns nothing for last quarter.
A collector recreates the old point because its source mapping was never updated.
An operator opens a saved trend group, sees a flat line, and files a work order against a perfectly healthy transmitter.

Every one of these is a dependency you didn't find, which is why the dependency hunt gets more of the schedule than the rename itself.

The thing to check first, if you're inheriting a namespace that has already been through one of these: query a handful of tags across their known rename dates with a raw retrieval and see what actually comes back. A previous migration that nobody validated is the most common reason a historian's long-range history is quietly unusable, and nobody finds out until the first year someone tries to do trending on it.