Legacy tf.keras via tf_keras+TF_USE_LEGACY_KERAS vs. Migrating to Keras 3 for Model Loading Compatibility

When upgrading a TensorFlow environment from 2.15 to 2.16 or later, the default Keras implementation shifts from the in‑tree Keras 2 (tf.keras) to standalone Keras 3. This change affects how existing SavedModel and HDF5 files are deserialized, especially those that rely on custom objects or legacy preprocessing layers. The goal is to decide whether to preserve the original Keras 2 behavior by installing the tf_keras package and setting TF_USE_LEGACY_KERAS=1, or to migrate the codebase and re‑save artifacts to the native Keras 3 format, accepting the need for retraining and serving parity tests.

What are the practical trade‑offs between pinning the legacy path and migrating to Keras 3 regarding model fidelity, engineering effort, and future support? Which verification strategy can confirm bitwise parity for H5 models with custom layers under each option? What long‑term maintenance implications arise from continuing to rely on the tf_keras escape hatch versus adopting Keras 3?