--- title: "Upgrading your programme: when to adopt new technology" source_url: https://legionella.io/articles/upgrading-your-programme-when-to-adopt-new-technology/ canonical_url: https://legionella.io/articles/upgrading-your-programme-when-to-adopt-new-technology/ pillar: "Technology & Remote Monitoring" summary: "A four-question test for UK duty holders weighing remote monitoring, sensors and digital logbooks: when new Legionella tech earns its place, and when to wait." primary_keyword: "adopting new tech" date_published: 2025-10-29 date_reviewed: 2026-06-26 author: "Legionella.io editorial team (REMOTE TECH LTD)" reviewed_against: "HSE L8 and HSG274 guidance" region: "United Kingdom" license: "(c) REMOTE TECH LTD. Quote freely with attribution and a link to source_url." --- # Upgrading your programme: when to adopt new technology Most water-safety upgrades get bought back to front. A supplier demos a tidy dashboard, a neighbouring site mentions theirs, the budget line happens to exist — and the purchase order goes out before anyone has asked what decision the thing actually improves. Six months on, the sensors are firing alerts into a shared inbox nobody owns, and the paper logbook is still the record that gets pulled when an auditor visits. New technology can sharpen Legionella control. It can also bolt cost and complexity onto a programme that was already coping. The difference is rarely the kit itself. It is whether the kit earns its place. Here is a way to decide that holds up under questioning from finance, from an assessor, and from your own successor. ## Why "because it's new" is a weak reason to buy The default trigger for an upgrade is novelty: it exists, a peer has it, the demo looked good. None of those tells you anything about your site. A sensor that streams beautiful graphs nobody acts on has not improved control; it has added a maintenance task and an attack surface. A dashboard that mirrors data you already gather, without thresholds, ownership or an exception process, is a screen, not a safeguard. The useful trigger is different. Technology is worth adopting when it makes a real decision faster, more consistent, or better evidenced than the method it replaces. If you cannot name that decision, you are not ready to buy. ## The earn-its-place test Run any proposed upgrade through four questions, in this order. They get harder as you go, which is the point — most weak purchases fail on the first one. **1. Which decision does it improve?** Not "what data does it show" — which judgment does it make better. A calorifier flow-and-return sensor improves the decision "is hot water leaving hot enough, today, without someone walking the plant room". A graph emailed weekly improves nothing if the same person was already reading the gauge. **2. Does it make the evidence stronger?** A defensible record answers who did the task, when, on which asset, what the result was, whether it was in range, and what happened when it was not. L8 expects duty holders to keep records of monitoring and the management arrangements behind them [1]. If the new tool captures the tick but loses the exception, the evidence has not improved. **3. What new burden does it create?** Every device adds calibration, connectivity, false alarms, and someone to train. Honest accounting nets the burden off the benefit. A tool that saves an hour of recording but needs two hours of alert triage has gone backwards. **4. Can you get your data — and your independence — back out?** If the readings live only inside one vendor's platform and leave with the contract, you have bought a dependency, not a capability. Portability is a control question, not just a procurement one. A purchase that clears all four is worth a costed pilot. One that stalls on question one is a budget line you have just saved. ## Adopt, pilot, or wait: working it through Take the single upgrade you are closest to buying and walk it down this path. - **Does it improve a decision you actually have to make, or only display data?** - *Only displays data* → wait. Find the decision first, or you are buying a monitor for the sake of a monitor. - *Improves a real decision* → continue. - **Would its records satisfy an auditor, or a successor, with no narration from you?** - *No* → fix the evidence design before you commit. A prettier log of the wrong fields is no safer than the paper one. - *Yes* → continue. - **Is the manual method genuinely failing — missed checks, late detection, logs no one can read?** - *The manual method is coping* → log the idea and revisit it at the next risk-assessment review. Novelty alone is not a trigger. - *The manual method is failing* → continue. - **Can you pilot it on a defined subset and export your data if you walk away?** - *Locked in* → renegotiate the contract now, not after rollout. - *Portable* → pilot it, set the success measure up front, and adopt only if the pilot actually hits it. Three outcomes fall out of that: adopt where it clears every gate, pilot where it clears the first three and you need proof, and wait where the manual method is doing the job. ## Putting it against the upgrades people are weighing Remote temperature monitoring on sentinel outlets and the calorifier is the strongest case on most sites, because manual sampling of distant or awkward points is exactly where checks slip. It earns its place when the sensors are calibrated, sited at points that mean something, and wired to a named owner with an escalation route. It earns nothing if the alert lands in a generic inbox. Swapping a paper logbook for a digital one usually wins on evidence and handover. The record survives a staffing change and an audit pull, and a missed flush can be made to chase the responsible person automatically. The catch is the same as ever: the system has to capture the exception and the action taken, not just the green tick. QR-coded assets and automatic alerts are worth it only when they shorten the time between a reading drifting and a human acting on it. If an alert has no owner and no defined response, it is noise with a timestamp. ## Where the test runs out The framework tells you whether a tool deserves a place. It does not run your programme. Technology supports the duty holder, the responsible person and the competent person; it never becomes them. A dashboard is only as good as the person reading it, and HSE guidance still puts monitoring frequency in the hands of your risk assessment and HSG274, not the software's defaults [2]. New kit also brings new ways to fail. A sensor can drift out of calibration and quietly report comfort while control slips — which is why calibration is its own discipline ([Sensor calibration and maintenance: ensuring accuracy](https://legionella.io/articles/sensor-calibration-and-maintenance-ensuring-accuracy/)). Connectivity drops. A device on your network is now something to secure, not just to read ([Cybersecurity for smart water monitoring devices](https://legionella.io/articles/cybersecurity-for-smart-water-monitoring-devices/)). A word of caution that is easy to skip: none of this is product endorsement, and it is no substitute for a competent, site-specific risk assessment. New monitoring tools change how you gather evidence; they do not change the control you owe or the figures your assessment sets. Any threshold a device ships with is a number to confirm against your own written scheme, and any sampling it prompts still follows the system and the assessment rather than a fixed timetable [3]. ## Start here this week Pick the one upgrade you are most tempted by and run it through the four questions on a single side of paper. If it stalls on the first — which decision does it improve — park it until you can answer that in a sentence. The kit that survives all four has earned a small, time-boxed pilot with a success measure agreed before it goes live. The kit that does not has just told you something useful for free. ## Common questions ### Should we wait for the next risk-assessment review to change how we monitor? Not necessarily, but tie the two together. A material change to how you monitor is itself a reason to review the assessment, and the assessment is what justifies the new method. If you adopt mid-cycle, write down why and fold it into the next scheduled review [2]. ### Is a digital logbook enough on its own, or do we still need sensors? They solve different problems. A digital logbook fixes the record — legibility, completeness, handover and audit trail. Sensors shorten the gap between a temperature drifting and someone noticing. Many sites get more value from fixing the record first, then adding sensing only where manual checks are too slow or too infrequent to be safe. ### How do we prove a brand-new system to an auditor who has never seen it? Show the same chain you would for paper: who did the task, when, on which asset, the result, whether it was in range, and what happened when it was not [1]. If the system produces that on demand, the technology is incidental to the audit. If it cannot, that gap is what to close before you roll it out. ## Related reading - [Industry standards: how LCA membership helps avoid failures](https://legionella.io/articles/industry-standards-how-lca-membership-helps-avoid-failures/) - [Anticipating regulatory changes: staying ahead of the curve](https://legionella.io/articles/anticipating-regulatory-changes-staying-ahead-of-the-curve/) - [Cybersecurity for smart water monitoring devices](https://legionella.io/articles/cybersecurity-for-smart-water-monitoring-devices/) - [Sensor calibration and maintenance: ensuring accuracy](https://legionella.io/articles/sensor-calibration-and-maintenance-ensuring-accuracy/) ## Sources [1] HSE, "Legionnaires' disease. The control of legionella bacteria in water systems - Approved Code of Practice and guidance (L8)". https://www.hse.gov.uk/pubns/books/l8.htm [2] HSE, "Legionnaires' disease: Technical guidance (HSG274)". https://www.hse.gov.uk/pubns/books/hsg274.htm [3] HSE, "Testing and monitoring your water system for legionella". https://www.hse.gov.uk/legionnaires/testing-monitoring-water-system.htm