When an organization replaces an aging SCADA system, the flashy part is the new screens and dashboards. The part that actually determines whether the migration succeeds is far less glamorous: making sure every single point in the old system lands on the correct point in the new one, with the right name, the right units, and the right alarm limits. That translation table is called tag mapping, and it is the quiet backbone of every SCADA migration. This guide explains what a tag map is, how the mapping spreadsheet is built, how orphaned and duplicate tags are handled, and how the map is validated before anyone trusts the new system.
Tag Mapping (Migration) in one line: Tag mapping is the crosswalk that translates every point in a legacy SCADA system to its equivalent in the replacement system, reconciling naming conventions, data types, engineering-unit scaling, and alarm limits along the way. It is typically maintained as a row-per-tag spreadsheet that pairs each old tag with its new counterpart and records how each attribute is converted. Because everything downstream - graphics, history, alarms, reports - depends on it, an accurate tag map is the core deliverable of any migration.
A tag is the named handle a SCADA system uses for a single piece of information - a pressure reading, a valve position, a pump run status. Every graphic reference, trend, alarm, and report is wired to a tag by name. When you move to a new system, none of that plumbing survives automatically, because the new system almost never names, structures, or stores tags the same way the old one did. Tag mapping is the discipline of pairing each legacy tag with its new-system equivalent and documenting exactly how each of its attributes carries across, so that the meaning of a point is preserved even when its name and internal representation change.
The reconciliation goes well beyond matching names. Data types have to line up - a value stored as an integer in the old system may need to become a floating-point number in the new one, or a packed status word may need to be split into individual boolean tags. Scaling has to be preserved so that a raw count still resolves to the same engineering value in the same units, and the direction of any conversion has to be right so a level does not read as a percentage or a pressure end up off by a factor. Alarm limits, deadbands, and priorities have to travel with the point so operators see the same thresholds they always have. Each of these is a column in the map, and getting any of them wrong silently corrupts a point that otherwise appears to have migrated fine.
The mapping usually starts as a spreadsheet exported from the legacy tag database - one row per point, with columns for the old name, address or source, data type, scaling, units, and alarm settings. Alongside each old tag, the new name and its new attributes are filled in, plus a status column noting whether the tag is a clean one-to-one move, needs transformation, or is a special case. This spreadsheet becomes the single source of truth for the migration and the artifact every stakeholder reviews. Building it is painstaking because a real system rarely has a tidy tag list; it has years of accumulated history, and the map is where that history has to be untangled.
Two categories cause most of the pain. Orphaned tags are points that exist in the old database but drive nothing - a tag left behind by a removed instrument, or a test point that was never cleaned up. The temptation is to migrate everything to be safe, but that carries dead weight forward; the discipline is to decide deliberately whether each orphan is retired or kept. Duplicate tags are the opposite problem: the same physical measurement referenced under two names, or a naming collision where two genuinely different points share a name after a convention change. These must be resolved to a single authoritative tag before mapping, or the new system inherits ambiguity that will surface later as a mismatched trend or a phantom alarm. Working these edge cases out is where most of the real effort in a tag map goes.
One of the highest-value and easiest-to-break parts of a migration is historical continuity. Operators and engineers expect to open a trend and see years of data, not a record that starts on cutover day. Preserving that means the tag map has to define not only how live values move but how archived history is carried across or linked, so a point's past and future line up under one identity. If the mapping breaks a tag's continuity - a renamed point whose history is left stranded under the old name - the new trend appears to begin from nothing, and the loss is usually discovered only when someone needs the old data during an investigation.
The map is proven, not assumed, and the standard way to prove it is a parallel run: the legacy and new systems poll the same field data at the same time, and the two are compared point by point. A pressure that reads 412 in the old system had better read 412 in the new one; an alarm that is active in one had better be active in the other. Discrepancies flush out the mapping errors that no amount of desk review catches - a swapped scaling, a byte-order mismatch, an alarm limit entered in the wrong units. Only once the mapped points agree across a representative period does the team trust the map enough to cut over. This is why experienced integrators treat tag mapping as the true core of the project and the screens as comparatively easy: the graphics can always be rebuilt, but a wrong tag map quietly poisons everything the new system tells its operators.
Because it is where the accumulated inconsistency of a real system has to be resolved point by point. A live SCADA database carries years of renamed tags, orphaned points, duplicate references, and inconsistent scaling, and the map has to reconcile every one of them so meaning is preserved across two systems that name and store data differently. The graphics can always be rebuilt, but a single wrong mapping silently corrupts a point in ways that may not surface until much later.
It has to be deliberately carried across or linked as part of the mapping, or it is lost. Each tag's archived data is tied to its old identity, so a renamed point can leave its history stranded under the old name while its new trend appears to start from cutover day. Preserving historical continuity means the map defines how a point's past connects to its future under one identity, which is essential because operators expect to open a trend and see years of data, not just what was collected after go-live.
The most reliable method is a parallel run, where the legacy and new systems poll the same field data simultaneously and their points are compared side by side. Values, statuses, and alarm states that match across a representative period give confidence the mapping is correct, while discrepancies expose errors like swapped scaling, wrong data types, or mismatched alarm limits. Only after the mapped points reliably agree does the team trust the map enough to switch over.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.