The Bolt Migration Checklist

Use this checklist alongside the step-by-step Bolt migration guide. If an item doesn’t apply to your app, cross it out, but read it first. The items people skip are the ones that cause outages.

Code

• Project pushed to GitHub (or downloaded as ZIP and committed to a new repo)
• npm install and npm run build succeed on a clean machine
• Every variable from the project .env file listed
• Any Bolt-specific config or scripts identified

Bolt Database

• Every table listed with its row count
• Decision made: claim into Supabase, or export CSV/JSON
• Security rules and policies documented
• Test migration run end to end
• Own backup taken (Version History can’t restore data)

Users & auth

• Sign-in methods listed (email, Google, GitHub, etc.)
• Confirmed whether password hashes will transfer
• Reset or magic-link email written, if they won’t
• OAuth apps re-created on your own provider accounts

Storage

• Every bucket listed with total size
• Files copied to your storage
• File URLs in the database rewritten

Secrets

• Every secret name in the Secrets panel listed
• New key issued by each provider
• Keys stored in your secret manager or host environment
• Old keys revoked after cutover

Hosting

• Target host chosen and provisioned
• Nginx and SSL configured
• CI deploys on push to main
• Staging domain tested with real accounts
• Monitoring and uptime alerts set up
• Backups scheduled and one restore tested

Cutover day

• Users told about the maintenance window
• Writes frozen on the Bolt app
• Final data sync done and row counts reconciled
• Domain pointed at the new stack
• Sign-up, sign-in, payments and uploads verified
• Bolt project kept read-only as a fallback

After

• Two weeks without incidents
• Bolt plan downgraded or cancelled
• Runbooks written for deploys, backups and restores

Twenty-plus boxes is a lot for a weekend. If you’d rather hand it off, X & Company runs this checklist on every Bolt migration.