Backward-compatible deployment
Shipping so the new version and the old version can run side by side without either one choking on the other's data.
See it
What it is
Most deployments have to tolerate two versions of your app being live at once. A rolling deploy swaps instances one by one, browsers hold a cached JS bundle from ten minutes ago, mobile users sit on last month's build for weeks, and queued jobs were serialized by code you already replaced. An atomic single-server swap genuinely has no server-side overlap, and then the stale clients get you anyway. A backward-compatible deployment is one where the new code happily reads data the old code wrote, and the old code survives everything the new code writes.
The standard move is expand and contract: add the new column as nullable, write to both old and new, backfill, flip reads to the new one, and only in a later release drop the old column. Same rule for APIs: add fields, never rename or remove them in the release that starts depending on the replacement. Renaming is just a delete plus an add wearing a disguise.
The half people forget is the other direction: old code must tolerate shapes it has never seen. If your client throws on an unknown JSON key or an unrecognized enum value, every new field you ship becomes a breaking change for anyone who hasn't reloaded yet. Ignore unknowns, and keep a default branch on every switch.
Ask AI for it
Rewrite this change as a backward-compatible, expand-and-contract release, assuming old and new code run at the same time for at least 24 hours. Phase 1: additive-only migration (new nullable columns, no renames, no drops) plus dual writes to old and new fields. Phase 2: backfill script, then switch reads to the new field behind a feature flag. Phase 3: a separate later PR that removes the old column and the dual write. Make all API responses additive, make the client ignore unknown fields and unknown enum values instead of throwing, and list which phase can be rolled back safely and which cannot.