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

Direct answer

No. Rolling back a Cloudflare Worker to a previous deployment version swaps the edge code package and restores the binding configuration that existed at that time, but it does not inspect, transform, or reconcile the serialized state stored inside Durable Objects. Any state written under a newer schema remains exactly as it was written. If the older code cannot deserialize that state, requests routed to those objects will fail.

What rollback actually changes

A rollback is a code-and-configuration operation. The platform atomically replaces the active script and its associated bindings—such as KV namespace names, Durable Object class names, and environment variables—with the values captured in the target deployment. The underlying data planes are untouched: KV keys retain their current values, and Durable Object storage (whether the legacy key-value storage or the newer SQLite-backed storage) keeps its existing rows or entries. There is no transactional coupling between the code version and the state version.

Why schema drift breaks reverted code

Durable Object state is opaque to the platform. It is simply a blob (or a set of SQLite rows) that your Worker code reads and writes. If a newer deployment introduced a required field, changed a serialization format, or altered a SQLite table shape, the older Worker script may encounter a deserialization exception, a missing column, or a type mismatch when it loads the object. Because rollback does not run migrations, the schema mismatch persists until an operator intervenes.

Detecting incompatibility before rollback

• Embed a schema version in every object. Store a version field (or a dedicated SQLite metadata table) alongside application data. On load, compare it against the version the current code expects. If the stored version is newer, fail fast or enter a compatibility path rather than throwing an opaque parse error.
• Run a shadow probe. Before initiating a rollback, use a separate Worker or a tail session to instantiate a test Durable Object ID that mirrors a production object's state shape. Attempt to read and deserialize it with the older code bundle. This surfaces parse failures without touching live traffic.
• Canary the rollback. If your routing layer supports it, send a small percentage of traffic to the rolled-back version and watch for errors with wrangler tail. Roll forward immediately if deserialization errors appear.

Migrating state safely without downtime

Because the platform offers no automatic reconciliation, the safe pattern is to make the newer schema forward-compatible so that a rollback is survivable, or to perform a manual state migration before rolling back.

• Additive-only changes. Prefer appending new fields or tables over removing or repurposing old ones. Older code can ignore unknown fields; newer code can default missing ones.
• Dual-write and backfill. During a deployment, write both the old and new representations. Once the new format is verified, backfill historical objects lazily on first access. A rollback then finds the old representation still present.
• Versioned storage keys. For key-value style Durable Objects, prefix keys with a schema version (e.g., v2:user:123). The older code reads v1: keys and ignores the rest, avoiding format conflicts entirely.
• Migration queue. If a breaking change is unavoidable, drain objects through a migration Worker that transforms state to the target schema before the rollback cutover. Use Durable Object alarms or queues to process objects in batches.

Platform hooks and future automation

As of the current Workers platform, there is no documented hook, lifecycle event, or API that triggers user code during a rollback to transform Durable Object state. Rollback is treated purely as a deployment-level operation. Cloudflare could introduce migration hooks in the future, but operators should not design around that possibility. Treat rollback as a code-only action and keep state compatibility as an application-level responsibility.

One diagnostic detail would change the tactics: are your Durable Objects using the legacy key-value storage API or the newer SQLite-backed storage? SQLite-backed objects allow transactional table migrations inside the object, while legacy storage requires careful blob-format versioning. If you can share which storage backend you are on, the migration pattern can be narrowed further.