3e. Moving a company's data to where it should live

A company made before 2026-09-28 has no recorded residency, and its database and bucket are wherever Cloudflare put them — very likely North America. Every company made since records eu and is created in the EU jurisdiction (the full analysis, S10). An old one stays where it is until moved, deliberately: placing its next deploy without moving it would create an empty EU bucket beside its media.

Operator-run, in a window the customer has agreed — the application is down from the moment its database is replaced until it is redeployed:

divvent residency move <modelDir> --tenant <slug> --via staging --to eu          # says what it would do; moves nothing
divvent residency move <modelDir> --tenant <slug> --via staging --to eu --yes    # moves this application
divvent tenant redeploy <slug> --env staging --reason "residency move"           # at once, so it binds the new database

<modelDir> must be the revision production runs; a database behind or ahead of it is refused before anything is touched. The move stages <name>-moving in the EU (migrated, loaded, compared row for row; every object copied with its type and read back), removes the original only then, re-creates <name> from the staged copy and compares again. A run that dies partway is run again and finishes from the staged copy. Take a divvent dump first anyway.

On the company's last application, add --record: the company is then recorded as eu, and every deploy after places what it makes there. Not before: a deploy of an application not yet moved would place a new, empty bucket.

---