> ## 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.

# 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-indexing/sdk/solana-batch/general#set-block-range) `DataSourceBuilder` call (likely in `./src/main.ts`). Set it to the current slot number.
   3. [Update your deployment](/en/sdk/squid-sdk/squid-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/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>