An offline-first app has users who have not opened it in eight months. You need to change the local schema. How?

What the interviewer is testing

Whether you have thought about migration across a fleet of clients whose versions you do not control.

The problem

A device offline for eight months may be several application versions behind, holding local data in an old schema and unsynchronised local changes that must not be lost. When it finally opens, it must migrate its local data and reconcile changes made against a schema that has since changed on the server.

The design

Sequential, idempotent local migrations. Each version ships a migration from the immediately previous schema, and the app applies every migration in order from whatever version it finds. Never assume the device is one version behind.

Test the full chain, not just the latest step. A device on version 4 upgrading to version 12 executes eight migrations in sequence, and an incompatibility anywhere in that chain corrupts local data — including the unsynchronised changes.

Migrate before sync. Local data must be brought to the current schema before reconciliation begins, or the sync logic is operating on a shape it does not understand.

Preserve unsynchronised changes across migration. They are the irreplaceable part — server data can always be re-fetched, local unsent changes cannot. Migrate the queue of pending operations as carefully as the data itself.

Server-side compatibility with old sync protocol versions, since the device may need to sync before it can update the app — particularly if the update is large and the connection is poor.

The escape hatch

A forced re-sync path: if migration fails or the version gap exceeds what is supported, the app can discard local state and re-download from the server — after safely extracting and uploading any pending changes. This must exist, because some migration chain will eventually fail on a device you cannot debug.

What a strong answer adds

Building forced upgrade capability before it is needed: a version check that can block a client too old to be supported, with a clear message. Without it, supporting an unbounded set of historical versions is an obligation with no end.

Common weak answers

Assuming devices are at most one version behind. Wiping local data on schema change, which loses unsynchronised work.