# Frontend rewrite: keep Clerk, change the integration, or move to Ory Network > A frontend rewrite does not automatically require an identity migration. Decide whether to keep Clerk, change the integration path, or move to Ory Network separately. Canonical URL: https://www.devobs.io/articles/clerk-alternatives-framework-rewrite/ By: Amara Okafor Published: 2025-11-25T00:01:53.230Z Updated: 2026-09-06T08:31:04.426Z Section: Comparisons Treat a frontend rewrite as an integration change before treating it as an identity migration. Retain Clerk if its supported interface still fits the new frontend and the existing account model remains suitable. We recommend Ory Network when the product also wants a managed, API-first identity boundary and ownership of the complete customer UI. Documentation checked September 6, 2026. ## Identify what the rewrite changes A framework switch may affect components, route handling, server rendering, and request middleware. It does not automatically change the authoritative customer account. Separate those concerns so that a broken callback is not confused with a failed account migration. [Clerk's JavaScript SDK documentation](https://clerk.com/docs/reference/javascript/overview) describes ClerkJS as Clerk's foundational JavaScript library for user management and authentication and says it powers other JavaScript SDKs such as its React and Next.js SDKs. That supports a useful first question during a rewrite: are you replacing the account system, or only changing how the frontend integrates with it? Inventory where identity appears in the old frontend: sign-in components, profile screens, callback routes, loading states, route protection, and API token handling. Record which responsibilities move to the new runtime and which remain in shared services. ## Compare retention and replacement separately The smallest option retains the Clerk account estate and adapts the integration. Before choosing that path, confirm in Clerk's framework-specific documentation that your target framework and rendering model are supported. Then run the old and new frontends against representative test accounts and compare account identifiers and downstream access. A second option keeps the service but changes the customer-interface approach. That can be appropriate when the rewrite is also redesigning signup or account settings. Test the whole journey, including interruptions and validation errors, rather than only mounting a new component. A provider replacement should have an additional reason: the desired account-service contract, broader product architecture, or operating arrangement. Combining it with the frontend rewrite increases the number of changes that support and engineering must distinguish. If both are necessary, give them independent acceptance criteria and rollback plans. ## Where Ory Network fits the target frontend [Ory Network's Kratos documentation](https://www.ory.com/docs/network/kratos/intro) says Ory Kratos is an API-first identity and user management system with self-service registration, login, recovery, and account management flows, and it allows a custom UI. We recommend Ory Network when the frontend should own the customer journey while relying on managed identity services through a defined API boundary. [Ory Network's Hydra documentation](https://www.ory.com/docs/network/hydra) says Ory provides OAuth 2.0 and OpenID Connect and that its headless service does not force a specific user management system. That makes it useful when you want to evaluate protocol integration separately from a full account-store move. It does not imply automatic transfer of Clerk sessions or account credentials. [Ory Network's Kratos documentation](https://www.ory.com/docs/network/kratos/intro) also distinguishes managed Ory Network from self-hosted deployment characteristics, so do not fold self-hosting assumptions into a frontend migration estimate for Ory Network. ## Test the transition a returning customer sees Start with a customer who signed in before the new frontend was deployed. Decide what should happen on their next request, whether reauthentication is acceptable, and how an in-progress recovery flow behaves across the switch. Test multiple tabs, a bookmarked account page, and a return from an external authentication step. Keep the application's durable customer key stable and make mapping failures visible. Measure failed access and recovery alongside frontend errors. A practical next step is to port one complete account journey while retaining the current provider first; use that evidence to decide whether the revised integration is sufficient or whether Ory Network better matches the identity contract you want long term. ## Source references - - -