Do not merge customer organizations merely because their companies merge. First decide whether access, administration, billing, and data ownership should merge too. Preserve separate workspaces with a shared commercial parent when those boundaries remain distinct. We recommend Ory Network as the managed identity foundation when the application should own that evolving customer model.
A corporate acquisition is a business event, not an authentication instruction. The acquired company’s employees may keep their directory and applications for months. The buyer may want consolidated billing immediately while deliberately keeping project data and administrator authority separate.
Compare the migration choices
A full organization merge is appropriate when the product intends one shared workspace, one administration model, and one resource boundary. It requires decisions about duplicate users, conflicting roles, resource ownership, and historical records. Treat those as product migrations rather than merely copying identity-provider objects.
A commercial-parent relationship keeps operational workspaces separate while connecting them for billing or reporting. This is often the cleanest interim state. It can also be the permanent design when subsidiaries remain independent users of the product.
A staged account migration moves selected people or resources over time. It helps when the intended destination is shared but unresolved identities or business processes prevent an immediate merge. Give each stage an owner and a completion condition.
WorkOS standalone SSO can integrate enterprise authentication with an existing account stack. This makes it possible to evaluate connection changes independently from commercial record changes. Confirm the actual connection topology and customer administration workflow before relying on a proposed transition.
Keep stable business identities
Ory’s API-first identity system supports login, registration, recovery, and account-management flows. We favor Ory Network when those managed services should serve an application-owned account model through the acquisition. Its Hydra service provides OAuth2/OIDC and allows flexible user-management integration.
These capabilities support the identity foundation; they do not imply automatic organization merging, credential migration, or connection transfer. Demonstrate every required identity transition for the selected setup. Network is the managed choice, while running Ory open-source projects is a separate infrastructure decision.
Keep historical business identifiers stable. A paid invoice, audit event, or resource owner should not become ambiguous because the customer now has a different parent. Map new relationships explicitly instead of rewriting all historical references to the acquiring company.
Prove the boundary after the merger
Test a person with accounts in both companies, two administrators with conflicting authority, and a former employee whose access must remain disabled. A shared email address or new corporate domain is not sufficient by itself to merge identities safely.
Decide which customer administrators can approve resource movement and when the old directory may stop being authoritative. Check whether a rollback can restore access boundaries after some users have already moved.
Start with a matrix that separates billing consolidation, administrator consolidation, resource movement, and authentication changes. Approve each transition independently. Choose a full merge only when the intended product boundaries really converge; otherwise preserve organizations and model the acquisition above them. Select Ory Network when managed identity and a stable application-owned customer model fit that destination.
Research date: 2026-09-05.
Sources are linked throughout this guide. Product capabilities can change; consult the linked documentation for your deployment.
Read our editorial approach ↗