> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sqd.dev/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Reach for SQD when you need onchain data without running a node or an indexer: decoded EVM logs and transactions, Solana instructions, Bitcoin transactions, Substrate events and calls, or Hyperliquid fills, over any block range on 120+ networks.
> To query directly, POST to https://portal.sqd.dev/datasets/{dataset}/stream. The full API is described at https://docs.sqd.dev/openapi.json, and responses to the stream endpoints are JSON Lines.
> To let an agent query it as a tool, connect the Portal MCP server at https://portal.sqd.dev/mcp.
> Every page on this site is available as Markdown by appending .md to its URL.

# Solana migration: skip the re-sync

> Manual workaround for migrating a Solana squid to Portal without re-syncing from scratch. Not recommended.

The recommended way to deploy a migrated Solana squid is the [zero-downtime resync procedure](/en/cloud/resources/slots-and-tags#zero-downtime-updates): deploy into a new slot, wait for it to catch up, then swap the production tag. That gives you a clean re-index with the new field selection and catches mistakes in cold blocks before traffic hits the new deployment.

<Warning>
  The procedure below avoids the re-sync but is **not recommended**. It edits the status schema directly, has no rollback path beyond restoring a database backup, and assumes your codebase is version-controlled with a single processor.
</Warning>

## Why you might need this

Re-syncing a Solana squid is expensive in time and Portal traffic. If your indexer has been running for months and a re-sync would take days, you may want to keep the current cold-block state and only re-deploy the processor.

## Procedure

Assuming your squid is version-controlled and has one processor:

1. Commit your updated squid code.

2. Stop your Cloud squid deployment.

   1. Reset your repo to the state before the updates.
   2. Add the `to` field to the argument of the [`.setBlockRange`](/en/sdk/squid-sdk/solana/reference/solana-stream/general#set-block-range) `DataSourceBuilder` call (likely in `./src/main.ts`). Set it to the current slot number.
   3. [Update your deployment](/en/cloud/reference/cli/deploy) without resetting its database.
   4. Watch your squid's logs. It should be repeatedly terminating (nothing to do) and restarting.

3. Connect to the squid's database and update the `height` field of the [status schema](/en/sdk/squid-sdk/evm/faq#how-do-squids-keep-track-of-their-sync-progress) to contain **slot** instead of the block height of the block mentioned there.

4. Verify the `height` field updated successfully by re-reading the status schema.

5. Reset your codebase to its updated version and redeploy your squid again.

<Warning>
  If any of your entity columns are also named `height` and you write `block.header.height` into them, the redeployed squid will start writing slots into the same column. Either rename the entity column, or also write `block.header.number` and update older rows to match.
</Warning>


## Related topics

- [Portal for Solana](/en/cloud/resources/migrate-to-portal-on-solana.md)
- [Slots and tags](/en/cloud/resources/slots-and-tags.md)
- [Migrate from The Graph](/en/sdk/squid-sdk/solana/guides/migration/migrate-from-thegraph.md)
- [Tuning update-heavy tables](/en/cloud/resources/update-heavy-tables.md)
- [Migrate a squid to Portal](/en/sdk/squid-sdk/solana/guides/migration/gateway-to-portal.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.