The upgrade with no rolling path
Hazelcast IMDG 3.x to Platform 5 has no rolling upgrade path. For a cluster holding live session or cache state, that makes the upgrade an availability problem, not just a version problem.
Challenge
Without a rolling upgrade, the cluster has to be taken down and brought back on the new version -- which means either planned downtime or a parallel-cluster cutover with state migration, for a component that is usually holding exactly the state you can't lose.
Environment
Hazelcast IMDG 3.x holding session, cache or compute state in production, past community support.
Approach
OSSeva patches the IMDG 3.x line so the cluster is covered, and designs the Platform 5 cutover around the state it holds rather than assuming a restart is acceptable.
What this delivers
A supported IMDG cluster today, and a Platform 5 migration designed around the availability requirement instead of against it.