All posts
AWS Amplify

Leaving AWS Amplify and AppSync: When It Is Time, and How to Do It Without a Rewrite

By

November 2, 2026

7 min read

Amplify gets a startup to launch fast. The trouble starts later: list queries that scan, resolvers that can't throw or call out, a 30-second ceiling, and a data model that was never designed. The signs it is time to leave, what to move to, what to keep, and a cutover that doesn't log anyone out.

Amplify Exit
AWS Amplify
AppSync
Migration
Startups

Amplify does what it promises: a schema file becomes an API, tables, auth rules and a typed client in an afternoon. That is a good trade for a prototype. It becomes a bad one when the product works and the team needs reporting, complex queries, background jobs and the ability to debug a slow request. At that point Amplify's defaults are decisions nobody made on purpose.

The signs

  • List screens get slower as tables grow. Amplify's docs say the list operation uses DynamoDB scans, and DynamoDB applies the filter after reading, so a filtered page reads the whole page and can come back nearly empty.

  • Business logic is spread across resolvers that can't use try/catch, throw, async code or network calls, and every exception becomes a Lambda resolver bolted on the side.

  • Someone needs a report, a join or a count, and the answer is "export the tables".

  • A request needs more than 30 seconds and can't have it: AppSync's request execution time is a fixed quota.

  • Nobody can explain why an authorization rule lets a user see a record, because the rule lives in generated resolvers.

  • Deploys are slow and nervous, because the backend is regenerated from a schema rather than changed in small steps.

Want a second opinion on this for your system?

Book a free 30-minute call. You'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.

What to move to

Piece

Typical destination

Why

AppSync GraphQL API

Your own API: REST or GraphQL on Lambda or containers

Ordinary code, ordinary errors, tests and tracing; no runtime subset

Amplify-generated DynamoDB tables

Postgres for relational data; DynamoDB designed on purpose for the hot paths

Joins, counts and reports; access patterns chosen rather than generated

Subscriptions

AppSync Events, API Gateway WebSockets, or server-sent events

Keep real time without the GraphQL layer

Amplify Hosting

CloudFront and S3, or Vercel

Usually optional; Hosting is the part that tends to be fine

Cognito user pool

Keep it

Moving users means password resets; the new API can verify the same tokens

S3 storage

Keep it

Same buckets, accessed with presigned URLs from your API

How to cut over

  1. Stand up the new API next to AppSync, verifying the same Cognito tokens, so a signed-in user is signed in to both.

  2. Move data with a full export and a change stream: export the tables to S3, load them into the new store, then replay DynamoDB Streams until the two match.

  3. Move one screen at a time behind a flag in the client. Reads first, then writes.

  4. Keep AppSync running until the oldest supported mobile app version no longer calls it. Old app versions are the reason this takes months, not weeks.

  5. Delete the Amplify backend last, after a final export to S3.

hoolco Monthly Review

Once a month: what changed in tech that month and what it means for you, from cloud and AI to security and the tools you build with. Every item links to its source. No sales pitch, unsubscribe in one click.

As of November 2, 2026. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.