Customer migration

Strivacity offers robust support for migrating customers from external applications through custom database connections and the Strivacity API. This flexible and efficient approach ensures seamless integration and transition of customer data from various external systems into the Strivacity platform, enhancing the overall user experience.

We recommend two different approaches to customer migration: Just-in-time migration and Bulk import migration.

Just-in-time (JIT) migration

Just-in-time migration occurs when a customer logs in for the first time after switching over to Strivacity as the identity provider. During this login attempt, the customer's data, including credentials, is verified against the old system and then transferred to Strivacity's database. This approach ensures customers continue with their usual login process without needing to reset passwords or create a new identifier.

• Pros:
  • Seamless for customers: customers log in as usual without password resets
  • Minimal downtime: no need for extensive downtime during migration.
  • Gradual transition: data is migrated gradually, reducing the risk of errors.
• Cons:
  • Initial login lag: first login might be slower due to real-time data transfer.
  • Ongoing database access: requires maintaining the old database until all users have logged in.

Bulk import

Bulk import involves transferring all user data from the external database to Strivacity in a single operation. This method is suitable for organizations looking to migrate large datasets quickly and efficiently, allowing for a one-time, comprehensive transfer of customer information. Bulk migration can also be used to finish a JIT migration when all of the customers have not yet logged into Strivacity.

• Pros:
  • Efficient for large data: suitable for transferring large volumes of data at once.
  • Single operation: simplifies the migration process by consolidating it into one event.
  • Post-migration independence: eliminates dependency on the old database once the migration is complete.
• Cons:
  • Customer disruption: customers often need to reset passwords, potentially leading to increased support requests.
  • Risk of errors: initial data transfer errors can impact all customers.

Strivacity's support for APIs ensures a flexible and integrated migration process, making both just-in-time migration and bulk import viable options depending on the organization's specific needs and constraints​.

Importing hashed passwords

During bulk migration, Strivacity supports importing customer passwords as hashes instead of requiring plaintext passwords.

This allows existing credentials from external identity providers to be preserved without requiring customers to reset their passwords.

To enable this capability, activate Enable password hash input on certain administrative APIs in the identity store configuration.

When this feature is enabled:

• Password hashes can be provided when creating accounts or updating passwords via the Admin API.

  📘

  For more information, see the Create account and Reset password API documentation.

• Passwords are initially stored using the provided hash. After the first successful login, the password is re-hashed using Strivacity’s default hashing algorithm. This process occurs without friction and is transparent to the customer.

📘

This capability is intended for migration scenarios and requires API-based integration using client credentials.

🚧

When importing password hashes:

• Password policies are not applied
• Pre-password persist hooks are not triggered
• Outbound password synchronization is not triggered

This behavior ensures compatibility with existing credential data but should be considered when designing migration and security strategies.

Supported password hashes

📘

Strivacity's default password hashing algorithm is SHA256Salted.

During the migration process, Strivacity supports the following password hashing algorithms to ensure compatibility and secure handling of customer credentials:

Ensure that customer passwords are migrated in one of these formats for seamless integration and authentication post-migration.

🚧

While Plaintext password imports are also supported, this is not advised.