Answer
IFS's own official guidance recommends no user activity on the system at all while applying a release, which is the core reason a true zero-downtime rolling-update approach is risky rather than officially supported. Several specific concerns apply: batch queues are meant to be disabled across ALL nodes during an update, not just the node being updated; a full backup of IFS Home typically requires the environment being fully shut down for a clean, consistent backup; a clustered release requires signing certificates before generating the cluster deployment zip files, which could create a mismatch for nodes still actively running during that process; and standalone components like Print Agents, Crystal Reports, and Demand Planner can also be affected by a release in ways that aren't necessarily safe to apply while other nodes remain live and serving users. The overall conclusion: attempting a genuinely zero-downtime rolling update this way isn't an officially IFS-supported procedure, and doing so exposes you to unknown failure states that IFS support may not be well-positioned to help recover from if something goes wrong mid-rollout.