Legacy 1.0 → 2.0 bridge & migration
Soundverse 1.0 (the old/ stack) and 2.0 run side by side during the transition. Two
mechanisms connect them: a read-only compat layer so 2.0 can surface legacy content, and a
migration spine that moves users, billing, and library content into the 2.0 schema.
The compat read layer
Section titled “The compat read layer”/api/compat/* routes in the SaaS BFF proxy to the legacy user-backend (old/ub), exposing
read-only legacy chat projects under a “Legacy” group in the sidebar. It is
identity-gated (a 2.0 user sees only their own legacy content). This is a bridge, not a
sync — nothing writes back to 1.0.
The migration spine
Section titled “The migration spine”Handled by core-migration:
| Piece | What moves | Status |
|---|---|---|
| User + billing migration | ~1.24M public.users → identity + billing (balances frozen at cutover) |
Audit-hardened, JIT-only |
| Library content migration | 1.0 files re-ingested into 2.0 storage via a legacy_file_map spine |
Code done, not deployed |
| Email/password import | 1.0 bcrypt users sign into 2.0 via lazy on-demand digest import into Logto | Not deployed |
| Shared-wallet token sync | One shared wallet; 2.0 billing canonical, 1.0 reads via a balance gateway | Design only |
Related
Section titled “Related”- core-migration — the migration service
- Configure Logto OIDC — where legacy credentials land
- Identity & auth — JIT provisioning