# An app update must carry yesterday's unsent jobs

Offline upgrades need compatibility across local storage, queued commands and the server. A new screen is not ready if an older submission becomes unreadable.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Inventory the data that can outlive a release

List draft records, queued commands, attachment blobs, upload receipts and conflict decisions. Record their schema versions and how long a supported device may remain disconnected. That interval determines how long old command formats can return after a server release.

A field worker may reopen the application with a week-old queue. Testing only an empty local database misses the upgrade path that matters most to them.

Keep local database migration separate from business submission migration. Renaming an object store is a storage operation. Changing what a command means requires compatibility logic and, sometimes, a user decision.

## Rehearse an upgrade with a mixed queue

Build a fixture containing a draft, a partially uploaded report, a command accepted by the server with no local receipt and a genuine conflict. Upgrade the application and verify each state independently.

For example, adding a required inspection category should not invent a category for an old report. The application can preserve the report and ask the worker for the missing information, or the server can accept a documented legacy format. The product owner must choose.

Avoid rewriting stable command IDs during migration. That would destroy the connection to a result already committed before the upgrade.

## Release server compatibility before new clients depend on it

Deploy support for the new format while retaining the required old readers. Then introduce the client gradually and watch for schema-related rejections and stalled queues.

Test service-worker and page-version combinations as part of the rollout. A tab can remain open across releases. The user should receive a controlled update path rather than a forced reload in the middle of saving an inspection.

Define rollback against migrated local data. If the old client cannot read the new database, rolling back static assets alone is not a usable recovery plan.

## Retire old formats using evidence

Use supported-version policy and observed device check-ins to identify remaining old clients. Absence of recent traffic does not prove that every offline device has upgraded.

Before removing compatibility, decide what happens when an overdue device returns. Provide an explanatory recovery screen or assisted path. A generic validation error leaves the worker with a report they can see but cannot deliver.

## Sources

- [MDN: IndexedDB](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API)