How migration works
Export your existing keys
Extract key hashes from your current system (database, auth provider, etc.)
Why key hashes?
Unkey never stores plaintext keys. During migration, you provide the hash of each key, not the key itself. Your users continue using their existing keys. When they call your API:- You extract the key from the request
- Unkey hashes it and matches against stored hashes
- Verification succeeds if there’s a match
What can be migrated?
| Setting | Migrated? |
|---|---|
| Key hash | ✅ |
| Custom metadata | ✅ |
| Roles & permissions | ✅ |
| Rate limits | ✅ |
| Credits/remaining | ✅ |
| Expiration | ✅ |
| Identity/owner | ✅ |
Migration paths
Self-managed database
Export hashes from PostgreSQL, MySQL, MongoDB, etc.
Auth providers
Migrate from Auth0, Clerk, Firebase, or custom auth.
Other API management
Moving from Kong, Tyk, or homegrown solutions.
Custom systems
We’ll help you figure out the best approach.
Get started
Contact us
Email [email protected] with:
- Your workspace ID
- Current key storage system
- Approximate number of keys
- Hash algorithm used (SHA-256, bcrypt, etc.)
Execute
Follow our step-by-step guide to migrate your keys.
Every system is different. We’re here to help — reach out at [email protected] and we’ll guide you through your specific migration.