How to Plan a SCADA Tag Migration

Back to Blog

Build a Complete Old-to-New Mapping

The backbone of any migration is a mapping that accounts for every existing tag and what it becomes in the new system. For each old tag, record the new name, the new structure, and any change in scaling, units, or type, so nothing is left to be figured out during the cutover. A migration without a complete mapping is a migration that loses tags silently - the ones nobody mapped simply do not arrive, and their absence is discovered later when a screen or a report comes up empty.

Use the mapping to enforce the new naming convention rather than carrying old inconsistencies across. A migration is one of the rare chances to clean up a naming scheme that grew organically, so if the new system adopts a proper tag naming convention, the mapping is where each old ad-hoc name gets assigned its correct new one. Carrying the old mess across unchanged wastes the opportunity and locks the inconsistency in for another generation.

Flag the tags that change meaning, not just name, because those are the dangerous ones. A tag whose scaling, units, or type changes in the new system needs special handling so its history is not misinterpreted after the move, and a tag being split or merged needs an explicit decision about how its past maps forward. The straightforward renames are easy; the tags that genuinely change are where the mapping earns its keep, and each one deserves a deliberate note rather than a silent pass-through.

Decide How History Follows Each Tag

The history is usually the hardest and most valuable part, so decide explicitly what happens to each tag's past. The options range from carrying the full history across under the new tag name, to keeping the old history accessible in the old system and starting fresh in the new, to a hybrid. What you cannot do is leave it undecided, because the default - starting blank - throws away years of trend data that people rely on for exactly the long-term comparisons a new system is often meant to improve.

Handle the timestamp and structure carefully when carrying history across, because migrated data has to land on the same timeline correctly. History moved to a new system must keep its original event times so a trend spanning the cutover is continuous, which is the same discipline as normalizing timestamps in a historian applied to a bulk move. A migration that re-stamps history on import collapses the past onto the migration date, which is the worst possible outcome for the data you were trying to preserve.

Choose the mechanism that fits the volume and the change. Where a tag maps cleanly, a bulk historian transfer or a CSV backfill can carry its history forward; where a tag changed meaning, you may keep the old history in place rather than migrate a series that no longer means the same thing. Match the method to each tag's situation rather than applying one blanket approach, since the clean renames and the genuinely changed tags need different treatment.

Cut Over in Stages With a Rollback

Migrate in stages, not in one big bang, because a staged migration lets you catch problems on a small population before they hit the whole plant. Move and verify a manageable group of tags - one area, one asset type - confirm they work in the new system with their history intact, then move the next. A single all-at-once cutover means any systemic error affects everything simultaneously and you discover it with the whole plant already migrated, which is the hardest possible position to recover from.

Keep the old system available as a proven rollback until the new one is fully validated. Until every migrated tag is confirmed working with its history and alarms in the new system, the old system is your way back, and shutting it down prematurely turns any migration problem into an emergency. This is the migration-scale version of staging a config change with rollback: never commit irreversibly until the new state is proven, and the old system is the rollback for the whole move.

Verify each migrated stage the same way you would validate any new configuration. Confirm each migrated tag reads correctly, carries the history you intended, has working alarms, and matches its mapping, before that stage is considered done and before you rely on it. This per-stage validation is the same end-to-end proof used in a pre-go-live validation, applied to each batch, so the migration is a series of validated steps rather than a single leap of faith.

Verifying the Migration Preserved Everything

Reconcile the migrated system against the mapping to prove nothing was lost. Every tag in the mapping should exist in the new system, reading correctly and mapped as intended, and any tag in the old system absent from the mapping is a tag about to be left behind. This reconciliation is how you catch the silent losses - the points nobody mapped and the ones that failed to migrate - before the old system is retired and they become genuinely gone.

Verify the history actually followed by trending across the cutover. Pull a trend that spans the migration date on a migrated tag and confirm it is continuous, with the past carried forward at its correct times and no gap or collapse at the cutover. A tag that reads fine live but has lost or misplaced its history is a half-successful migration, and only a trend spanning the boundary reveals it. Confirm the alarms and their history came across too, so the new system inherits not just live values but the full context, and keep the old system until every one of these checks passes.

Common Mistakes to Avoid

The migration-killing mistake is an incomplete mapping, which loses tags silently - the unmapped points simply never arrive and their absence surfaces later as an empty screen or report. Build a mapping that accounts for every existing tag. The second mistake is leaving the fate of history undecided, defaulting to a blank start that discards years of trend data people depend on for long-term comparison.

The third mistake is a single all-at-once cutover with no staging, so any systemic error hits the whole plant simultaneously and is discovered too late to contain. Migrate and verify in stages. The fourth is retiring the old system before the new one is fully validated, turning any migration problem into an emergency with no way back - keep the old system as a proven rollback until every migrated tag, its history, and its alarms are confirmed.

Frequently Asked Questions