PRA Site Upgrades - Client Updates

Hi All,

We’re relatively new to BeyondTrust PRA and are deploying multiple on‑prem PRA systems (one large Atlas system plus several HA systems for data‑residency). As we plan appliance upgrades (e.g. 24.2.3 → 24.3.3), we have concerns around remote access disruption and network impact, particularly related to Jumpoints.

Environment

• 24x7 OT environments
• 100+ Jumpoints (growing significantly)
• Jumpoints used as Jump Zone proxies aligned to Purdue/network segmentation
  • JumpItems - primarily JumpClients and RDP.
• Remote sites connect via low‑bandwidth, often congested satellite links

Key Concerns

• Jumpoints are not backward compatible
  • Remote access is unavailable until Jumpoints are upgraded to match the appliance version.
• Upgrade size & network impact
  • ​​​​​​​Latest guidance suggests Jumpoint upgrades are full installers (~130 MB), creating risk of network congestion at scale.
• Lack of upgrade controls for Jumpoints
  • ​​​​​​​No way to defer/disable auto‑updates, limit concurrency, throttle bandwidth, or prioritise upgrades (unlike Jump Clients).
• Limited benefit from Jump Zone Proxy clustering
  • ​​​​​​​Only available from 24.3.x and doesn’t appear to significantly reduce upgrade disruption.

Questions

Are others operating PRA in large, distributed, or low‑bandwidth environments facing similar constraints?
How do you:

• Stage or control Jumpoint upgrades?
• Minimise remote access downtime?
• Prevent large, uncontrolled network spikes during upgrades?

We have an active support case and feature request open, but would really value practical, real‑world approaches from the community.

Thanks!