Migration

Migration to FoxIDs normally combines application migration, user migration and a controlled transition between the existing identity platform and FoxIDs. Plan these workstreams together so identifiers, claims, authentication behaviour and rollback options remain consistent throughout the transition.

FoxIDs tenants support separate environments. Use dedicated development, test, staging and production environments to configure and validate migration flows in parallel without changing the production environment prematurely.

Assess the existing identity platform

Start by recording:

Applications, APIs and environments connected to the existing platform.
OpenID Connect, OAuth 2.0, SAML 2.0 and WS-Federation configurations.
Identity providers, authentication methods and multi-factor authentication requirements.
User identifiers, profiles, claims, groups, roles and access assignments.
Password storage, validation and reset options available in the source platform.
Certificates, metadata, redirect URLs, logout behaviour and token lifetimes.
Monitoring, audit and rollback requirements for cut-over.

The source can be AD FS, Active Directory, Keycloak, Auth0, Okta, Microsoft Entra ID or another identity provider or custom user repository. The available migration path depends on the protocols, export capabilities and password validation options provided by that source.

Application migration

Migrate applications by protocol and environment rather than treating the estate as a single cut-over.

Register the application in a non-production FoxIDs environment.
Reproduce the required claims, scopes, identifiers, certificates and logout behaviour.
Connect the existing identity provider as an authentication method when parallel authentication is required.
Test the complete sign-in, token and logout flow with representative users and integrations.
Move a controlled group or one application at a time before wider rollout.

FoxIDs protocol bridging lets an application retain its current protocol while the identity provider side changes. This is useful when modern OpenID Connect applications and existing SAML 2.0 or WS-Federation applications must operate during the same migration period.

User profiles and identifiers

Decide which identifier remains stable before importing or creating users. Email addresses, phone numbers and usernames can change, so use a stable source identifier where the integration supports one.

Map the user information required after migration:

User profile properties and login identifiers.
Claims used by applications and APIs.
Groups, roles and access assignments.
Multi-factor authentication requirements and the enrolment or recovery approach after migration.
Disabled, deleted or otherwise restricted accounts.

Use Upload many users when users can be exported and imported in batches. Use Directory Connector when an existing directory or custom repository should remain authoritative during the transition. For Active Directory, use Directory Connector for Active Directory.

Password strategy

Choose the password path based on what the source platform can expose or validate securely:

Import passwords or supported password hashes only when they are available in a compatible form and can be handled securely.
Validate the existing password through Directory Connector while the source directory remains authoritative.
By default, FoxIDs saves a local password copy after successful Directory Connector validation. This makes it possible to disable the connector later and move password validation to FoxIDs without forcing every user through a reset.
Disable the local password copy when policy requires the external directory to remain the only password store.
Require password reset when importing or retaining the existing password is not technically possible or when reset is the safer option.

Never assume passwords can be moved directly from an identity provider. Confirm the source platform's export format, hashing algorithm, validation API and security constraints before selecting the migration method.

Gradual migration

Where the source directory supports online validation, users can be created or updated in FoxIDs on their first successful sign-in through Directory Connector. This supports a gradual transition without requiring all users to migrate at the same time.

Keep the source available until the required user population has migrated and the rollback window has closed. Monitor failed sign-ins, identifier conflicts, missing claims and connector availability throughout the transition.

Cut-over and rollback

Before production cut-over:

Complete representative application and user acceptance tests.
Confirm certificates, metadata, DNS, redirect URLs and firewall paths.
Define the order in which applications, APIs and user groups move.
Record the previous configuration and the conditions that trigger rollback.
Ensure monitoring and logging cover both FoxIDs and remaining source-platform flows.
Communicate password reset or changed sign-in behaviour before it affects users.

A staged rollout limits the number of applications and users affected by each change. Keep rollback technically possible until production behaviour, claims and access have been verified.