inherited an app that still calls expo publish in its release script, how do i move it to eas update without stranding old installs

Safe order that has worked twice for me. Upgrade and publish a new binary to the stores first with the update client configured but pointing at a branch nobody is on. Wait until adoption of that binary is meaningful, a week or two. Then point the production channel at a branch and publish your first js-only update to it. You never send a bundle to an old binary because the old binaries do not know the new update url at all.

The whole safety question comes down to one field, runtimeVersion. Classic publishing keyed updates loosely to the sdk version, and the replacement makes you declare explicitly which native binaries a given js bundle is compatible with, so a bundle only reaches installs whose runtime matches. Set it before you publish anything, not after, because a mismatched update is exactly the scenario you described and it looks like a white screen to the user.

Worth asking whether you want over the air updates at all on an app this size. Four thousand users and one maintainer is exactly the profile where a bad bundle at 11pm is unrecoverable without a store release anyway. I run store releases only on two of my apps now and the reduction in moving parts was worth more than the speed.

Do not skip the channel and branch distinction because it reads like jargon. Channel is the thing baked into the binary at build time, branch is what you publish to, and the mapping between them is what you change when you want to promote or roll back. Once that clicked for me the rollback story became trivial instead of terrifying.

Whatever you decide, put the runtimeVersion into your release checklist as a line someone ticks. Every one of these incidents I have seen came from a native change shipping under an unchanged runtime version.