Migrating BMS Point History When Replacing a Head End

A head-end replacement is scoped around what the new system will do. The tender covers graphics, points, sequences, integration and training. Historical data is mentioned, if at all, as a line saying the existing trend data will be made available, which is not the same as migrated and is frequently discovered to mean an export in a format nobody can use. By the time anyone looks properly, the old system is being decommissioned and the window is closing.

The message up front: decide what the history is worth before the project starts, because the answer determines the approach. The identity problem is the hard part, not the volume: the new system will number its points differently, so without a mapping from old identity to new, the data arrives as an orphaned series nobody can join to anything. Get the export while the old system is still running and supported, and treat separating the history from the head end as the permanent fix rather than repeating this at the next replacement.

1. Decide what it is worth, honestly

Not all history earns a migration, and the useful question is what specific things become impossible without it.

• Seasonal comparison. Needs more than a year to compare like with like. The commonest genuine justification.
• Baselines for savings claims. If an energy or optimisation programme has a measured baseline, losing the data behind it ends the ability to evidence the claim.
• Reporting obligations. Where a scheme or contract requires retention of the underlying data, the decision is not yours to make.
• Asset history and failure analysis. Condition trends behind a chronic fault, which connect to the case records in converting repeated faults into one case.
• Nothing in particular. A legitimate answer for a building where nobody has looked at a trend older than a month. Say so and move on rather than migrating out of caution.

The resolution question follows. Full-resolution history is a large volume and rarely what the use cases above need; hourly or daily rollups usually satisfy all of them at a fraction of the size, which is the tiering argument in BMS data retention policy. Migrating a coarse long history and a short fine one is almost always the right shape.

2. The identity problem, which is the real work

Volume is a logistics issue. Identity is where migrations actually fail.

The old system numbered its points one way. The new one will number them its own way, and the mapping between the two exists nowhere unless somebody builds it. Without that mapping the migrated data is a set of series labelled with identifiers the new system does not recognise, joined to nothing, and effectively write-only.

• Build the crosswalk explicitly: old identity, new identity, and the asset both refer to. This is the same join described in BMS point-to-asset mapping, with the old system as an additional column.
• Do not key the crosswalk on point names. Names will be changed during the new system's commissioning, often as a deliberate tidy-up, and a name-keyed migration breaks at exactly that moment.
• Expect it to be imperfect. Points that existed then and not now, points that are new, points that were renamed and re-ranged. Each needs a disposition rather than a silent drop.
• Anchor on the asset where the point mapping is unclear. Attaching history to the right asset with an uncertain point attribution is more useful than discarding it.
• Produce the crosswalk during the project, while people who know both systems are still engaged. Reconstructing it afterwards is substantially harder.

3. Getting the data out

Whichever route, require three things in the export beyond the value: the point identity as the old system held it, the timestamp with its basis stated, and the units. An export of values and times alone forces every unit to be inferred later, which is the error described in sensor units and scaling.

Access to this export is a contractual question as much as a technical one, and it belongs in the terms discussed in BMS service contracts. A supplier being replaced has limited incentive to make it easy.

4. What has to be reconciled on the way in

• Timestamp basis. Local or UTC, and how daylight saving was handled. Getting this wrong shifts the entire history by an hour for part of each year, which is both subtle and permanent. The underlying issue is in timestamps and clock synchronisation.
• Units and scaling. The old system's conventions may differ from the new canonical units, so convert on ingestion and keep the original.
• Quality flags. Where the old export carries them, map them to the new vocabulary rather than discarding, per BACnet data quality flags. Where it does not, flag the whole migrated set as quality-unknown rather than implying it was verified.
• Rate versus quantity on meters, which is the distinction in validating meter units and is frequently lost in an export that labels everything as a reading.
• Known discontinuities. Instrument replacements, recalibrations and scaling changes in the old data, which should be carried across as events if any record of them exists, per sensor replacement and BMS history.

5. Validating the migration

A load that completes without error is not a successful migration.

• Row counts per point per period, source against destination. Discrepancies cluster and the clusters identify the cause.
• Spot-check values at known timestamps, chosen across the full range rather than from the recent end. Problems concentrate in the oldest data.
• Re-derive a known total, such as a monthly consumption figure somebody previously reported, and confirm it matches. This catches unit and timestamp errors in one check.
• Check the boundaries. The join between migrated history and new live data is where duplicates and gaps appear, and the identity rules in handling duplicate sensor readings should make the overlap harmless.
• Verify the daylight-saving transitions specifically, in both directions. This is where a timestamp basis error becomes visible and nowhere else.
• Keep the raw export until validation is signed off, and preferably well beyond.

6. The legitimate alternative

Not migrating is a defensible decision when made deliberately rather than by default.

• Keep the raw export as a cold archive, documented, with a note on how to read it. Small, cheap, and it preserves the option.
• Migrate only what the use cases need, which is often a short list of points and a coarse resolution rather than everything.
• Record the discontinuity explicitly, so that anybody querying across the changeover date knows the history begins there and does not read the absence as a quiet period.
• Accept the baseline loss knowingly. If a savings claim depends on the old data and you are not migrating it, say so now rather than discovering it when the claim is questioned.

7. Not doing this again

The structural fix is to stop keeping long-lived data inside short-lived software. A separate store, fed from the building and outliving any one head end, turns the next replacement from a migration into a reconfiguration of where the data comes from. That is the main argument in what is a BMS data historian, and a replacement project is the moment it is cheapest to act on, because the export is happening anyway.

Two supporting pieces make it durable: the point crosswalk kept as a living record rather than a project artefact, in the register described in the BMS point dictionary, and an export right written into the new contract so the next extraction is an obligation rather than a negotiation.

The idea to walk away with

The volume is a logistics problem and the identity is the real one. Without a crosswalk from old point identity to new, migrated history is a set of orphaned series that nobody can join to an asset, and building that crosswalk requires people who understand both systems and are only available during the project.

So scope it at the start, take the raw export early while the old system still runs, decide the resolution from the actual use cases, and use the opportunity to move the history somewhere that will survive the next replacement.

Final thoughts

If a head-end replacement is on your horizon, the single most valuable action available today is not planning the migration. It is taking the export, now, and putting it somewhere safe.

That one step removes the deadline from the decision. Everything else about the migration can be designed calmly afterwards, and if the conclusion turns out to be that the history was not worth migrating, you have lost very little by having it.

Related reading: What is a BMS data historian, BMS head-end platforms compared, BMS point-to-asset mapping, BMS point dictionary, CAFM data migration strategy, BMS data retention policy.