Moves
- the gateway
- the schema registry
- CI checks
- observability wiring
Open source, running in your cloud, built on GraphQL Hive by The Guild. The same schema, the same checks and the same audit trail for humans, apps and agents.
Talk to an engineer| Stage | What moves |
|---|---|
| Registry first | Registry first when your pain is schema governance, breaking changes, or contract sprawl - lowest risk, no traffic moves. |
| Gateway first | Gateway first when your pain is cost, performance, or self-hosting - bigger win, needs a traffic plan. |
Most teams go registry first.
Every stage is reversible. Traffic shifts behind your own flags. Both gateways can run in parallel during cutover.
Weeks 11–12: your engineers run a migration step themselves with ours watching. You leave able to operate it.
| Weeks | Stage | What moves |
|---|---|---|
| 1–2 | Graph audit | Inventory of subgraphs, consumers, breaking-change risk, agent surface. Nothing changes in production. |
| 3–4 | Registry and checks | Hive schema registry live, checks wired into CI. Still no traffic moved. |
| 5–10 | Gateway migration | Subgraph by subgraph, behind your flags, with rollback at every step. |
| 11–12 | Agents and handover | MCP skills declared and governed. Your team certified to run it without us. |
Scope agreed before anything moves, with published exit criteria. Commercial terms are direct with The Guild.
Incrementally. The registry and the gateway are separable concerns, so most teams move one first and run both side by side. Subgraphs themselves generally need no rewrite - they are spec-compliant either way.
In the normal case, no. The work sits at the gateway and registry layer.
One call, an engineer on it, and a straight answer about whether this is worth doing for you.