Every new Portal release restarts the same conversation: upgrade now, later, or never-until-forced? After shepherding fleets through many cycles, our answer is a checklist rather than an opinion.
Before touching anything
- Inventory the fleet: for each machine — Portal version of record, CPU firmware, HMI type, option packages (Safety, GRAPH, ProDiag), and whether the license stock covers the new version.
- Read the compatibility notes for your CPUs, not the marketing page. Older firmware stays configurable from new Portal, but option-package version coupling (especially Safety) is where surprises live.
- Confirm third-party dependencies: Openness scripts, version-control integration and library tooling are pinned per version and need their own update pass.
The rollout that never burned us
Install the new version alongside the old (they coexist cleanly), pilot on one non-critical machine end-to-end — open, upgrade project, compile, download at a planned stop, archive — and run a full production cycle before scheduling the rest. Fleet machines then upgrade opportunistically at planned maintenance, one by one, each leaving a pre-upgrade .zap behind. The old Portal version stays installed until the last machine leaves it.
Never upgrade a project during a breakdown intervention. Emergencies use the machine’s version of record; upgrades are planned work.
FAQ
Is skipping versions safe? Yes — project upgrades can jump multiple versions in one step. Skipping releases entirely is a legitimate fleet strategy; many of our customers ride every second version.
When are we forced? New CPU hardware generations and new option features eventually require current Portal — that, not the release calendar, is the honest forcing function.
Zone Otomasyon maintains version-of-record discipline for every machine under contract. Fleet software management is part of the service.