Which upgrade path preserves state for a small Erlang app during zero‑downtime migration?

Goal

Upgrade a lightweight OTP application in a production cluster while keeping all nodes online.

Constraints

Stateful gen_server modules must survive the code change, dependencies must be pinned to avoid mismatched BEAM images, and the upgrade path must be reproducible.

Unresolved Decision

OTP’s release_handler offers a standard --upgrade workflow but its default strategy may leave stale modules in memory and relies on code_change/3 callbacks. A hand‑crafted deployment script can explicitly purge and load new modules, but adds complexity and requires manual coordination.

Questions

• Which approach—release_handler’s built‑in upgrade or a custom script—provides stronger guarantees for preserving in‑memory state across gen_server restarts?
• What additional safeguards (e.g., module pinning, state migration hooks) are necessary when using the custom script to avoid lingering old modules?
• Can a hybrid strategy that triggers release_handler but injects a custom code_change/3 callback improve reliability?