Migrate from Bolt with evidence at every irreversible step

No. Separate the migration into customer identity, durable business records, files, derived analytics, and disposable preview state. Preserve provider identities and consent where possible; use a controlled account-link flow where credentials cannot be transferred. The destination can accept a staged backfill, but it must know which source is authoritative for each record while the move is in progress.

Mirror the environment shape first, then validate callback URLs, CORS, certificates, email sender alignment, storage access, and mobile links. Keep a versioned secret inventory without placing secret values in migration notes. Change DNS after the destination is ready to answer health and business checks; rotate credentials after traffic is stable and old access can be revoked without breaking a queued job.

The practical rollback is a traffic and write-authority reversal with reconciliation, not an untested restore fantasy. Capture a migration watermark, keep source writes or a controlled journal during the window, and define treatment for destination-only accounts. Exercise the reversal against a failed callback and a partial import. If neither team can say which system owns a record after rollback, the migration is not ready.

Build a representative corpus: verified and unverified users, role changes, large and missing assets, failed payments, pagination edges, and jobs interrupted mid-flight. Run scripted workflows and compare state, permissions, notifications, URLs, and audit records. Have product and operations review the exceptions, then hold the new path through a realistic traffic replay. Only after the evidence and support plan agree should Bolt be disabled.