How does @override(from:) move field ownership between subgraphs safely?

## What the directive changes Ownership of a field is normally implied: whichever subgraph declares it resolves it, and a second declaration is a composition failure. That rule makes moving a field between services awkward, because the two states you want — old subgraph resolves it, new subgraph resolves it — are separated by a moment where both declare it. `@override` legalises that moment and gives it a direction: ```graphql # Reservations subgraph — taking over the field type Locker @key(fields: "id") { id: ID! activeHolds: Int! @override(from: "Lockers") } ``` Composition reads this as: `Locker.activeHolds` is now resolved by Reservations; the declaration still present in the Lockers subgraph is superseded and will not be used. The supergraph records the new routing, and every router that picks up that supergraph plans the field to the new subgraph. The `from` argument is the subgraph's **registered name** in the composition — the name it was published under, not its URL, service name in an orchestrator, or repository. Get it wrong and you have written a directive that overrides nothing. ## Why it is a sequence, not a switch The safe migration has four steps, and the ordering is the answer an interviewer is listening for. 1. **Implement in the new subgraph, with the directive.** The receiving subgraph must be able to resolve the field for real — including any data access it did not previously need — before the supergraph is composed. Deploy it and let it run; nothing routes to the field yet. 2. **Compose and publish.** This is the moment traffic moves. It is a supergraph change, not a service deploy, so it is reversible by publishing the previous supergraph — which is only true while step 4 has not happened. 3. **Verify.** Compare per-field latency and error rate against the old implementation, and compare values if you can. The old subgraph is still capable of serving the field, which is exactly what makes a rollback cheap. 4. **Remove the field from the old subgraph, later.** Only after routers have all picked up the new supergraph and you are satisfied. Doing this in the same change as step 2 throws away the rollback and creates a window where a router still on the previous supergraph plans a field to a subgraph that no longer has it. That last point is the one people miss. Routers pick up a published supergraph asynchronously; during the rollout, old and new plans coexist. Both implementations must be live across that window. ## Ramping instead of switching Switching a field in one step is fine when the new implementation is cheap and well understood. It is uncomfortable when the field sits on a hot path with a tight budget — if a graph is holding a 340 ms p99 and the field's new implementation crosses a service boundary the old one did not, you would rather find that out on a slice of traffic than on all of it. Newer Federation versions support progressive override: a `label` argument alongside `from` lets the router send a share of requests to the new implementation and the rest to the old one, so you can ramp and watch. Check what your composition and router versions support before designing a plan around it, and remember that while a field is split across two implementations, both must return values a client cannot tell apart. ## Scope and limits `@override` names one field. It does not move a type, a key, or a set of fields; a type migration is a list of field migrations, which is tedious but keeps each step reversible. It is also worth being clear about what it is *not*: it is not `@shareable`. Shareable means both subgraphs resolve the field, indefinitely and interchangeably. Override means exactly one does, and states which — it is a transition, and the end state of a healthy override is a deleted declaration in the old subgraph. Leaving overrides in the schema for years is a smell: it means step 4 never happened, and every reader now has to trace an ownership decision through two repositories. ## The organisational half Moving a field is rarely only a technical change. The team gaining the field gains the pager for it, the data access behind it, and the schema-design argument the next time it changes. Sequence the human side too: agree the handover before the directive lands, and make step 4 a scheduled piece of work with an owner, because a migration that stalls at step 3 leaves two teams half-responsible for one field — which is worse than either team owning it outright.