Identity Migration

Identity migration for users, passwords and applications

FoxIDs helps teams move from existing identity providers, directories and custom user repositories with a migration strategy that protects users, credentials, claims, application access and production continuity.

Talk to an expert All services

Migration planning with operational risk in view

A good migration plan is explicit about identifiers, claims, passwords, application dependencies, test environments, cut-over, rollback and what must be validated against an existing source before it moves.

User profiles, stable identifiers, claims, groups, roles and access information

Password strategy based on source platform, hashes, validation options and security requirements

Gradual application migration by protocol, environment and rollout group

Migration from existing platforms

FoxIDs helps teams move from Active Directory, AD FS, Keycloak, Auth0, Okta, Microsoft Entra ID, custom user repositories and other identity providers. The migration starts by understanding the source platform, attached applications, protocols, users, password options, identifier model, operational constraints, Directory Connector or AD connect options and the separate tenant environments needed to test the migration path before production cut-over.

Active Directory (AD) AD FS Keycloak Auth0 Okta Microsoft Entra ID Custom user repositories

Assess the source

Inventory applications, identity providers, directories, Directory Connector and AD connect options, user identifiers, claims, groups, roles, authentication methods and password options before choosing the migration path.

Design the transition

Decide where FoxIDs can bridge protocols, where Directory Connector or AD connect can support transition, where users can be migrated gradually, where passwords can be kept, and where password reset is the safer option.

Launch and stabilise

Plan staged rollout, production checks, rollback points, support ownership and monitoring so cut-over can happen with minimal downtime and clear recovery paths.

User migration

User migration covers more than creating accounts. The plan needs to preserve the identifiers and access information applications rely on, and decide whether Directory Connector or AD connect can support synchronisation from Active Directory or existing directories during transition.

User profiles and core account attributes
Stable subject identifiers and login names used by applications and APIs
Claims, groups, roles and access information that drive authorisation
Access relationships and application assignments that must survive the migration

Password strategy

Passwords need special care because the safest option depends on what the source system can expose, what can be validated during transition and what your security requirements allow.

Keep existing passwords where technically and securely possible
Validate passwords against an existing directory or identity source during transition, using Directory Connector or AD connect where relevant, then optionally move the password to FoxIDs after successful validation where supported
Force users to set a new password when this is safer or required
Gradually migrate users at first successful login where the source and security model support it
Use password reset flows when this gives the safest and clearest user journey

Password migration depends on the source platform, available hashes, validation options and security requirements. FoxIDs helps evaluate the options without promising that existing passwords can always be preserved.

Application migration

Applications can often be moved gradually by protocol, environment and rollout group. FoxIDs helps plan migrations across OpenID Connect, OAuth 2.0, SAML 2.0 and WS-Federation, using separate tenant environments where useful, so teams can reduce risk and avoid one large switch-over where it is not needed.

OpenID Connect OAuth 2.0 SAML 2.0 WS-Federation

Cut-over planning

Cut-over needs a clear plan for verification, communication, rollback and support while users are moving, with the migration path validated in separate environments before production changes.

Parallel testing in separate environments covering login, logout, claims, groups, roles and application access
Staged rollout across users, applications, environments and partner groups
Rollback planning and decision points before production changes are made
Steps to minimise downtime, failed logins and user disruption