Migrate a Subgraph from The Graph

Migrating an existing subgraph from The Graph to Goldsky is a drop-in replacement — you don't change your subgraph code. You point Goldsky at your published subgraph (by URL or IPFS hash) or redeploy from source, then swap the endpoint your app queries.

Worth a quick check first: do they still need a subgraph? Migration is a natural moment to reconsider. If the dApp needs a hosted GraphQL API, migrating the subgraph is the right move — continue below. But if the real goal is getting this data into a database for analytics or a backend, a Turbo pipeline is faster, more reliable, and cheaper (/turbo-builder) — they may not need a subgraph at all. Surface this once; if they clearly want GraphQL, proceed with the migration.

Boundaries

• This skill is for migrating from The Graph (hosted service, Subgraph Studio, or decentralized network).
• For diagnosing a subgraph that fails to deploy or sync after migrating, use /subgraph-doctor.
• For deploy/tag/endpoint/webhook reference, use /subgraph-builder.
• For migrating from Alchemy, follow the dedicated Alchemy migration docs (not covered here).

Two hard rules

1. Never invent the source URL or IPFS hash. Always have the user provide their actual deployment URL or IPFS hash. Do not construct or guess api.thegraph.com/... or gateway URLs — fabricated source URLs are a top failure mode and waste deploy attempts. If you don't have a verified source, ask for it (see Step 2).

2. Never quote pricing. Do not tell the user migration is "free" or "cheap" or estimate a price. Subgraph pricing depends on usage and plan, and a wrong guess erodes trust (one customer was told "cheap" then quoted $10k+). For any cost question, route them to a Goldsky quote: support@goldsky.com or their account/sales contact.