What to do with end-of-life location systems
How to Integrate RTLS Personnel and Asset Tracking Without Disrupting Operations
Replacing a location tracking system in a secure facility is never a simple hardware swap. In correctional facilities, forensic hospitals, behavioral health centers, and critical infrastructure sites, the stakes of getting it wrong can be costly. A coverage gap during migration is a potential safety failure. An alert that fires late or not at all can put a correctional officer, a nurse, or a vulnerable patient at risk.
Done poorly, a system transition creates blind spots, breaks the emergency workflows that staff depend on, and erodes the institutional trust that takes years to build. Done well, it’s an opportunity to extend the value out of previously installed systems and even move from reactive incident response to real-time situational awareness, building a location platform that actually fits the complexity of the environment.
This guide walks through the full process: assessing your current legacy system, planning an integration or upgrade, and migrating in phases without compromising the safety of the people your facility is responsible for. If you’re evaluating modern RTLS solutions for complex architecture and have an old system already installed, this is where to start.
What “End of Life” Really Looks Like in a Secure Facility
End-of-life doesn’t always mean the system has stopped working. In most cases, it means the system still functions in part but either lacks the necessary support for a critical safety layer, or no longer supports the way operations actually run.
RTLS tags and especially anchors or locators can be prohibitively expensive to replace, but leaving in situ without a supported firmware path is not an option. The software is stranded on an obsolete operating system, which means patches stop coming and security exposure grows. Reports have to be exported manually. And somewhere along the way, command staff have quietly stopped trusting the alerts — so when a duress alarm fires, the first instinct is to verify it rather than respond to it.
That last problem is the most dangerous one. A system that people don’t trust is worse than no system at all, because it creates a false sense of coverage.
The Bosch Security Escort system is the most prominent current example of this dynamic. For nearly two decades, Security Escort was a trusted staff duress and personnel location platform in corrections and behavioral health. Bosch announced its end-of-life in 2022, with full discontinuation of support scheduled for December 2026. Many facilities are still running it today — some because budget cycles haven’t aligned, some because a full rip-and-replace feels operationally disruptive, and some because they’re waiting for clarity on what a migration actually involves.
For Security Escort installations specifically, there is a bridging option worth knowing about. Actall’s HubSens 5.0 is a Linux-based software appliance that serves as a drop-in replacement for the original Security Escort interface — which was built on Windows 8 and Windows Server 2012, both long out of Microsoft support. HubSens 5.0 supports the existing Bosch field hardware, meaning facilities can modernize the software layer and extend the operational life of their current infrastructure without an immediate full replacement. For facilities caught between budget cycles and the December 2026 deadline, it provides a realistic path forward.
Beyond Security Escort, the general pattern of EOL erosion shows up the same way regardless of platform:
| EOL Symptom | Safety or Operational Risk |
|---|---|
| Unsupported tags or transponders | Higher failure rates, no spare parts pipeline |
| Software on obsolete OS | No security patches, growing compliance exposure |
| Poor location accuracy | Delayed response to duress events, low staff trust |
| No integration with access control or incident management | Location data siloed, not actionable |
| Limited reporting | Weak audit trails, compliance gaps |
First Decision: Retire, Replace, Integrate, or Hybrid?
Before you engage a vendor, decide what role the current system should play going forward. There are four realistic options, and the right one depends on the state of your hardware, your data reliability, and your operational timeline.
Retire when the system no longer supports the critical safety workflows needed or the operational requirements have changed, retiring the system may be a sensible strategy.
Replace when the hardware layer can’t meet current requirements. This includes transponders with insufficient battery life, anchor networks with coverage gaps in high-risk areas, or conflicts with other wireless systems. If your architecture has changed significantly since the original deployment — new wings, additional floors, secure perimeters that have shifted, full or partial replacement could be a logical path.
Integrate when the location data is still possible from the hardware, but is isolated from existing systems and processes. Many legacy systems can accurately locate a staff member or asset, but can’t pass that event to a control room dashboard, an access control system, or an incident record. In that case, integration can extend the useful life of what you have without replacing every device. In some instances, updating the software layer may actually improve performance from legacy hardware with more up-to-date or advanced location algorithms.
Hybrid when different zones or populations require different technology approaches, or only partial coverage has been achieved with a legacy system, a correctional facility might use a hybrid approach. Finding a software solution that enables integration of multiple location systems, including legacy or end-of-life systems, provides a way of extending value without unnecessary cost.
| Decision | Best Fit |
|---|---|
| Retire | It no longer supports emergency workflows or operational requirements have fundamentally changed |
| Replace | Coverage, accuracy, or hardware support can’t meet current safety requirements |
| Integrate | Location data is possible and reliable from existing hardware, but not connected to control room or incident systems |
| Hybrid | Different areas or populations require different tracking approaches, or only partial coverage exists with legacy technology |
Audit the Current Environment Before Anything Else
This step isn’t glamorous, but skipping it is where migrations go wrong. Before committing to a path, document what you actually have (not what the system was supposed to do when it was installed).
Start with the physical layer. Walk the facility. Count transponders, anchors, receivers, gateways, and spare devices. Note firmware versions, battery performance, power sources, network dependencies, cabling routes, and — critically — areas with known coverage gaps. In complex architecture, coverage gaps are rarely evenly distributed. They tend to cluster in exactly the places you most need visibility: stairwells, transition corridors, interview rooms, isolation units.
Then move to the software layer. List licenses, operating system dependencies, dashboards, alert configurations, reports, integrations, and user roles. Who has access to what? Who depends on which report, and how often? Which alerts are acted on, and which ones get acknowledged without a response because they’re known to be unreliable?
Map what’s being tracked. In a correctional facility, that typically means correctional officers and other staff carrying duress devices, potentially with inmate location tracking as a separate function. In a behavioral health or forensic hospital setting, it may mean clinical staff, security personnel, and patient wander prevention. In a federal building or critical infrastructure site, it might mean access-credentialed personnel, contractors, and high-value assets like medical equipment, key management systems, or controlled devices. Each population has different movement patterns and different consequences when location data fails.
Also document where the data goes today. Does a duress alert reach the control room within seconds? Does it show location on a floor plan? Does it log to an incident record? Or does the system generate an alarm that a radio operator has to interpret and manually relay? The gap between what the system technically produces and what actually happens operationally is usually where the biggest risks sit.
Finally, define accuracy requirements by area. Not every space needs the same precision. A large outdoor yard may only need zone-level location. A housing unit corridor may need room-level accuracy. A high-observation psychiatric unit may need sub-room precision with reliable man-down detection. Design your requirements around the specific risk profile of each area, not a single facility-wide standard.
Design Integration Around Operations, Not Just Hardware
Good RTLS integration in a secure facility starts with operational workflows, not with tags or anchors. Hardware captures location then sound integration turns that location into an actionable response.
Start by defining which systems need to receive location data. In corrections and behavioral health settings, the most common integration targets are: physical access control systems, control room command platforms, incident management and reporting tools, nurse call or staff assist systems, and compliance and audit reporting. The goal is to make location data visible inside the systems that already drive decisions.
From there, define the events that matter operationally. Raw coordinates are useful to a computer, not to a correctional officer or a charge nurse. What those roles need are events with clear meaning: staff member activated duress, staff member has been stationary for more than X minutes, staff member has exited authorized zone, asset removed from secure area, person entered restricted space without escort. Events like these are what close the loop between location intelligence and human action.
Identifier mapping is one of the most underestimated parts of any integration. The tag or transponder ID, the personnel record, the badge number, the shift assignment, and the control room display all need to refer unambiguously to the same person. In a facility where misidentifying a staff member during a duress event could mean the wrong person gets responded to is a critical safety requirement.
Some applications also benefit from condition data alongside location. Man-down detection, lack-of-motion alerts, and device tamper detection are all condition-based events that pair with location to give responders a clearer picture of what they’re walking into.
Build a Migration Plan That Protects Operations During Cutover
In a 24/7 secure facility, there is no maintenance window where safety can be briefly paused. Migration has to be designed around that reality from the beginning.
The safest approach starts with a contained pilot and expands in phases. Choose a pilot area where the problem is visible and where you can measure results without putting the whole facility at risk. A single housing unit, a clinical wing, or a specific staff population are all reasonable starting points. The pilot area should be important enough to generate meaningful data, but bounded enough that issues can be identified and corrected before they propagate.
Run the legacy and new systems in parallel long enough to compare results in real conditions. Verify that duress alerts fire correctly. Check that location updates are fast enough to be useful to a responding officer. Confirm that coverage extends into the corners and transition spaces where incidents are most likely to happen. If the old system and the new system disagree on where someone is, investigate before you scale.
Transponder replacement should be phased by risk level and operational access. Start with the staff populations that are hardest to cover with the current system, or where coverage failures have caused problems in the past. Work around shift schedules and operational rhythms — in corrections especially, the right time to touch hardware is determined by what’s happening in the facility that day, not by the project timeline.
Don’t decommission control room displays, alert workflows, or legacy reporting until the new integrations are fully validated. Someone on the night shift is probably depending on a report or an alert configuration that was set up years ago and never formally documented. Confirm that everything that’s being replaced is actually replaced — not just technically substituted — before you turn the old system off.
A solid cutover plan includes pilot success criteria, parallel operation period, rollback procedures, staff training, control room familiarization, and a structured post-go-live review. In facilities where staff turnover means new employees may be using the system within days of go-live, training can’t be an afterthought.
The Use Cases That Matter Most
Locating a staff member who has activated a duress alarm is the core use case for RTLS in secure environments, but it’s not the only one, and facilities that treat it as the only one tend to underinvest in capabilities that have significant operational and safety value.
Response time to duress events is the most direct measure of system value. When a correctional officer or clinical staff member activates an alarm, how quickly does a responder reach them? That time is a function of location accuracy, alert delivery speed, and how well the system integrates with the communication tools responders are already using. Improving it is the clearest ROI case for RTLS in this sector.
Personnel accountability and post-incident reconstruction are closely related. Accurate, time-stamped location data creates an audit trail that supports incident reviews, grievance responses, use-of-force documentation, and accreditation reporting. Facilities that have experienced litigation around incidents often discover too late that their legacy system’s logs were either incomplete or inadmissible.
Wander prevention and patient safety in behavioral health and forensic hospital settings add a patient-facing dimension. Knowing when a patient has moved outside an authorized area — and being able to verify that within seconds — reduces both safety incidents and the staff burden of manual monitoring.
Asset accountability matters in environments where controlled items represent security risks. Key management systems, medical equipment in secure treatment areas, and portable devices all benefit from location tracking that integrates with access control and inventory systems. An alert when a controlled asset leaves an authorized zone is a much faster response than a manual inventory count at shift change.
Staffing pattern analysis is an underused application. Anonymized location data over time can reveal whether patrol coverage is consistent, whether response protocols are being followed, and whether staffing levels in specific areas match the actual movement demands of the shift. This is valuable both for operational improvement and for accreditation documentation.
Strong use cases in this sector generally connect to one of four outcomes: faster emergency response, stronger accountability documentation, reduced safety incidents, or improved compliance posture. If a proposed integration can’t be tied to at least one of those, it’s worth reconsidering the priority.
What to Look for in a Vendor
The platform you evaluate should handle what you need today and have a credible path for what you’ll need in five to ten years. For secure environments, that means: proven accuracy in complex RF environments, support for duress alerting and man-down detection, integration with physical access control and incident management systems, robust audit logging, and a hardware roadmap that doesn’t leave you stranded.
Specific questions worth asking before you commit:
- Can I still use existing transponders, anchors, and gateways without an expensive and time-consuming rip-and-replace?
- How does the system perform in reinforced concrete construction with significant RF attenuation?
- Can location data be integrated with our access control and incident management platforms?
- What does the alert delivery path look like from activation to control room notification, and what is the typical latency?
- Can data be exported if we need to change platforms in the future?
- How are firmware updates managed and deployed in a way that doesn’t require facility downtime?
- Does the vendor have direct experience with correctional, forensic, or behavioral health environments?
- What migration support is available for facilities coming from legacy platforms like Bosch Security Escort?
That last question matters more than it might seem. A vendor who understands what a Security Escort installation looks like — its field hardware, its alert logic, its control room integration patterns — will deliver a migration that’s faster, less disruptive, and more likely to preserve institutional knowledge than a vendor who’s treating it as a generic RTLS replacement project.
Measuring Success
Baseline measurement should begin before the migration starts. Capture current response times to duress events, known coverage gaps, alert reliability rates, and the volume of manual workarounds staff use to compensate for system limitations. Without that baseline, you can’t demonstrate improvement — and in this sector, demonstrating improvement is often required for budget justification, accreditation, and regulatory compliance.
During and after deployment, track reductions in response time to duress events, improvements in location accuracy across the facility, and the reliability of alert delivery. Track system health separately: transponder battery status, anchor coverage, data latency, missed events, and integration uptime. A location system can only protect people if the underlying infrastructure is functioning reliably.
Also track adoption. In secure facilities, staff acceptance of a new system isn’t automatic. If officers or clinical staff stop wearing transponders, or start ignoring alerts because they don’t trust them, the system’s technical performance becomes irrelevant. Building that trust requires accuracy, reliability, and a control room experience that makes the data easy to act on — not just technically present.
Before scaling beyond the pilot area, compare results against the legacy baseline. If accuracy, response time, and alert reliability meet the defined acceptance criteria, expand. If not, fix the design before adding more of the facility to the system.
Final Thought
RTLS in a correctional facility, forensic hospital, or behavioral health setting isn’t an IT project with a location layer. It’s a life-safety system that happens to run on technology. The standard for getting it right is different, and so is the cost of getting it wrong.
The best outcomes come from a clear audit of the current environment, a migration strategy built around operational continuity rather than project timelines, and a technology partner who understands the specific constraints of complex architecture.
If your current platform is approaching end of life — or if you’re running on Bosch Security Escort hardware and weighing your options before the December 2026 support cutoff — Actall has worked with facilities in exactly that position. Explore Actall’s products and solutions to see what a path forward looks like.