Mobile screens were waterfalling 7 to 14 REST calls each. Over-fetching everything. Under-fetching what mattered. Backend shipped a breaking change and didn’t notice mobile depended on the field. Versioning the REST API had become a monthly meeting.
Migration REST to GraphQL migration · Apollo + Hasura + Federation · UK
REST to GraphQL migration for the team waterfalling 11 calls. per page.
We move UK SaaS, mobile, and product teams off a sprawling REST surface onto a schema-first GraphQL API — per screen, per feature, on Apollo Server, Hasura, or Yoga. Persisted queries for safety, REST kept alongside through the whole transition.
4GraphQL migrations shipped since 2019
11→1REST calls per page collapsed
5-dayfixed-scope migration audit
(Why founders + CTOs migrate now)
You don’t need to leave REST. You need to leave the version of REST that’s costing you growth.
One GraphQL query per page replaces 11 REST waterfalls. Schema-first design forces the team to agree on the data shape before code, so frontend and backend stop shipping breaking changes at each other.
01
<5
0
The founder this page is for60+ endpoints · 7-14 calls/screen · 2 weeks behind
Hanna leads mobile at a UK marketplace. iOS, Android, web, one REST API.
Mobile shipped two weeks behind web every release because of the integration tax. Ten-week migration. Apollo Server plus Apollo Federation on top of the existing services. Schema-first design with frontend and backend in the room. Persisted queries from web and mobile.
REST kept available for six months as fallback. Mobile shipped same-day as web after week seven. Waterfalls gone. Breaking-change risk gone. This page is for the founder or CTO who has decided the migration is happening, and wants it to land without taking the business down.
Four phases. Each ends in a board-ready deliverable.
No mystery box. Each phase is fixed-scope, fixed-price, and ends with a written deliverable. You decide whether to continue at every phase boundary.
- 01
“We’ve decided to migrate. We don’t know what it costs or what breaks.”
Two senior engineers read your REST estate for 5 days. We map the surfaces, integrations, data shape, hidden coupling, and migration cost. Output: a 20-30 page audit pack with risk matrix, target architecture, data migration plan, rollback plan, and a fixed quote.
- 02
“How do you build the new thing without touching the running business?”
We build the GraphQL target in parallel while REST keeps running. Data migration dry-runs, integrations rebuilt, dual-write or shadow-read pattern set up so traffic routes safely. No customer-facing change yet. Output: GraphQL target environment on a prod data clone.
- 03
“The flip is the moment it all goes wrong. How do you de-risk it?”
Cutover happens in a planned window, often a weekend. We dual-run, shadow-read, then flip the canonical write path. Old system stays read-only for 60 days. Rollback is rehearsed and reversible. Output: cutover runbook plus signed-off cutover.
- 04
“What happens after the flip, and when does the old estate finally go?”
We monitor, fix what only production traffic surfaces, hand over. Decommission the old REST estate on a schedule you sign off. The old system isn’t deleted until you say it can be. Output: stabilised production, handover docs, decommission plan.
Migration risk + mitigation matrix
The four risks that sink a GraphQL migration
We don’t pretend migrations are safe. We make each risk legible and mitigated, in writing, before a single line of production code changes.
Resolver N+1 explosion
Naive resolvers re-fetch per field. We batch with DataLoader plus per-request caching. Postgres or Mongo query count stays under five per typical query.
Field-level auth + tenant pin
REST auth is per-endpoint. GraphQL auth is per-field. We model auth at the schema with directives plus tenant pin at the data layer. Cross-tenant query becomes impossible.
Arbitrary query DoS prevention
Persisted queries mean clients only run pre-registered queries. Cost analysis plus depth and complexity limits as defence in depth.
REST + GraphQL coexistence
REST stays for three to six months. Web and mobile migrate per screen, per feature. Old REST endpoints sunset on a schedule your team signs off.
The GraphQL stack we migrate you onto.
We default to Apollo Server plus MERN plus AWS. Comfortable on GCP, Azure, Cloudflare, DigitalOcean, Vercel, and Fly.io where your team has constraints or a relationship.
T1
Default GraphQL target stack
ApolloApollo ServerHasuraGraphQL YogaDataLoaderPersisted queriesApollo Federation v2CodegenNode.js / PythonReact + Apollo ClientReact Native + ApolloMixpanel + Apollo StudioCloudflare edge cache
T2
Migration-specific tooling
reach when neededStellateWunderGraphApollo RouterGraphQL MeshGraphiQL / Apollo SandboxSchema Registry
T3
Infra, observability, safety net
AWS-defaultAWSAWS LambdaAWS AppSyncRDS / DocumentDBRedisSecrets ManagerKubernetes (EKS)Datadog APMSentryCloudflare + WAFTerraformk6 / Artillery
REST to GraphQL migration · what we move
What we migrate, in order
Per screen, per feature, REST kept alongside. Five workstreams that take a sprawling REST surface to a schema-first GraphQL API.
7-141
Calls per screen, after
60+
REST endpoints unified
“Mobile shipped same-day as web after week seven. The waterfalls were gone. So was the breaking-change risk.”
001
Schema-first design
We design the SDL with frontend and backend in the room before code. Generated resolvers come from the schema, not the other way around.
002
DataLoader batching
DataLoader plus per-request caching at the resolver layer. Postgres or Mongo query count stays under five per typical client query, measured not assumed.
003
Apollo Federation
Run multiple services? Apollo Federation v2 with subgraphs. We avoid legacy schema stitching. Subgraph ownership plus composition managed in the gateway.
004
Persisted queries + auth
Clients only run pre-registered queries. Directive-based auth at the schema, tenant pin at the data layer. Cross-tenant query becomes architecturally impossible.
005
Cutover + coexistence
Web and mobile migrate per screen. REST kept alongside for six months as fallback. Old endpoints sunset on a schedule your team signs off.
What teams say after cutover
From the mobile leads, founders, and CTOs who left REST waterfalls behind.
100%
would refer us
Mobile shipped same-day as web after week seven. The waterfalls were gone. So was the breaking-change risk.
Real questions we get on the audit call
Direct answers, no marketing varnish.
Apollo for the richest ecosystem plus Federation when you run multiple services. Hasura when most of your data is in Postgres and you want auto-generated CRUD. Yoga when you want minimal and flexible. We’ll recommend at the audit, with the trade-offs written down. Most REST to GraphQL migrations we ship land on Apollo Server.
No. We migrate per screen, per feature, and REST coexists for as long as you need. Old endpoints sunset on a schedule when no client uses them. Most clients keep some REST around for webhooks and third-party callbacks long after the rest of the surface has moved.
Persisted queries by default, so clients can only run pre-registered queries. On top of that, query cost analysis, a depth limit, a complexity limit, and per-user rate limits by cost as defence in depth. Arbitrary-query DoS becomes architecturally hard, not just policed.
Directive-based auth at the schema, tenant pin at the data layer, field-level authz where you need it. By the time we ship, a cross-tenant query is architecturally impossible. We port your existing auth, rate limiting, and observability across as part of the REST to GraphQL migration, not as a follow-on project.
No, and anyone who says it does hasn’t run one in production. DataLoader plus per-request caching at the resolver layer, plus careful schema design. We typically end up under five DB queries per typical client query post-cutover, measured, not assumed.
30-day walk-away both ways. Milestone billing 25/25/25/25. UK VAT registered, listed on Companies House, shipping since 2019. The audit is a standalone £8K deliverable you own whether or not you continue, so you’re never more than four weeks at risk of paying for nothing.
Every migration has two senior engineers paired, not one. Every decision goes into an ADR the same day. Mohit reviews every PR. If one engineer leaves, the other has full context the next morning. In seven years, two engineers have left mid-project. Both handovers were inside 48 hours.
Yes, with 14 days’ notice. Because REST stays live alongside the new GraphQL surface, pausing doesn’t leave you stranded mid-cutover. Engineers move to other projects, spend pauses, and you resume with 14 days’ notice. No cancellation fee, no restart fee.
In context
What it looks like shipped.
rest to graphql migration, in context — the dashboards, flows and components your team actually ships, reviews and maintains.
Five lines. That’s it.
Tell us your current REST estate (traffic, data size, integrations), why you want to migrate, and the deadline you’re working to. Mohit replies inside 24 hours with availability and the next 5-day audit slot.
What happens after the email lands
- < 24h
A personal reply.
Yes, no, or the deciding question. Straight to your inbox.
- Week 1
Audit week begins.
Risk matrix, target architecture, data migration plan, fixed quote.
- Cutover
Lands without the outage.
Planned window, rehearsed rollback, REST read-only for 60 days.