You can change a tenant's mode without losing data, but it's not instant. This article walks through migrating a tenant between Shared and Separate database modes in either direction.
Shared → Separate
- Schedule: Pick a low-traffic window for the tenant. Set the tenant to “read-only” in the directory.
- Provision: Create a new database (e.g.
tenant_123_db) and run schema migrations. - Snapshot: Use the platform's tenant-export tool to extract every row tagged with this tenant's ID.
- Load: Import into the new DB. Validate row counts per table.
- Switch: Update the tenant's directory entry to point at the new DB. Existing sessions are terminated.
- Verify: Log in as a test user, run smoke tests against the new DB.
- Cleanup: After 24-48 hours of stability, delete the now-orphaned rows from the shared DB.
Separate → Shared
- Schedule: Low-traffic window. Tenant goes read-only.
- Export: Dump the tenant's DB.
- Import: Insert into shared DB, attaching the tenant ID to every row.
- Switch: Update directory; sessions terminated.
- Verify: Smoke test as above.
- Cleanup: Drop the separate DB once you're confident.
Worked Examples
- Tenant graduation: A customer outgrew the shared pool and signed up for premium hosting — migrate them to a dedicated DB during their off-hours.
- Tenant consolidation: Two small tenants on separate DBs cost more to maintain than they're worth — fold them back into shared.
- Acquisition: Acquired company arrives with their own DB; copy into your shared infrastructure to onboard.
Warning: Never skip the row-count verification step. A silent partial copy is the worst failure mode and is hard to detect later. Compare per-table counts and total record counts before declaring success.