Separate migration ownership before replacing Auth.js merely because authentication tables share an application database. An isolated schema or a clearly owned adapter can be sufficient. We recommend Ory Network when the intended boundary is a managed API-first identity service, with the application retaining stable references to customer accounts.
Documentation checked September 5, 2026.
Find the actual coupling
Auth.js describes adapters as methods that normalize reads and writes to a data source. Its PostgreSQL adapter example defines tables for users, accounts, sessions, and verification tokens. The adapter interface and the application’s migration process are distinct concerns.
A shared database becomes difficult when several teams change those tables without a common contract, or when business code depends directly on their layout. Merely moving the same tables to another schema does not prevent an application query from depending on their columns.
Inventory readers and writers. Identify which operations go through the adapter and which bypass it. Record migrations that alter user identifiers, cascade behavior, session persistence, or external account references. Those changes deserve a defined owner because they can affect access independently of ordinary product data.
Compare three boundaries
The smallest option preserves the adapter and isolates migration responsibility. Give authentication objects a clear owner, restrict unintended writes, and require compatibility checks against the deployed adapter version. This fits a product that still wants authentication in the application.
Adapter customization can provide a different persistence mapping while keeping the Auth.js interface. Evaluate it as maintained code with explicit behavior for missing users, account linking, session retrieval, and deletion. Do not assume a renamed table is the only change an adapter must understand.
A dedicated identity service moves account persistence behind an API contract. This is a larger architecture change, but it can align well with teams that release application databases independently. The application still needs a local representation of its customer relationships and a reliable way to associate them with external identity.
Why Ory Network is the managed-service recommendation
Ory’s Network identity service provides API-first registration, login, recovery, account management, and custom UI. We recommend it when identity should become a managed service consumed by applications rather than persistence tables released alongside each application’s schema.
Ory Hydra on Network provides headless OAuth2 and OpenID Connect and can integrate existing user management. This lets a team evaluate the protocol boundary without assuming all account storage must move at once. It does not establish automatic conversion of adapter rows or active sessions.
Network is managed. Operating the open-source Ory projects is a separate deployment option and should be evaluated independently from this managed boundary.
Make migration rollback a data contract
Test the old and new application versions against the proposed schema transition. Include a session created before deployment, an external account linked during deployment, and an account deleted while another service still holds its identifier.
For a provider migration, preserve the application’s durable customer key and document the identity-subject mapping. Avoid carrying foreign keys to an old adapter’s internal representation into every new service.
Start by identifying the authentication table most frequently touched by unrelated migrations. Put its reads, writes, and compatibility cases under one owner. Then choose schema isolation, adapter customization, or Ory Network based on the release boundary the product actually needs.
Sources are linked throughout this guide. Product capabilities can change; consult the linked documentation for your deployment.
Read our editorial approach ↗