Platform Migration: What Actually Breaks When You Change Monitoring Vendors

Every operator who has changed monitoring platforms remembers the thing that broke that nobody warned them about. Usually it was not the software. It was the history. Migrating from one monitoring platform to another sounds like a procurement exercise — pick the better product, move across, done. In practice it is a data-continuity exercise wearing a procurement costume, and the parts that break are rarely the ones the sales process discussed. Your dashboards will look different; that is trivial. What is not trivial is what happens to years of historical data, to the tag names your reports depend on, to the alarm set your operators trust, and to the KPI baseline every performance comparison is measured against. Handle those badly and you spend the first year on the new platform unable to compare it to the old one.

What actually breaks in a migration

Four things break with enough regularity that they should be treated as certainties to plan for, not risks to hope against.

Historian gaps

Your historical time-series data lives in the outgoing platform's historian. Getting it out — completely, at full resolution, with quality flags intact — is the single hardest part of most migrations. Data may be exportable only in summarised form, only for recent periods, or in a format that loses the granularity you will later need. Any period that does not transfer cleanly becomes a permanent hole in your record, straddling the exact boundary where you most want to compare old performance to new.

Tag remapping

Every signal on your plant has a tag name, and your reports, alarms and analyses are wired to those names. The new platform will almost certainly name things differently. Mapping thousands of tags from the old scheme to the new — correctly, without silent mismatches — is painstaking, and errors here are insidious: a mis-mapped tag does not fail loudly, it just quietly reports the wrong signal, and the mistake surfaces months later as an inexplicable anomaly.

Alarm re-tuning

The alarm set on your outgoing platform represents years of accumulated tuning — thresholds adjusted, nuisance alarms suppressed, priorities set through hard experience. That tuning does not transfer automatically. On the new platform you often start closer to a default alarm configuration, which means either an alarm flood while you re-tune, or the risk of missing faults the old tuning would have caught. Neither is acceptable to discover after cutover.

Reporting discontinuity

Your KPIs — performance ratio, availability, loss figures — were computed a particular way on the old platform: particular assumptions, particular handling of gaps and edge cases. The new platform computes them its own way. Even with identical raw data, the two can produce subtly different numbers, which means the day you switch, your performance trend has a step in it that is an artefact of the platform change, not a change in the plant.

What you can and cannot take with you

Being clear-eyed about this before you start prevents the worst surprises. You can usually take your raw historical time-series data — but its completeness, resolution and format depend entirely on what the outgoing platform's export permits, which is why data portability belongs in the contract. You generally cannot take the outgoing platform's computed history — its specific KPI calculations — because those are the vendor's methodology, so you may need to recompute your history from raw data on the new platform to get a consistent series. You cannot take alarm tuning, dashboards or configuration; those are rebuilt. Knowing which category each asset falls into shapes the whole migration plan.

The parallel-run period, and how long it really needs

The single most valuable risk-reducer in a migration is running both platforms in parallel for a period before decommissioning the old one. During the parallel run, the same raw data flows into both systems, and you can compare their outputs directly — verifying that tags are mapped correctly, that KPIs reconcile, that alarms behave, and that the new platform's numbers can be tied back to the old platform's history. How long is long enough? Long enough to see the plant through its full range of normal behaviour and at least some abnormal behaviour — which for a seasonal asset like solar or wind means the parallel run should span enough time to capture varied conditions, not just a quiet fortnight. A parallel run that covers only calm, clear weather has not tested how the two platforms handle the events that matter. The temptation to shorten the parallel run to save cost is exactly the false economy that produces the migrations people regret.

Re-baselining KPIs across the cutover

Because the two platforms can compute KPIs differently, the honest way to preserve a continuous performance history is to re-baseline: recompute a span of historical KPIs on the new platform, from raw data, so that the series before and after cutover is calculated consistently. This turns the step-discontinuity at the switch into a smooth series, and it means a performance comparison across the migration boundary reflects the plant, not the platform. Skipping this leaves you with two incompatible halves of history and no clean way to answer 'are we doing better or worse than last year' across the switch.

A migration checklist

Distilled to its essentials, a defensible migration plan includes:

• •Confirm the raw data export — completeness, resolution and format — from the outgoing platform before committing to the switch.
• •Build and verify the tag map thoroughly, with checks that catch silent mismatches, not just missing tags.
• •Plan the parallel run to span varied conditions, and hold to it rather than shortening it under cost pressure.
• •Reconcile KPIs across both platforms during the parallel run, and investigate any divergence before cutover.
• •Re-baseline historical KPIs on the new platform so your performance series stays continuous.
• •Re-tune alarms deliberately, carrying forward the accumulated wisdom of the old set rather than starting from defaults.

What to negotiate before you start

The best time to secure a clean migration is before you ever signed with the outgoing vendor — and the second best time is now, before you sign with the next one. The terms that make a future migration survivable are data-portability and exit clauses: the contractual right to export your complete historical data, at full resolution, in a usable format, with transition assistance, at the end of the relationship. An operator who negotiates these up front never faces the worst migration scenario, which is discovering at contract end that the data you assumed was yours is difficult, incomplete or expensive to retrieve.

Frequently asked questions

How long does a monitoring platform migration take?

It varies with portfolio size and data complexity, but the schedule is usually driven less by installing the new platform than by the data-continuity work around it: exporting and verifying historical data, mapping tags, running both platforms in parallel across varied conditions, and re-baselining KPIs. The parallel-run period in particular should span enough time to see the assets through a representative range of weather and operating states, which for seasonal renewable assets means it cannot be rushed. Treating migration as a data exercise rather than a software install sets realistic expectations.

Can you migrate historical SCADA data between platforms?

Usually the raw time-series data can be migrated, but its completeness, resolution and format depend entirely on what the outgoing platform's export permits — which is why data portability belongs in the contract. What generally does not migrate is the outgoing platform's computed history, such as its specific KPI calculations, because those reflect that vendor's methodology. To preserve a consistent performance series, operators often recompute their historical KPIs from raw data on the new platform rather than trying to carry across the old platform's computed figures.

What happens to your KPI baseline when you switch vendors?

Even with identical raw data, two platforms can compute KPIs like performance ratio and availability slightly differently, because of differing assumptions and edge-case handling. The result is a step in your performance trend at the moment of cutover that reflects the platform change, not the plant. The fix is re-baselining: recomputing a span of historical KPIs on the new platform from raw data, so the series before and after the switch is calculated consistently and the comparison across the boundary reflects the asset rather than the tooling.

Should you run both platforms in parallel?

Yes — the parallel run is the single most effective risk-reducer in a migration. Feeding the same raw data into both systems lets you verify tag mapping, reconcile KPIs, confirm alarm behaviour and tie the new platform's numbers back to the old platform's history before you decommission anything. The parallel run should span varied conditions rather than a quiet stretch, because it needs to test how both platforms handle the events that matter. Shortening it to save cost is the false economy behind most regretted migrations.

The bottom line