# Migrate pod-based index to serverless
There is no in-place conversion. The migration is two steps, and you keep both indexes until you cut over.
## Steps
1. **Decide on downtime.** If any divergence between old and new is unacceptable, pause traffic to the pod-based index before starting. The docs call this out explicitly.
2. **Save the pod index as a collection.** A collection is a static copy of the index. Creating it takes time proportional to index size; poll until it is ready.
3. **Create the new serverless index from the collection.** Same dimension and metric (they carry over); choose the serverless region.
4. **Verify the copy.** Compare `describe_index_stats` totals between the pod index and the new serverless index. Run a sample of queries against both and compare top results.
5. **Cut over reads.** Point the application at the new index. Keep the pod index for a rollback window.
6. **Decommission.** After the rollback window with no issues, delete the pod index to stop pod-hour billing.
## Ordering constraints
Collection before index creation; verification before cutover; cutover before deletion. Skipping verification is how silent data loss ships.
## Traps
1. Writing to the pod index during migration: those writes are not in the collection. Pause writes or re-sync the delta afterward.
2. Forgetting the pod index still bills after cutover. Deletion is a deliberate final step, not an afterthought.
3. Assuming dimension or metric can change in the move. They cannot; the new index inherits them.