Does Cloudflare Workers rollback reconcile Durable Object state after schema changes?

When a Workers deployment is rolled back to a prior version via the dashboard or API, the edge code package swaps atomically and propagates within roughly one minute. However, KV namespace bindings and Durable Object class definitions are not versioned alongside the code; rolling back restores the previous binding references but leaves existing KV data and Durable Object state untouched.

If a newer deployment wrote KV entries or serialized Durable Object state under a schema that is not backward compatible, the reverted code may encounter deserialization failures or read mismatches. The platform provides no automated migration tooling to transform stored state back to the older schema during rollback, so operators must plan manual migrations or maintain forward compatibility across releases.

Which strategies have proven reliable for detecting schema incompatibility before a rollback executes? What patterns allow Durable Object state to be migrated safely without downtime when a rollback is required? Does the platform expose any hooks or APIs that could automate backward state reconciliation in future releases?